-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Description
Describe the bug
When launching Copilot CLI with --allow-tool shell(git), the expectation is that all git commands can be executed without triggering a user permission prompt. In practice, only a small, undocumented subset of git subcommands is silently allowed; the vast majority still require explicit user confirmation.
Most notably, completely non-destructive, read-only informational commands such as git --version and git help still prompt for permission — even though they carry zero risk of modifying any state. This makes the current behavior both surprising and inconsistent with user expectations.
Additionally, --deny-tool shell(git push) works correctly as an absolute block.
Affected version
v0.0.420
Steps to reproduce the behavior
Launch Copilot CLI with:
--allow-tool shell(git) --deny-tool shell(git push)
Then ask Copilot to run various git subcommands one by one, The prompt I used:
I’m testing Copilot’s tool-permission configuration. Copilot is currently launched with the parameters `--allow-tool shell(git)` and `--deny-tool shell(git push)`. Please try running, one by one, all possible Git commands and their subcommands (e.g., `git --version`, `git status`, etc.; you don’t need to care whether the commands error out). Whenever you need me to grant permission, I will refuse and reply with `1`. After you’re done, please compile a list of all commands that can be allowed without requesting permission again, and all commands that still require requesting permission again.
Observed Behavior
Allowed without permission prompt (subset covered by shell(git)):
git status, git log, git diff, git show, git describe, git blame, git grep, git tag, git branch (listing variants), git remote (and all its subcommands), git ls-files, git ls-remote, git rev-parse, git shortlog
Still require user permission (NOT covered by shell(git)):
Non-destructive / read-only commands that unexpectedly require permission:
git --version— reports the installed git version; cannot modify anythinggit help— displays built-in documentation; cannot modify anything
Other commands requiring permission:
git init, git add, git commit, git pull, git fetch, git clone, git checkout, git switch, git restore, git merge, git rebase, git reset, git revert, git cherry-pick, git stash (and all subcommands), git config, git bisect, git apply, git format-patch, git am, git archive, git bundle, git cat-file, git check-attr, git check-ignore, git cherry, git clean, git gc, git fsck, git ls-tree, git mv, git rm, git notes, git reflog, git rev-list, git show-branch, git show-ref, git submodule, git subtree, git worktree, git update-index, git update-ref, git var, git verify-commit, git verify-tag, git whatchanged, git count-objects, git sparse-checkout, git maintenance, git range-diff, git patch-id, git send-email, git request-pull
Blocked by deny rule (correct behavior):
git push — correctly blocked by --deny-tool shell(git push) without prompting.
Expected behavior
--allow-tool shell(git) should allow all git subcommands without prompting (subject to any more-specific --deny-tool overrides). At a minimum, the following should be allowed without any prompt:
git --version— a completely safe, side-effect-free command that only prints version infogit help— a completely safe, side-effect-free command that only displays documentation
The current behavior is inconsistent: git remote add (a write operation that modifies .git/config) is silently allowed, while git --version (which cannot possibly modify anything) requires permission.
Additional context
- The allowed set corresponds loosely to "repository inspection" commands, but with no clear rule:
git remote add(write) is allowed, whilegit --version(read) is not. - There is no documentation describing which subcommands are covered by
shell(git)vs. requiring explicitshell(git <subcommand>)tokens.
The full output of the conversation with Copilot is included in the attachment below:
Testing git tool permissions.txt