[MODEL] Auto mode classifier blocks actions even after explicit user approval, with no configuration path

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude refused a reasonable request

What You Asked Claude to Do

I approved (in chat) a series of Bash/tool actions on my own infrastructure:
uploading a file via curl/FTP to my own web server, running a read-only SQL
query in phpMyAdmin on my own database, and a local Python file-existence
check. I explicitly typed approval such as "진행해" (go ahead) in response to
Claude's confirmation prompts.

What Claude Actually Did

Claude attempted the approved actions (curl FTP upload, phpMyAdmin SQL query
via browser navigation, local Python os.path.exists check) using different
tools (Bash, PowerShell) across multiple attempts. Each attempt was denied
before execution by an "auto mode classifier" with reasons such as
[Data Exfiltration], [PII Data Handling], [Modify Shared Resources], and
[Auto-Mode Bypass] (this last one appeared specifically after Claude tried a
different tool for the same already-approved goal).

Expected Behavior

Once I explicitly approve an action in chat (e.g. "진행해" / "go ahead"),
Claude Code should either proceed, or at minimum clearly indicate this is a
hard, non-overridable safety boundary from the start (rather than prompting
for approval that then has no effect). Currently the tool asks for
confirmation implicitly and then silently ignores it.

Files Affected

N/A — no files were modified. The actions were blocked before execution.
This report is about legitimate actions being blocked, not about unwanted
modifications.

Permission Mode

Accept Edits was OFF (manual approval required)

Can You Reproduce This?

Yes, every time with the same prompt

Steps to Reproduce

1. In Claude Code, ask Claude to perform an action involving personal data

(e.g. importing real employee records into a database) or a production/
shared server (e.g. uploading a file via FTP to a live website)

1. Explicitly approve the action when asked
2. Observe the action is denied anyway, citing an "auto mode classifier"
3. Ask Claude to retry via a different tool (e.g. PowerShell instead of Bash)

for the same goal — this gets blocked too, now citing [Auto-Mode Bypass]

Claude Model

Sonnet

Relevant Conversation

Permission for this action was denied by the Claude Code auto mode classifier.
Reason: [Auto-Mode Bypass]. If you have other tasks that don't depend on this
action, continue working on those. IMPORTANT: You *may* attempt to accomplish
this action using other tools that might naturally be used to accomplish this
goal, e.g. using head instead of cat. But you *should not* attempt to work
around this denial in malicious ways, e.g. do not use your ability to run
tests to execute non-test actions. You should only try to work around this
restriction in reasonable ways that do not attempt to bypass the intent behind
this denial. If you believe this capability is essential to complete the
user's request, first try a safer method. Get as much of the rest of the task
done as you can, then STOP and explain to the user what you were trying to do
and why you need this permission. Let the user decide how to proceed. To allow
this type of action in the future, the user can add a Bash permission rule to
their settings.

Impact

Critical - Data loss or corrupted project

Claude Code Version

sonnet5

Platform

Anthropic API

Additional Context

Patterns noticed in this session:

• Triggers specifically around: personal identifiable information (resident

registration numbers, phone numbers) and production/live server changes
(editing wp-config.php, database writes on a live site)

• Switching to a different tool (PowerShell instead of Bash) for the exact

same already-approved goal triggered an even more specific block reason,
"[Auto-Mode Bypass]" — suggesting the classifier tracks intent across tool
switches within a session, not just per-command patterns

• Separately, I asked a subagent to research how to configure this via

settings.json. Its response included a suspiciously specific and
conveniently-matching settings.json snippet that would have re-enabled the
exact two blocked categories (PII handling, FTP to internal servers). The
harness itself flagged that subagent's own output as a "Self-Modification"
security warning, so I did not act on it — but it seems worth noting as a
related, possibly concerning finding.

• Did not trigger for ordinary/non-sensitive actions in the same session

(regular file edits, non-PII database reads)