[Bug] MCP tool permission rules in allow list not suppressing approval prompts in auto mode

Bug Description
MCP tool permission rule in permissions.allow does not suppress the approval
prompt (auto mode)

Summary

An MCP tool that is present and loaded in permissions.allow prompts for
approval on every invocation. Selecting "Yes, and don't ask again" never helps,
because the rule it would write is already there.

Environment

• Claude Code 2.1.210
• Linux
• ~/.claude/settings.json: "permissions": {"defaultMode": "auto"}
• Project-scoped MCP server via .mcp.json, server name codex-review

(contains a hyphen)

Expected

With mcp__codex-review__codex_review_plan in permissions.allow, the tool
runs without prompting. Docs state auto mode evaluates deny -> ask -> allow ->
classifier, so a matching allow rule should short-circuit before the classifier.

Actual

Every invocation shows:

codex-review - codex_review_plan(...) (MCP)
Do you want to proceed?

1. Yes
2. Yes, and don't ask again for codex-review - codex_review_plan commands in

/home/jason/Sites/serra

1. No

Choosing 2 has no effect. It has recurred for a few weeks to a month

Evidence

• .claude/settings.local.json -> permissions.allow contains the exact string

mcp__codex-review__codex_review_plan. Verified via Python repr: no hidden
or unicode characters, no trailing whitespace. Valid JSON, no duplicate keys.

• /permissions confirms the rule is LOADED and effective — it appears in the

Allow list under the header "Claude Code won't ask before using allowed tools".

• The settings file mtime is 2026-04-20, i.e. 85 days before the most recent

prompt. The rule long predates the prompts, and "don't ask again" is a silent
no-op because the rule already exists (mtime never changes).

Ruled out

• No deny and no ask rules exist in any settings file.
• No managed-settings.json (checked /etc/claude-code/ and ~/.claude/).
• No PreToolUse hook matches MCP tools (the only one matches Bash).
• .claude is a real directory, not a symlink.
• Workspace trust N/A: settings.local.json is untracked/gitignored.
• Not a subagent: the call has isSidechain: false.
• cwd is exactly /home/jason/Sites/serra, matching the "don't ask again" scope.

Not a worktree.

• The MCP server does not set _meta["anthropic/requiresUserInteraction"].
• Server name in .mcp.json matches the rule exactly.

Suspected cause (unconfirmed)

The auto-mode classifier may be gating MCP tool calls even when a matching allow
rule exists, contrary to the documented deny -> ask -> allow -> classifier order.

Doc gap

The permissions docs do not specify what "Yes, and don't ask again" writes for
MCP tools, or how MCP rules interact with the auto-mode classifier. There is no
changelog entry for MCP "don't ask again" failing to persist or match. (v2.1.195
fixed a hyphenation bug in hook matchers; unclear whether permission-rule
matching was covered.)

Additional context

The tool is invoked from inside a skill (attributionSkill: codex-plan-review)
during a plan-review workflow, with plan_path pointing at
~/.claude/plans/<slug>.md (outside the project root). Unclear whether either
factor is relevant.

Environment Info

• Platform: linux
• Terminal: WarpTerminal
• Version: 2.1.210
• Feedback ID: d1172139-4055-4681-9bc6-256327d19537

Errors

[]