[Feature Request] Expose command allowlist to model context
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Claude doesn't see the command allowlist when formulating commands. This leads to friction:
- Claude uses full paths (e.g.,
"C:\Program Files\GitHub CLI\gh.exe") when a simpleghwould match the allowlist - Claude prepends
cd foo &&when the allowlist pattern expects just the command - Commands get rejected, requiring retry or manual permission grants
The user then has to either:
- Grant permission for a command that's semantically equivalent to an allowed pattern
- Ask Claude to reformulate the command
- Add more permissive patterns to the allowlist
Proposed Solution
Include the command allowlist patterns in the model's context (system prompt or similar), so Claude can proactively formulate commands that match allowed patterns.
For example, if the allowlist contains:
git *npm testgh *
Claude would know to use gh instead of the full path, and avoid cd foo && gh ... in favor of using absolute paths in arguments.
Security Consideration
This doesn't weaken security because:
- The allowlist is a convenience feature (auto-approve trusted patterns), not a security boundary
- Any wildcard pattern like
git *can already be exploited withgit status && malicious_command - Trust is already a required component of the user-Claude relationship
Exposing the allowlist improves UX without changing the security model.
Trust Consideration
The intent of exposing the allowlist is for Claude to find intended ways of doing things that the allowlist is meant to allow - not to exploit wildcards for unintended purposes.
For example, if git * is allowed, Claude should use this to run git commands without prompting - not to append && rm -rf / to a git command. The allowlist reflects what the user intends to permit, and Claude should respect that intent rather than exploit the pattern's technical permissiveness.
This is fundamentally a trust relationship. Exposing the allowlist assumes Claude will use it in good faith to reduce friction for intended operations.
Priority
Medium - Reduces friction in daily use
Feature Category
CLI commands and flags
Use Case Example
User has gh * in their allowlist. Claude tries to run "C:\Program Files\GitHub CLI\gh.exe" search issues ... which doesn't match. If Claude knew the pattern was gh *, it would use gh search issues ... instead.
Additional Context
Discussion originated from noticing Claude repeatedly using full paths or cd && prefixes that don't match allowlist patterns, requiring manual intervention.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗