Auto mode classifier denies tool calls in bypassPermissions sessions (v2.1.231)

Environment

• Claude Code: 2.1.231
• OS: macOS (Darwin 25.5.0)
• Launched with: claude --dangerously-skip-permissions
• Settings: ~/.claude/settings.json → permissions.defaultMode: "bypassPermissions" (set explicitly, so the CLI flag and the settings file agree — no ambiguity about the intended mode)
• Status bar: bypass permissions on
• No managed settings present (/Library/Application Support/ClaudeCode/managed-settings.json and /etc/claude-code/managed-settings.json both absent)

Summary

In a session whose effective permission mode is bypassPermissions, tool calls are intermittently denied with:

Permission for this action was denied by the Claude Code auto mode classifier.
Reason: Blocked by classifier.

Per the permission-modes docs, bypassPermissions "disables permission prompts and safety checks so tool calls execute immediately". The documented exceptions are explicit ask rules, connector tools an org set to ask, MCP tools marked _meta["anthropic/requiresUserInteraction"], the rm -rf / / rm -rf ~ circuit breaker, and two cross-session messaging safeguards. The auto mode classifier is not among them.

Two further mismatches with the documented exceptions:

1. Every documented exception produces a prompt. What we see is a hard denial with no prompt — there is no in-CLI path to approve the action.
2. The denial text tells the user to "add a Bash permission rule to their settings", which does not apply to MCP tool calls.

Evidence

From the session transcript (~/.claude/projects/<project>/<session-id>.jsonl):

• "permissionMode":"bypassPermissions" appears in 57 entries. No other value appears anywhere in the file — the session was never in auto under any resolution.
• The full denial string appears inside tool_result entries in that same transcript.
• Denials are non-deterministic: tabs_create_mcp was denied once, and the byte-identical call succeeded a few turns later.

Denied calls observed

All were claude-in-chrome MCP tools:

1. tabs_create_mcp — no arguments at all
2. navigate → https://github.com/enterprises
3. browser_batch → navigate to https://github.com/organizations/EXAMPLE_ORG/settings/billing
4. browser_batch → a single read-only left_click on a row of https://github.com/enterprises/EXAMPLE/billing/budgets, to open a detail view

Case 4 is the clearest: the same page had just loaded successfully via navigate in the same session. Navigation to that URL was allowed; a click on the rendered page was denied.

In the same session and mode, these all succeeded: navigation to example.com, google.com, github.com, and the billing URL in case 4; computer screenshots; typing into a search box; tabs_close_mcp; and every Bash call.

Minimal reproduction

1. Put "defaultMode": "bypassPermissions" under permissions in ~/.claude/settings.json
2. Launch claude --dangerously-skip-permissions
3. Confirm the status bar reads bypass permissions on
4. With the claude-in-chrome MCP, navigate to a billing or account-settings page of a site you are logged into
5. Attempt a computer left_click on that page
6. Observe the denial

Because the behavior is non-deterministic, step 5 may need a few attempts.

Expected behavior

Either:

• bypassPermissions suppresses the auto mode classifier, matching the documented "disables permission prompts and safety checks"; or
• the docs list the classifier as an exception in bypassPermissions, and the denial offers an in-CLI approval path rather than a dead end.

Actual behavior

Hard denial, no prompt, no approval path, non-deterministic, in a session that never left bypassPermissions.

Possibly related

• #36168 — bypass / dangerously-skip-permissions reported broken after v2.1.77
• #33617 — session lands in auto instead of bypassPermissions when launched with --dangerously-skip-permissions
• #43406 — Edit tool prompts despite bypass

Note on #33617: we initially suspected a flag-vs-settings mismatch was the cause, since the settings file had defaultMode: "auto" while the session was launched with the flag. Setting defaultMode: "bypassPermissions" explicitly and relaunching did not fix it — case 4 above was observed after that change, with both layers in agreement.