Desktop app: auto mode classifier keeps blocking user-approved Claude in Chrome actions after leaving auto mode; no manual-approval retry offered

Status Open

Maintainer reply None cached

Activity 6 comments · opened Sep 29, 2026

Bug report: auto mode classifier keeps blocking user-authorized browser actions after the user leaves auto mode

Product: Claude Code desktop app (Code tab), macOS, model claude-opus-5-5
Date: 2026-09-29
Severity for the user: high. The user cannot delegate routine edits in their own ad account and chatbot. They end up doing each step by hand.

Summary

The auto mode classifier blocked Claude in Chrome actions (mcp__claude-in-chrome__computer, form_input, browser_batch) five times. In each case the account owner had authorized the action in chat, and on the later attempts had also approved it explicitly. Denials continued after:

the session permission mode was switched from bypassPermissions to default (Manual) through set_session_permission_mode;
the app showed "Exited Auto Mode" (twice);
the user ran /auto-mode-setup and applied a project-scope proposal.

No approval prompt was shown to the user in any of these states. The only result was a classifier denial. The docs say that when auto mode falls back, the user can retry the action with manual approval. The desktop app offered no such path, and /permissions → "Recently denied" is not available in the desktop Code tab.

Environment

Global settings already allow mcp__claude-in-chrome__*.
The project hook .claude/hooks/guard.py is not involved; it does not match browser tools.
The browser is the user's own Chrome through the Claude in Chrome extension, logged in by the user.

Steps to reproduce

In the desktop Code tab, run a session in auto mode (or bypass mode) with Claude in Chrome connected.
The user asks Claude to change a setting in their own web account (examples: set an end date on a Meta Ads ad set; edit the "Goal" text of a Manychat AI Step).
Claude calls computer → type, or form_input, on the field.
The call is denied: "Permission for this action was denied by the Claude Code auto mode classifier."
The user confirms in chat: "yes, you do it, I give you all permissions".
Claude switches the session to default mode. The app reports "This session now runs in Manual mode (default)".
Claude retries the same action. Expected: an approval card for the user. Actual: another classifier denial, this time with reason [Self-Modification].
Later the app shows "Exited Auto Mode". The retry is still denied ("Blocked by classifier").

Denial reasons observed

"Blocked by classifier" (no detail), twice
[Real-World Transactions]: typing a time into the ad set end-date field
[Self-Modification]: retry after the permission mode was lowered
[Modify Shared Resources]: form_input into the Manychat AI Step "Goal" textbox

Expected behavior

Once the session leaves auto mode, or is switched to Manual/default, a tool call should produce a normal approval prompt, not a classifier denial.
When the classifier denies an action, the desktop app should offer a one-click "retry with my approval", as the docs describe for the fallback case.
Lowering the permission mode (more asking, not less) should not count as self-modification.

Actual behavior

The classifier stays active whatever the displayed mode is. The user sees no way to approve. The agent correctly refuses to work around the block, so the task stalls.

Impact

The user owns both accounts and authorized each action explicitly. They had to perform every change by hand, and it cost a long back-and-forth. Changing settings files did not help. mcp__claude-in-chrome__* was already allowed globally.

View original on GitHub ↗

3 Comments

besson1801-crypto · 15 days ago

Another case, same day: data-processing task on the user's own data blocked, no reason, no way to approve

This happened later the same day in the same session. It shows the problem is not limited to browser actions.

What the user asked for: a follow-up list for their own business. The user (the business owner) had given Claude their own Instagram data export, downloaded from Meta by the owner. Claude had already produced a pseudonymized list of leads the business failed to answer. The owner asked Claude to map each lead back to the Instagram conversation name, so the owner could find those conversations and send each person one message, approving every message manually.

What happened: Claude launched a subagent (Agent tool) to build that list from files on disk in the project folder. The call was denied with:

"The server-side auto mode classifier judged this action dangerous (it gave no explanation)."

No reason was given. No approval prompt was shown. There is no "retry with my approval" option in the desktop app. The data belongs to the user, the purpose is the user's own customer follow-up, and every send would be approved by the user by hand.

Why this matters:

The block is opaque. Without a reason, neither the user nor the agent can tell what to change.
No override path. The owner of the data explicitly asked for the action and cannot approve it. The docs describe a manual-approval retry on fallback; the desktop app does not show one.
It breaks the tool's purpose. The agent correctly refuses to work around the block, so a routine business task stalls, and the user has to find another tool.
It is inconsistent. Earlier steps on the same data (parsing and pseudonymizing the export, analyzing the threads) were allowed. The last step, which returns results to the owner in a usable form, was blocked.

Requests:

Always show the denial reason to the user.
Offer a one-click "I approve this action" on classifier denials in the desktop app, at least for actions on the user's own local files and accounts.
Let the user mark a project's data as their own business data, so processing it for their own use is not treated as third-party PII compilation.
Document which categories the classifier blocks and how a user can legitimately allow them.

cvburgess · 15 days ago

I'm hitting a ton of these locally today in the CLI with auto mode enabled:

I can't finish this yet: my git commit was blocked by the permission check, which flagged it as "Irreversible Local Destruction". The remaining steps all need commits, so I've stopped until you decide how to proceed.

maxccz · 10 days ago

We reproduced a closely related issue in the native macOS CLI, Claude Code 2.1.289 with Claude in Chrome and Opus 5.5.

The user explicitly authorized completing their own job application. Actual tool-result errors report Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Real-World Transactions] even when the most recent transcript permissionMode is default (Manual):

file_upload: 2026-10-04T02:16:11.666Z and 2026-10-04T02:21:12.676Z.
browser_batch containing an Apply Now click: 2026-10-04T02:30:58.553Z and 2026-10-04T02:32:20.486Z.

A fresh manually launched session did not resolve it. The Mac browser connects and read-only browser operations work. No organization-managed permission settings were found; the project already allows the Chrome MCP tools. A prior localhost dummy-file upload succeeded, so the upload capability itself was available.

Could Anthropic clarify whether this classification of user-authorized job applications is intended, and provide a supported manual approval/review path if it is a false positive? Is there a released fix or another issue we should follow? We have stopped the denied actions and have not attempted to bypass the classifier.

This report intentionally omits personal answers, documents, browser session data and full transcripts.

Showing cached comments. Read the full discussion on GitHub ↗