[Feature Request] Expose command allowlist to model context

Resolved 💬 3 comments Opened Jan 23, 2026 by AnotherJob Closed Feb 27, 2026

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:

  1. Claude uses full paths (e.g., "C:\Program Files\GitHub CLI\gh.exe") when a simple gh would match the allowlist
  2. Claude prepends cd foo && when the allowlist pattern expects just the command
  3. 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 test
  • gh *

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 with git 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗