claude-code - 💡(How to fix) Fix [FEATURE] scope permissions.allow to specific permission modes [1 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

permissions.allow in settings.json / settings.local.json applies uniformly across all permission modes (except bypassPermissions). Over time, project
allowlists grow large — in my case, ~100+ entries accumulated during normal work (approving common git, grep, psql, MCP calls, etc.).

This creates a tension:

• In acceptEdits mode I want the broad allowlist — I've explicitly opted into looser prompting and the allowlist keeps flow smooth.
• In default mode I want Claude to ask before running things — but the accumulated allowlist silently bypasses prompts for most commands, defeating the purpose of switching modes.

Effectively, once the allowlist grows, default mode becomes indistinguishable from acceptEdits for Bash/MCP calls. The only way to get real prompting
back is to manually curate or move the allowlist out.

Proposed Solution

Allow permissions.allow (and permissions.deny / permissions.ask) to be scoped to permission modes. A few shapes that would work:

Option A — per-mode blocks:
{
"permissions": {
"acceptEdits": { "allow": ["Bash(git:)", "Bash(psql:)", "..."] },
"default": {
"allow": ["Bash(ls:*)", "Bash(pwd)"] }
}
}

Option B — mode tag per rule: {
"permissions": { "allow": [
{ "pattern": "Bash(git:)", "modes": ["acceptEdits"] }, { "pattern": "Bash(ls:)" }
]
}
}

Option A is probably cleaner and backward-compatible (top-level allow stays as the default for all modes).

Why this matters

Permission modes are only meaningful if the allowlist respects them. Right now, users are pushed toward either:

• Keeping the allowlist small (painful — constant prompts for routine commands), or
• Letting it grow and losing the safety of default mode entirely.

Mode-scoped rules would let users opt into "strict" prompting for risky sessions (e.g. working on main, reviewing unfamiliar code) without permanently trimming their productivity allowlist.

Alternative Solutions

• PreToolUse hook: the hook input doesn't expose the current permission mode, and hooks run before allowlist evaluation — so an allow rule still wins. Not viable.
• Splitting settings.local.json and renaming it to toggle: works but manual and clumsy.
• /permission-mode switching: has no effect on allowlist behavior, which is exactly the problem.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

Scenario: I'm working across two types of tasks in the same project:

1. Routine development (refactors, adding features, writing tests) — I run /permission-mode acceptEdits and want Claude to move freely: git diff, grep, psql read queries, MCP calls against the dev database, running ./modooli-bin to test a module, etc. My allowlist has ~100 entries that make this
   smooth.
2. Sensitive work (reviewing an unfamiliar PR, working on main, debugging a production dump, giving a junior dev a demo) — I switch to default mode and want to be prompted for every Bash call. The whole point of switching is to slow Claude down and force me to approve each action consciously.

What happens today: Switching to default mode does almost nothing for Bash/MCP calls, because my accumulated allowlist still matches Bash(git:),
Bash(psql:), mcp__example__*, etc. Claude runs them silently just like in acceptEdits. The only real difference between modes ends up being file edits.

What I want: Scope the allowlist to acceptEdits so that in default mode I get honest prompts for the same commands. Same settings file, no manual
toggling, no splitting configs — just a mode-aware allowlist.

This is especially valuable for teams where settings.local.json is personal and grows organically: you don't want to audit and trim 100 entries every
time you want stricter prompting for an hour.

Additional Context

No response