Auto-mode classifier repeatedly blocks browser navigation, persists after explicit user bypass / Exit Auto Mode

Summary

During a live session, mcp__claude-in-chrome__navigate was repeatedly blocked by the "Claude Code auto mode classifier" with:

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

What happened

• Navigating to an internal admin-panel URL (an org-owned agent management dashboard, not third-party) was blocked on the first attempt.
• Retried the identical call 3 more times (same tab, same URL) — blocked every time, no variation in the denial reason.
• Asked the user to intervene. The user explicitly typed a bypass instruction in chat.
• The session then surfaced system reminders: "Exited Plan Mode" and "Exited Auto Mode" ("You have exited auto mode... You should ask clarifying questions when the approach is ambiguous rather than making assumptions").
• Despite that, the next navigate call to the same URL was blocked again, with the identical classifier message.
• Separately, in between these attempts, the browser tab group was found to be fully torn down (tabs_context_mcp returned "No tab group exists for this session"), even though nothing in the visible tool-call sequence closed it.
• A completely independent tool path (a different MCP connector, unrelated to the browser) also returned a hard 403 Forbidden / mcp_request_blocked on a plain read-only call around the same time.
• After the user asked to explicitly retry ("TRY claude-in-chrome"), a fresh tabs_context_mcp{createIfEmpty:true} call succeeded and subsequent navigation to the same previously-blocked URL worked immediately, with no configuration change on the user's end that they were aware of.

Why this is confusing/frustrating as a user-facing behavior

1. The classifier block gave no actionable detail about why the specific navigation was flagged (sensitive URL pattern? domain reputation? something else?), only a generic "Blocked by classifier" reason.
2. Explicitly exiting Auto Mode (via user instruction) did not visibly change the classifier's behavior on the very next identical call — the mode-exit and the persistent block felt disconnected/contradictory from the user's perspective.
3. The eventual "fix" (recreating the tab group) had no obvious causal relationship to the original block reason, making it unclear what actually resolved it — this makes the failure mode hard to reason about or self-diagnose in future sessions.
4. Silent tab-group teardown with no explicit close action in the visible tool trace made it look like a bug rather than an expected consequence of the permission block.

Impact

For a task involving legitimate, user-directed, time-sensitive work (credential provisioning coordinated live with the user), this cost several minutes of blocked retries and required the user to manually intervene twice (once for a general bypass, once to explicitly ask to retry the connector) before the underlying browser connection recovered.

Ask

• Surface a more specific reason when the classifier blocks an action (what triggered it), so the user/agent can address the actual cause instead of blindly retrying.
• Clarify the relationship between "Exit Auto Mode" and classifier gating — if exiting Auto Mode is expected to lift classifier blocks, that didn't happen here; if it isn't expected to, that should be reflected in the reminder text so users don't reasonably assume it will.
• Investigate why the browser tab group silently disappeared mid-session without an explicit close call.