permissions.allow rules do not override protected path prompts in bypassPermissions mode

Description

permissions.allow rules with path-specific patterns do not suppress permission prompts for protected paths (.claude/, .git/, etc.), even in bypassPermissions mode. Users who explicitly opt into allowing these paths in their settings are still prompted.

Steps to Reproduce

1. Add path-specific allow rules to ~/.claude/settings.json:

``json
{
"permissions": {
"allow": [
"Edit(//.claude/**)",
"Write(//.claude/**)",
"Read(//.claude/**)",
"Edit(//.git/**)",
"Write(//.git/**)",
"Read(//.git/**)"
]
}
}
``

1. Launch Claude Code with --permission-mode bypassPermissions
2. Attempt to edit a file in .claude/ (e.g., .claude/noice-deployments.yaml)

Expected Behavior

The edit should auto-approve since:

• The user is in bypassPermissions mode (explicitly accepting all risk)
• The path is explicitly listed in permissions.allow

Actual Behavior

Claude still prompts:

Do you want to make this edit to noice-deployments.yaml?
  1. Yes
  2. Yes, allow all edits during this session (shift+tab)
  3. No

Environment

• Claude Code version: latest (April 2026)
• Plan: Max 20X
• OS: Ubuntu 24.04
• Model: Claude Opus 4.6

Additional Context

• This also affects Bash commands targeting protected paths (e.g., rm ~/.claude/...) even with Bash(*) in the allow list
• The protected path check appears to be a separate enforcement layer that runs independently of and takes precedence over permissions.allow rules
• Workaround: approve once per session via the prompt (option 2), but this defeats the purpose of bypassPermissions mode
• --permission-mode auto is not available on Max plans, so bypassPermissions + allow rules is the only path to zero-prompt workflows for Max users