Desktop app: 'auto mode classifier' refuses supervised Claude-in-Chrome actions while the session is in bypassPermissions

Status Open

Maintainer reply None cached

Activity 3 comments · opened Oct 6, 2026

Claude Code desktop app: permission check blocks supervised browser actions in bypassPermissions mode

Date: 2026-10-06, 07:30 to 08:30 Pattaya (00:30 to 01:30 UTC)
App: Claude desktop app, Code tab, macOS. Session permission mode: bypassPermissions (confirmed by set_session_permission_mode, which answered "already in Bypass permissions mode"). Model: Claude Fable 5.1. Browser: Claude in Chrome extension, the user's own Chrome, user present and watching, user instructing each step in chat.

What happened

The user, who relies on the assistant for writing and posting because of a documented disability, approved six replies to be posted on his company's X account from his own Chrome. Every tool call aimed at that was refused with:

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

Refused calls (each its own small call, none chained):

browser_batch: navigate to the post, wait, find the reply box (refused as a whole).
navigate alone to the post URL (a read-only page load), refused.
navigate alone again, immediately after the user's explicit written instruction to post, refused.

Earlier the same hour the same check refused: ticking a checkbox and pressing "Authorize app" on X's OAuth consent page for the company's own app; adding a callback URL on the company's own X developer-app settings page; reloading Apple's account-recovery page; typing an email address (not a password) into Apple's sign-in form.

Allowed in the same session: reading pages, navigating to search pages, OAuth consent pages rendering, the Play Console and X developer console reads, API posts from the server.

Why this is a defect

The session was already in bypassPermissions, the mode whose purpose is to run without permission prompts. The "auto mode classifier" should not apply.
The actions were in the user's own browser, on his own accounts, with the user present and instructing in writing. The denial text offers no setting to change and no way to approve; get_settings lists no control for it.
The user has a disability for which this assistance is an accommodation; a silent, unchangeable refusal of supervised actions removes that accommodation.

Impact

About an hour of the user's time and significant distress; the work was later done through a server-side API route instead of the browser.

Ask

Either honour bypassPermissions for Claude in Chrome actions, or give the user a visible approval card / setting for these refusals, as every other permission in the app has.

Addendum, same morning: cross-session message held and expired between two bypassPermissions sessions

At 01:36 UTC this session sent a cross-session message (SendMessage) to another Claude Desktop session on the same machine, asking it to stop browser actions. The app held it ("usual cause: the two sessions run in different permission modes") and it expired undelivered. Per the user, both sessions have been in bypassPermissions for months. Same pattern as above: a bypass session treated as if it were not.

View original on GitHub ↗

3 Comments

ScottKemp · 7 days ago

Same behavior on Windows 11: Claude desktop app (Code tab), Claude Code 2.1.260, Opus 5.5, Claude in Chrome. No managed settings file, permissions.defaultMode unset, and the app reports bypass and auto mode both "allowed by policy".

Across 2026-10-06 and 10-07, one session's Claude in Chrome calls were refused with "denied by the Claude Code auto mode classifier" while get_session reported bypassPermissions and later default. No approval card was shown in any mode.

navigate to a Cloudflare Zero Trust applications page: [Permission Grant]
click "Add secret" on the user's own Google OAuth client: [Secret-Store Writes]
the same step retried after the user confirmed bypass mode: [Auto-Mode Bypass]
open that client's info panel: [Credential Materialization]
tabs_context_mcp (read-only): "Blocked by classifier", with the session in default
click the copy icon on a just-created client secret: [Credential Materialization], then [Auto-Mode Bypass] on retry

Verdicts were inconsistent: the same navigation, and adding, disabling and deleting a secret on the same client, succeeded minutes later with no setting changed. Non-browser tools (PowerShell including SSH, MCP writes) were never refused.

The built-in browser pane is affected too: when the user asked to try the same Cloudflare page there instead, the first navigate was denied [Auto-Mode Bypass]; the identical call succeeded a few minutes later.

Also reproduced the addendum: a SendMessage to another desktop session was "held" for differing permission modes and expired undelivered.

Effect: because the denial text names "auto mode", the agent told the user three times that the thread was in auto mode when it was in Bypass Permissions, and the user had to make the click by hand. Same ask as above: in bypass or manual mode, show an approval card instead of a silent classifier denial, and don't label it "auto mode".

CaptainVirgil · 6 days ago

Adding a data point in case it helps others, plus a workaround we've confirmed.

Setup: Claude Code CLI on Linux, installed with mise. Claude in Chrome driving a remote-desktop web console (a self-hosted tool, internal host) to edit config in a desktop app. Session launched with --dangerously-skip-permissions, and permissions.allow includes mcp__claude-in-chrome.

What happened:

On 2.1.280 the task ran cleanly, with 166 computer calls allowed.
On 2.1.291 and 2.1.293 the identical task was denied by the auto-mode classifier at almost every step. The reasons shown were Blocked by classifier, [Sensitive Remote Exec] and later [Auto-Mode Bypass], and a "server-side auto mode classifier judged this action dangerous" message appeared once.
/permissions approvals cleared only the one approved action. Adding an autoMode.allow rule turned later denials into [Auto-Mode Bypass], which matches what this issue describes.
Settings, permission mode and the autoMode block were identical on both dates. A transcript diff showed the Claude Code version was the only change. That's consistent with the 2.1.281/2.1.282 changelog entries moving auto mode to server-side review.

Workaround that worked: roll back to 2.1.280 (mise use -g claude@2.1.280) and restart Claude Code. The same task, in the same conversation that had been blocked on 2.1.293, then completed with zero classifier denials.

Things that did not help: /permissions grants, toggling modes mid-session, claude --continue, setting permissions.defaultMode, adding an autoMode.allow rule, and setting CLAUDE_CODE_AUTO_MODE_SERVER=0 (this last one was a guess on our part; it isn't documented).

I haven't tested whether the Desktop app can be pinned the same way. Hope a fix lands so pinning isn't needed.

FormaDelSol · 1 day ago

Same here on macOS, Claude desktop app (Claude Code 2.1.29x). Session in Bypass permissions (get_session reports bypassPermissions), Claude in Chrome on our own Magento admin. Saving help-center entries and deleting a URL rewrite are hard-denied by the auto mode classifier ([External System Writes], [Irreversible Deletion (general)], [Modify Shared Resources], [Auto-Mode Bypass], "Blocked by classifier"), even with my explicit approval in the same session and in a freshly started bypass session. No deny rules, hooks or defaultMode in settings. As the owner I have no way to approve the action. Please let bypass mode really bypass the classifier, or offer a manual approval.