github
Copilot CLI prompts for /dev/null access in non-interactive CI environment
Describe the bug
When running Copilot CLI inside CI (non-interactive), it occasionally prompts for access to /dev/null, which makes no sense in this context since there’s no user to respond. This causes the job to hang indefinitely.
✓ List directory . (32 files)
✓ Read package.json (74 lines)
The following paths are outside the allowed directories:
/dev/null | wc -l
Allow access to these paths? (y/n):
The following paths are outside the allowed directories:
/dev/null | head -20
Allow access to these paths? (y/n):
Affected version
0.0.350 Commit: 6bd4106
Steps to reproduce the behavior
Run Copilot CLI inside a CI job (GitHub Actions in my case).
Configure access only to the current repository (as recommended in the docs).
copilot \
--model claude-sonnet-4.5 \
--allow-all-tools \
--deny-tool 'shell(git push)' \
--deny-tool 'write' \
--add-dir "$GITHUB_WORKSPACE" \
Trigger any command that scans files (e.g., copilot suggest, copilot test, etc.).
Observe that it hangs waiting for input about /dev/null.
Expected behavior
Copilot CLI should not attempt to request access to /dev/null, nor prompt for confirmation in non-interactive mode. /dev/null should not be treated as a file path outside the allowed directories. It’s a standard system sink, not part of the project.
Additional context
It looks like the CLI is interpreting /dev/null as a regular file path when running shell commands like wc -l or head -20. This likely causes the access control layer to treat it as an “external” path and prompt for approval, even though /dev/null is safe and should be ignored or auto-allowed.
Environment: GitHub Actions (Ubuntu runner latest)
I am experiencing the same issue when using the GitHub Copilot extension. It always tries to write to /dev/null, which causes auto approval to malfunction and blocks most write requests. Has anyone found a fix or a way to bypass this issue?
This problem is pretty much all that is keeping GitHub Copilot from performing tasks without user interaction. All other interaction types can be pre-approved. Some kind of custom instructions to not redirect to /dev/null may be able to mitigate the problem until it is solved, but I haven't tried it yet.
