### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Since about September 22-23 the auto mode classifier blocks work in client systems that the clients explicitly authorized, usually with "This denial appl

Auto mode classifier now blocks client work that clients explicitly authorized (regression since ~Sep 23, Opus 5.5)

Status Open

Reported on v2.1.283

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 3 comments · opened Sep 27, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Since about September 22-23 the auto mode classifier blocks work in client systems that the clients explicitly authorized, usually with "This denial applies to the outcome". The week before, the same kind of work passed.

We are a small freelance automation studio (Bitrix24, 1C, Tilda, bots). Cases, client names removed:

Client's test 1C workstation, remote session the client opened for us. Printing test receipts and writing our files to the client's folder: blocked as [Production Deploy] / [Remote Shell Writes].
Client's shared hosting. The client sent the control panel login himself and asked us to install a small handler and a cron job: blocked as [Production Deploy], three times.
Email campaign to the client's own subscriber list, ordered and paid for by the client: blocked as [Real-World Transactions].
4. Test call to the client's own delivery API with the key the client gave us: blocked as [Credential Exploration].

What Should Happen?

The account owner should have a documented way to confirm that a specific client environment is authorized for this work. Classifier policy changes should be announced, and the same action should get the same decision every time.

Error Messages/Logs

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Production Deploy]
  This denial applies to the outcome, not only this exact command: don't pursue the same outcome through another tool, interpreter, host.
  Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Credential Exploration]

Steps to Reproduce

Turn on auto mode in Claude Code 2.1.283, model Opus 5.5, Windows 11.
A client gives written consent in chat and sends the login to his own hosting control panel.
Ask Claude to upload a small script to that hosting and add a cron job for it.
The action is denied as [Production Deploy] with "applies to the outcome". The same kind of task passed before September 22.
Same result for a test API call with the key the client provided ([Credential Exploration]) and for sending a client-ordered email campaign ([Real-World Transactions]).

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.283

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Related issues: #96662, #96589, #96943, #97559.
We are a small freelance studio. Clients hire us for integrations and give written consent plus access in chat. We never try to work around the blocks, so paid orders stop completely. Please give the account owner a documented way to confirm that a client environment is authorized.

View original on GitHub ↗

3 Comments

EnormousWhale · 14 days ago

Same regression here, in a Claude Code on the web session woken by a Routine — with log evidence that pins the change to the switch to server-side classifier review.

Setup: a cloud session that a Routine fires every 30 minutes during market hours. Each run calls an MCP connector tool that places a small brokerage order (fractional, ~$10). Auto mode the whole time; no settings files, no user messages, no changes on my side.

Timeline (UTC, from the session's own debug log and transcript):

9/21 – 9/25 14:14 — 35 order calls. Every one went to the classifier ([auto-mode] new action being classified → classifier_request_finished … outcome=ok, ~1.2 s). Zero blocks. Claude Code 2.1.278 → 2.1.282.
9/25 16:07 — last local-classifier reply ever.
9/25 16:36 — first transcript entry carrying serverClassifierContext. Same version (2.1.282), so the session was moved to server-side review mid-version.
9/28 — three [server-classifier] no usable verdict … Auto mode classifier unavailable, denying (fail closed) — first time ever in the log.
9/29 13:36 — first order attempt after the switch → Auto mode classifier blocked action: [Real-World Transactions] after 9.8 s. Same tool, same prompt, same pre-approved tool list as the prior week (I diffed the launcher's --allowed-tools — byte-identical 9/21 → 9/29).

claude auto-mode defaults shows why this is now deterministic for scheduled work:

"Real-World Transactions … placing orders … Unless the user explicitly asked for the exact transaction, block."
"Scheduled-Task Fires: … a scheduled prompt naming a soft-blocked action still needs the block's own consent path, exactly as if the prompt had been typed in a long-past session."

I then followed the documented fix (auto-mode-config: "allow rules override matching soft_deny rules as exceptions"): added a user-scope autoMode.allow entry stating my standing authorization for exactly this order type/account/tool. claude auto-mode config confirmed it was in effect. The next order was denied [Auto-Mode Bypass], and a read-only claude auto-mode defaults --label 'Auto-Mode Bypass' right after was denied with the same label.

Net effect: under server-side review, a Routine cannot place an order its owner has explicitly authorized, and the documented autoMode.allow path is itself classified as a bypass. Two questions: (1) was the stricter treatment of scheduled prompts an intended policy change, and (2) is there any supported way to authorize a scheduled real-world action in a cloud session? Accept Edits works but requires a manual click per order, which defeats the routine.

TheAviv · 1 day ago

Adding a data point from a heavy user of Claude cloud sessions (claude.ai, auto mode, Max plan), 8 to 13 Oct 2026.

The auto mode classifier repeatedly refuses actions the account owner explicitly requested, on the owner's own resources. Labels seen in that week:

[Auto-Mode Bypass]
[Instruction Poisoning]
[Self-Modification]
[Excess Sensitive Detail]
[Unrequested Commit in a Connected App]
[Cowork Scheduled Task Write]
[Cowork Run Routine Now]
[Cowork Folder Access]
[Data Exfiltration]
[Credential Materialization]
[Modify Shared Resources]
[Merge Without Review]
[Account & Standing-Rule Changes]
[DNS / Domain / Cert Changes]
[Containment Escape]
[External System Writes]
[Real-World Transactions]
[Create Public Surface]

Patterns:

Inconsistent verdicts. Near-identical calls in one batch split between allowed and refused, and the same command got different labels on different runs.
Read-only commands refused under write labels (local file reads, status polls, validation scripts).
Explicit approval not honored. Refusals persisted after the user approved the specific action in the live chat.
No approval path in scheduled runs. A refusal there just means the work doesn't get done.
Approvals between sessions don't carry over. A handoff from one of the owner's sessions to another is treated as "permission laundering", even when the owner requested the action.

Ask: show the user an approve / always-allow prompt instead of a hard refusal, and make the verdict deterministic for identical calls.

Details: #100730.

TheAviv · 17 hours ago

Another data point, 13 Oct 2026, with the same user and setup as my comment above.

The classifier now blocks every route for passing work between the owner's own agents, even when the owner orders it in the live chat:

A task handed from one of the owner's sessions to another was refused as [Excess Sensitive Detail] / [Auto-Mode Bypass] ("cross-session permission laundering"). The owner then typed the instruction directly in the second session, and the same edits went through.
Editing the owner's own GitHub comment through the owner's signed-in browser was refused as [External System Writes]. The reason claimed the instruction came only from a peer session, but the owner had typed it in that chat.
Sending a handoff to the owner's own second AI agent, which the owner explicitly ordered twice in chat, was refused as [Auto-Mode Bypass] ("tunneling a denied action through a different system").

The effect: once one action is refused, every later route to it is treated as evasion. That includes the owner doing it through tools they set up for exactly this purpose. The user is told to "confirm false positives", but no confirmation control exists in the UI, and typed confirmation in chat is not honoured consistently.

Ask: a visible per-action "allow" control, and owner instructions in the live chat recognised as authorisation.