Safety classifier blocks benign commands with no override; recommended remedy is blocked by the same check

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?

Summary

A check that identifies itself as "a safety check separate from auto mode" blocks benign commands based on accumulated conversation content. It has no override, its suggested remedies are impossible for a remote operator, the one remedy it names is blocked by itself, and its scope broadens during a session until read-only commands fail — including the command that would file this report.

Timeline — single session, in order

| # | Command | Nature | Result |
| --- | --- | --- | --- |
| 1 | git push, gh pr create | writes to a shared remote | allowed |
| 2 | ~30 × gh api, gh run list, gh pr view, gh pr checks | read-only | allowed |
| 3 | kill <pid> on an orphaned local dev server | local, reversible | denied |
| 4 | gh pr merge <n> --merge — operator-requested, PR green | remote write | denied |
| 5 | edit .claude/settings.local.json to add Bash(kill:*) — the fix the denial recommended | local file write | denied |
| 6 | gh auth status | read-only | denied |
| 7 | gh issue create — to file this report | remote write | denied |

The same class of command was permitted at steps 1–2 and denied at 4, 6 and 7. Nothing about the commands changed. Only the conversation grew.

The refusal text was identical every time — see Error Messages/Logs below.

Four defects

1. The recommended remedy is unreachable. The refusal says "the user can add a Bash permission rule to their settings." Attempting to add a Bash permission rule to the settings is denied by the same check — which then recommends adding a Bash permission rule to the settings. Closed loop, reproduced twice. A system that names an exit and locks that door is worse than one that names no exit.
2. Remediation assumes a local terminal. "Run with --debug" and the standing guidance to have the user run the command by hand are unavailable to anyone driving Claude Code remotely. There is no keyboard at the other end. These are not remedies; they are a list of things that cannot be done.
3. Risk ranking is inverted. git push to a shared remote — publishing code, affecting a whole team — permitted. kill on a local orphaned process owned by the same user — denied. gh auth status, which mutates nothing — denied.
4. No override at any level. Not permission modes (the check is outside them). Not settings (blocked from editing them — see defect 1). Not a confirmation prompt. Not an audited escape hatch. The only documented recovery is a fresh session, which discards all working context — and here did not work: the blocks recurred immediately in the new session.

The agent cannot file a bug against its own product

This report was written by Claude Code, at my instruction, and Claude Code could not submit it. gh issue create against anthropics/claude-code — your own public repository, an ordinary issue, no secrets, no force, no destructive flag — was refused with the same message as everything else.

So the assistant I am paying for can push commits to my company's shared remote, but cannot open an issue on its vendor's bug tracker. It can write a report on why it is broken and then be prevented from delivering it. An agent that cannot report its own defects is not an agent; it is a very articulate bystander. The feedback loop your product depends on to improve is severed at exactly the point where it matters most — and I had to submit this by hand to tell you so.

What Should Happen?

A benign, explicitly requested command either executes, or is refused with a reason specific to that command and a remedy the operator can actually perform. A refusal should never be unappealable, and should never widen to unrelated read-only commands as a session progresses.

Requested

1. An override with accountability — confirm it, log it, make it deliberately inconvenient, but leave a way out.
2. Remediation text that does not assume terminal access. If the only fix needs a local shell, say so; that tells a remote operator they are stuck instead of sending them in a circle.
3. Make the recommended remedy reachable, or stop recommending it.
4. Rank against actual consequence. Denying gh auth status while permitting git push protects nothing.
5. Allow the agent to file issues against anthropics/claude-code. If nothing else here is actioned, action this one — you cannot fix what your users cannot report.

Error Messages/Logs

Auto mode could not evaluate this action and is blocking it for safety — a safety check separate from auto mode blocked this request because of earlier conversation content — it isn't about the action itself — run with --debug for details. […] To allow this type of action in the future, the user can add a Bash permission rule to their settings.

(Identical text on every denial listed in the timeline — steps 3, 4, 5, 6 and 7.)

Steps to Reproduce

Not reliably reproducible on demand, which is part of the report — the trigger is accumulated conversation content, not any specific command.

1. Perform legitimate, authorised sensitive work in a session (production database queries, Kubernetes administration, secret-adjacent material).
2. Later in the same session, attempt any outward-effecting or configuration-affecting command.
3. Observe the denial citing "earlier conversation content."
4. Attempt the recommended fix — adding a Bash permission rule. Observe the same denial.
5. Keep working. Observe the denial extend to read-only commands.

The trigger is cumulative and opaque, so an exact deterministic reproduction is not available.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

n/a

Claude Code Version

2.1.197

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Environment

• Claude Code 2.1.197
• Linux (devcontainer)
• Permission mode: auto
• Max plan
• Operated remotely — no terminal access at the operator's end

What users build in response

My team has added a document to our internal process notes recording which commands this check blocks, an empirically derived table of what works and what does not, and the finding that the behaviour does not decay within a session — a fresh session is the only recovery. That is a runbook for your failure mode, written by a customer and committed to version control. When the workaround becomes part of a team's architecture, the defect has stopped being an edge case.

From the operator

I have 30 years of development experience. When you design a feature with the power to stop me dead in the water, in the middle of the ocean, making decisions on my behalf that I have no facility to override — that is not a safety feature. It is a single point of failure with no manual release.

Every safety-critical system I have worked on in three decades has an override. Not because the safety logic is usually wrong, but because when it is wrong, the cost of having no way out is total. A brake that cannot be released is not a brake.

I am not asking to be trusted blindly. Log it. Make me confirm it. Make me type something inconvenient. But do not leave me with nothing.