Auto-mode classifier keeps refusing browser actions after the user switches the session to Manual mode, and ignores explicit user approval

This reads like the auto-mode classifier is still attached after the session leaves Auto, not like a Chrome MCP failure. get_session already reports permissionMode: "default" (Manual), but later mcp__claude-in-chrome__* calls are still refused as "Auto-Mode Bypass" with no approval prompt — so the classifier decision is outliving the mode that created it.

A few tight fix surfaces that match the repro:

1. Gate the classifier on the current mode. When permissionMode is Manual/default, skip the auto-mode classifier entirely and use the normal per-action approval prompt. "Blind Apply" / "Auto-Mode Bypass" should only apply while Auto is active.
2. Clear classifier state on mode switch. Leaving Auto (UI or session tool) should drop any in-flight Auto refusals for that turn and the next, so an earlier Blind Apply cannot poison Manual.
3. Honor explicit chat approval or surface a prompt. If the user has already said "go ahead" in the same thread, either treat that as approval for the refused action, or show the Manual approval card instead of a silent classifier deny.
4. Expose the mode picker in Desktop. If Claude has to flip mode via a session tool because the UI control is missing, users cannot recover when the classifier sticks.

Useful confirmation bits if you still have the session: the exact permissionMode from get_session on the refusing turn, whether any approval UI flashed, and whether a brand-new Manual session (never Auto) can drive the same Squarespace edit. That would separate "stuck after Auto" from "classifier always on for Chrome tools."

Same behaviour here, in the CLI rather than the desktop app, across three sessions and several config changes.

Environment

• Claude Code CLI 2.1.283, macOS 26.6.2
• Model: claude-opus-5-5 (1M context)
• Browser tools: Claude in Chrome (computer, javascript_tool)
• Task: testing forms in a web app, using an account I own and was explicitly authorised to write test data to

What I tried, in order

1. Session 1, auto mode (~/.claude/settings.json had permissions.defaultMode: "auto"). Form writes were refused as "Modify Shared Resources" and "Real-World Transactions", even with explicit approval in chat. /permissions allow rules made no difference.
2. Changed defaultMode to "manual" and started a new session.
3. Session 2. Still refused ("Real-World Transactions", "Production Deploy") when typing a quantity and rate into a form. "manual" is probably not a valid value, so I changed it to "default" and started another new session.
4. Session 3, defaultMode: "default". One form submission was allowed. The very next action, typing a search term into a read-only list filter, was refused as "Modify Shared Resources". No approval prompt appeared.
5. Switched mode with Shift+Tab and told Claude to continue. The same typing action was then refused as "Auto-Mode Bypass", again with no prompt.
6. Tried permissions.disableAutoMode: "disable", but that is the wrong place for the key. The settings reference lists disableAutoMode as a top-level key. Corrected ~/.claude/settings.json:

``json
{
"disableAutoMode": "disable",
"useAutoModeDuringPlan": false,
"permissions": { "defaultMode": "default" }
}
``
Testing this in a fresh session now. Will report back.

Observations

• The classifier stays active even though the configured default mode is not auto. It also stays active after switching mode with Shift+Tab. That matches the original report, and also affects the CLI.
• It is not consistent: a form submit was allowed, then a keystroke into a search box on the same page was refused.
• After one refusal, any retry, even after a real mode change and explicit user approval, is labelled "Auto-Mode Bypass". There is no way to approve the action inside the session.
• ~/.claude/settings.json also contains "skipAutoPermissionPrompt": true from an earlier opt-in. That may be why auto mode keeps coming back, but I have not confirmed it.

Expected

Outside auto mode, a refused action should fall back to the normal per-action approval prompt. A mode switch should reset any earlier classifier refusals.

Confirming this affects Cowork tasks too, not just the CLI.

Context: a Cowork task, editing a Joomla CMS admin panel (not a code repo) through the Claude in Chrome browser extension, under my own already-logged-in session, on a staging site I administer myself.

Task set to "Manually approve." Setting a menu item's status via a form control (form_input on a <select>) was denied outright with [Modify Shared Resources] — no approval prompt appeared first, it was a hard block.
I switched the task's approval mode to "Auto" specifically to get past this.
Retrying the same category of action (navigating to the same admin edit page in a new tab) was denied again, now with [Auto-Mode Bypass].
There is no discoverable, documented way to allow this action/category for this task. I ended up doing the change by hand instead.

Would appreciate guidance on an intended, supported path to allow "edit content in an admin panel I'm personally logged into" — right now there seems to be none in Cowork's UI.