Skip to content

--allow-tool shell(git) does not blanket-allow all git subcommands — only a narrow undocumented subset is covered #1736

@imkuang

Description

@imkuang

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 anything
  • git 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 info
  • git 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, while git --version (read) is not.
  • There is no documentation describing which subcommands are covered by shell(git) vs. requiring explicit shell(git <subcommand>) tokens.

The full output of the conversation with Copilot is included in the attachment below:
Testing git tool permissions.txt

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions