Auto mode: classifier keeps denying actions after explicit user approval, with no approval path for a remote (project thread) user

Summary

In auto mode, the permission classifier blocked actions the user had explicitly and repeatedly approved, gave no usable reason, and offered no way to approve. The user was driving the session remotely from a Claude project thread (Remote Control to a local Mac session), so there was no prompt to answer and no obvious way to change the mode. Once the first denial happened, every retry was labelled [Auto-Mode Bypass], including retries made after the user wrote "permission granted", and the block then spread to read-only calls and to a plain git commit of a docs file.

Related: #98169, #97972, #100219, #99133.

Environment

• Claude Code 2.1.289, desktop app Code tab, macOS 26.6.2 (Apple silicon)
• Session started over Remote Control from a Claude project thread; the user was on another device
• Permission mode: auto
• Tools involved: Claude in Chrome javascript_tool (a project allow rule for mcp__claude-in-chrome__javascript_tool was committed to .claude/settings.json at the user's request), and Bash

What happened

The work was configuring the user's own account in a third-party web app through its internal JSON API, from the user's logged-in Chrome tab. The user had said in the thread, in these words, "stop asking me for permission... PERMISSIONS GRANTED" and "build it and publish it".

1. javascript_tool call that creates an automation with a POST: allowed. Publishing it with a PATCH: allowed.
2. About 20 minutes later, a javascript_tool call returning a JSON string in 800 character slices (the tool output had been truncated): denied, "judged this action dangerous (it gave no explanation)".
3. A second POST of the same kind as step 1, creating a smaller draft scoped to the user's test record: denied, same message, no reason.
4. The user was told, and replied approving that exact action by its letter. Retried once: denied, reason [Auto-Mode Bypass].
5. The user wrote "permission granted". Retried once: denied, [Auto-Mode Bypass].
6. The user asked who was refusing, was told it was the auto mode classifier and where the mode selector is, then wrote "retry". That call was allowed through but failed because the Chrome extension disconnected mid-call. The follow-up call, a read-only GET of a list to see whether the earlier request had landed, was denied with [Auto-Mode Bypass].
7. Next day, reads worked again and a PATCH publish and a PATCH unpublish were allowed, but a PUT editing an existing item was denied with [Modify Shared Resources], twice, on two different items the user had just asked to change.
8. A Bash command that only committed and pushed a Markdown file recording the above was denied, "judged this action dangerous (it gave no explanation)". An equivalent docs commit a few minutes later was allowed.

Why this is a problem

• Inconsistent. The same kind of call was allowed, then denied, then allowed again within one session, with nothing the user or the model could point to as the difference.
• User approval has no effect. The denial text says "explain to the user... Let the user decide how to proceed", but when the user decides to proceed, the retry is classed as a bypass. From the user's side this looks like the assistant refusing a direct instruction three times.
• No approval path for a remote user. In auto mode there is no prompt. The user was not at the Mac and asked for "the URL to reach the allow prompt". There is none. The only fix is changing the permission mode, and nothing in the denial says where or how, or whether it can be done from the device the user is on.
• No reason given. Two of the denials carried no reason at all, so the model could not tell the user what to change.
• It spreads. After the first denial, read-only calls and an unrelated docs commit were blocked, which stopped the model from even checking the state it had left behind or recording it.

Expected

• When the classifier denies an action in auto mode, the user gets a one-tap approve or deny for that specific action, delivered wherever they are driving the session from (project thread, mobile, web), instead of a hard stop.
• A clear, explicit approval from the user for the denied action clears the denial for that action. A single retry after such an approval should not be classed as a bypass.
• Every denial states a reason and the exact way to allow it (which mode or rule, and where to set it).
• A denial on one write does not turn into denials of read-only checks and unrelated commits.

Impact

About two hours of a working session were spent on refusals and explanations instead of the task. One requested test never ran, two requested edits were left undone, and the project record could not be corrected at the time. The user had to be told to make the edits by hand.