`> /dev/null` and `2>&1` should be special-cased to not require permission

[andrewneilson]

Describe the bug

It seems cd is a special case in that you have to approve it every time. This is probably fine, but the issue is that copilot CLI frequently wants to cd into the current directory before running other commands. So even if those commands are already approved, the fact that the cd is there means we still have to approve it.

Here is an example:

 ╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
 │ Check desktop apps files:                                                                                                        │
 │                                                                                                                                  │
 │ ╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
 │ │ cd /current/directory && for file in sub/dir/fileA sub/dir/fileB                   │ │
 │ │ sub/dir/fileC; do echo "=== $file ==="; grep -n "NEEDLE" "$file" 2>/dev/null | head -3;  │ │
 │ │ done                                                                                                                         │ │
 │ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
 │                                                                                                                                  │
 │ Do you want to run this command?                                                                                                 │
 │                                                                                                                                  │
 │ ❯ 1. Yes                                                                                                                         │
 │   2. No, and tell Copilot what to do differently (Esc)                                                                           │
 │                                                                                                                                  │
 │ Confirm with number keys or ↑↓ keys and Enter, Cancel with Esc                                                                   │
 ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

And especially note that the approval is one-time.

This happens constantly with many commands so I don't think it has anything to do with the for loop.

Affected version

0.0.334

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

[andrewneilson]

A better example of something even more innocuous

 ╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
 │ Check if this file exists:                                                                                             │
 │                                                                                                                                  │
 │ ╭──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮ │
 │ │ cd /current/directory && ls -la path/to/file 2>&1                                               │ │
 │ ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯ │
 │                                                                                                                                  │
 │ Do you want to run this command?                                                                                                 │
 │                                                                                                                                  │
 │ ❯ 1. Yes                                                                                                                         │
 │   2. No, and tell Copilot what to do differently (Esc)                                                                           │
 │                                                                                                                                  │
 │ Confirm with number keys or ↑↓ keys and Enter, Cancel with Esc                                                                   │
 ╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

[SteveSandersonMS]

I suspect this isn't to do with cd at all, but really it's the redirection operators that are triggering the prompt. We prompt for confirmation if it looks like the script is trying to write a file using > destination syntax because that could otherwise bypass rules on which directories may be written to.

However we should special-case > /dev/null and 2>&1, as they aren't going to write to a file on disk.

[RyanHecht]

Can confirm a simple cd $CWD && do_something_else does not trigger it, it's the output redirection:

Going to rename this issue to better reflect the change needed!

[dsyme]

We have hit this. We have an invocation of Copilot CLI

  copilot --add-dir /tmp/gh-aw/ --log-level all --log-dir /tmp/gh-aw/.copilot/logs/ --allow-tool 'github(download_workflow_run_artifact)' --allow-tool 'github(search_users)' --allow-tool safe_outputs --allow-tool shell --allow-tool web-fetch --allow-tool write --prompt "$COPILOT_CLI_INSTRUCTION" 2>&1 | tee /tmp/gh-aw/agent-stdio.log

During the execution we see this shell command

dotnet tool install --global dotnet-reportgenerator-globaltool 2>&1 || echo "ReportGenerator already installed"

resulting in

Permission denied and could not request permission from user

but then this very similar shell command

export PATH="$PATH:$HOME/.dotnet/tools" && dotnet tool list --global | grep reportgenerator || dotnet tool install --global dotnet-reportgenerator-globaltool

is accepted through the permissions system.

I have access to Copilot CLI source code at GitHub and I set VSCode Agent Mode analyzing this and it said this:

Looking through the onShell handler, I don't see hasWriteApproval being used directly in the shell permission logic! It's only used in the onWrite handler

This might be a bug in the logic. The onShell handler should probably check if write redirections are approved when hasWriteApproval is true.

The issue is that line 428 doesn't consider whether write operations are approved:

This would explain why:

• First command with 2>&1 fails: hasWriteFileRedirection is true, but the logic doesn't check hasWriteApproval
• Second command without redirections succeeds: hasWriteFileRedirection is false

The fix would be to modify the condition to also allow approval when write operations are explicitly approved via the --allow-tool write flag.

[RyanHecht]

We've improved our permissions checking for redirection scenarios in 0.0.351!