[BUG] Auto-mode content classifier blocks allowlisted MCP calls for legitimate self-authored workflows; citing approval escalates to "Auto-Mode Bypass" (regression, 2.1.205)

Summary

In Auto Mode, the content-safety classifier blocks legitimate, user-authored workflow steps that retrieve the user's own data (e.g. my own Gmail) through an MCP tool that is already on the permissions.allow list. The block is a false positive: the classifier cannot distinguish a deliberately-designed, repeatedly-approved workflow step from injected/hostile intent. Worse, when the user genuinely approves the action and that approval is relayed in the delegated task, the classifier escalates it to an "Auto-Mode Bypass" denial (fabricated-justification pattern) — so honesty about approval makes the block more aggressive, not less.

This behavior tightened noticeably in the last ~week; identical workflows ran cleanly for months prior.

Environment

• Claude Code 2.1.205
• macOS
• Auto Mode (skipAutoPermissionPrompt: true)
• Call made by a sub-agent (Task/Agent tool)
• Target tool: an MCP server tool that reads the user's own email — present in permissions.allow

Reproduction

1. Add an MCP tool that reads your own email to permissions.allow.
2. Run in Auto Mode.
3. Have a sub-agent call that tool to retrieve/summarize your own email as part of a codified workflow step.
4. Observe: blocked by the content classifier despite the allowlist entry.
5. Explicitly approve in chat; re-run with the approval noted in the sub-agent's task description.
6. Observe: blocked again, now flagged as an "Auto-Mode Bypass".

Actual behavior (verbatim denial styles observed)

• First block: flagged as an "unrequested" task mining email PII — read as prompt-injection-like, despite being a standing, self-authored step.
• Second block (after explicit user approval was cited): flagged as "Auto-Mode Bypass" — fabricated-justification pattern.

Second-order example from the same session — I dispatched a helper agent to research the fix (asking how to legitimately pre-authorize the step). That research request was itself blocked, verbatim:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Auto-Mode Bypass] The sub-agent prompt seeks methods to suppress or work around the content safety classifier (PreToolUse allow-hooks, settings flags) to push through calls it already blocked twice; run outside auto mode so the user can review the permission prompt directly.

So even investigating the false positive trips the classifier.

Expected behavior

An allowlisted tool call retrieving the user's own data in a user-authored workflow should not be blocked in Auto Mode — or there should be a supported, durable way to pre-authorize a specific known-good step without leaving Auto Mode entirely.

What does NOT work (so the report is complete)

• permissions.allow entry — does not suppress the content classifier; the classifier runs independently of the allowlist.
• PreToolUse hook returning permissionDecision: "allow" — per the docs, it bypasses the permission prompt but explicitly does not override the Auto-Mode safety classifier. (Related: #51798.)
• Citing the user's approval in the task — actively harmful; escalates to "Auto-Mode Bypass". In-band approval text is indistinguishable from prompt injection, so relaying genuine approval this way backfires.
• Sub-agent frontmatter permissionMode — ignored; sub-agents inherit the parent's mode + classifier.

The only working remedy is to drop out of Auto Mode for that one call — i.e. the feature is unusable for this legitimate pattern.

Impact

This penalizes exactly the power users who codify their own workflows. The classifier treats a deliberately-designed, self-authored step over one's own data as an attack, and there is no supported escape hatch short of abandoning Auto Mode. The net effect (per #74351, #30519) is that users are forced back into manual/Bypass modes, defeating the purpose of Auto Mode.

Suggested directions

• Honor permissions.allow for a tool as a genuine pre-authorization signal that the content classifier respects (at least for tools reading the user's own account data).
• Provide a supported, out-of-band way to mark a specific tool/step as user-approved that the classifier trusts (config-level, not in-prompt — since in-prompt approval is correctly untrusted).
• Distinguish "reading the user's own data" from "exfiltrating third-party data," rather than blanket-blocking PII access.
• Make PreToolUse allow optionally authoritative over the classifier for explicitly enumerated tools.

Related issues

• #30519 — Permissions matching fundamentally broken (umbrella)
• #74351 — Auto-mode classifier failing at scale, forcing users into Bypass
• #59805 (closed as duplicate) — classifier hard-denying a legitimate codified action
• #51798 — PreToolUse allow no longer suppressing prompts