Claude Code Auto Mode Blocked My Command: What to Do Next

When Claude Code auto mode blocks a command, first read the denial and decide whether it is a real “denied” or a “no verdict” error, because they are handled differently. For a real denial, use the documented route: retry the action by hand from the /permissions screen, say in the session that you meant it, or add a rule. If the step is risky or cannot be undone, hand it to a human as a short script that you run yourself. That last part is our own practice, not Anthropic’s advice.

These are the docs as read on 2026-10-23. We did not test them in a live Claude Code session, and we did not record a version. The behaviour has changed recently: according to the docs, auto mode became the built-in starting mode for interactive terminal and VS Code sessions in version 2.1.283. Check the pages linked below before you rely on any detail.

What does auto mode check, and why?

Auto mode is a permission mode in which a separate model reviews actions instead of you. The docs put it in one line: “A separate classifier model reviews actions before they run” (permission modes, checked 2026-10-23). A classifier here just means a model that sorts each proposed action into allowed or not allowed. Read-only actions and file edits inside your working directory (except writes to protected paths) are approved without review. Other actions go to the classifier.

The docs also say what it is for. The default blocks include examples such as production deploys and migrations, and boundaries you state in conversation are enforced too: if you tell Claude not to push, the classifier blocks matching actions. Anthropic is plain about the limit: “Auto mode reduces permission prompts but does not guarantee safety.” So this is a safety layer that was built to say no sometimes. It is not a defect, and it is not a guarantee.

AccrueDev is not affiliated with Anthropic. Everything here about the control comes from the public docs.

Is it “denied” or “no verdict”?

Read the message first, because the two cases look alike and need different handling. A denial means the classifier judged the action. A no-verdict result means the check did not return an answer at all. The docs say that when the server gives no verdict, “Claude Code denies the action rather than run it unreviewed” (permission modes, checked 2026-10-23). The error text says the check could not decide, not that the action is unsafe. Anthropic has a page for it: the server returned no safety verdict.

A public example is GitHub issue #97854, opened 2026-09-28 and still open when we read it on 2026-10-23. It reports the server-side check intermittently returning no verdict, so that even trivial commands were blocked. The error text in the issue calls it a transient failure of the check, not a judgment about the action, and says read-only operations still worked. The issue body says it resolved by itself after minutes, one commenter reports a repeating cycle that only a new session cleared, and another says switching to manual for a few calls and back cleared it. Those are user reports. We have not reproduced them.

So for a no-verdict message, do not rewrite your task or argue with the tool. The errors page says to wait a moment and then try the action again (for the related “cannot determine” error). Once a run of no-verdict responses stops the turn, it says to send a message to try again, or switch out of auto mode. If it repeats, the options are the ones people report in that issue: switch modes or start a new session. The docs also describe an environment variable, CLAUDE_CODE_AUTO_MODE_SERVER=0 (v2.1.281 or later on a direct API connection), that makes Claude Code use its own classifier requests instead of the server-side check. It changes who runs the check, not whether it runs.

These apply to no-verdict errors only. A real denial is not an outage; do not switch modes to push the same action through. Use the retry, the explicit approval or a rule. For an explicit denial, keep reading.

The closest public match we found to “it was allowed earlier and denied later” is issue #98199, opened 2026-09-29 and open when we read it. The reporter says a release step that was allowed earlier in a project was denied later, even though they had approved it in chat. It has two comments, one from the reporter and one from another user who says they have the same issue, so it shows that people hit this and nothing more. We make no claim about its cause.

What can I do inside the documented settings?

Four things, all from the docs, in order of effort.

First, retry by hand. The docs say to open /permissions, go to the “Recently denied” tab and press r to retry the action with manual approval (auto mode configuration, checked 2026-10-23). Anthropic’s engineering post describes a false positive as costing a single retry, where the agent gets a nudge and reconsiders. That describes the design, not a promise about your session. After 3 denials in a row or 20 in total, auto mode pauses and Claude Code goes back to asking you (permission modes, checked 2026-10-23).

Second, say what you meant, in the same session. The docs say a one-off action you did intend can be approved in your next message, if the approval names the action and its specifics, and that it covers only that action. A vague request does not count: “clean up the repo” does not authorize a force push, while “force-push this branch” does. Third, teach it the context. Repeated denials for the same destination usually mean missing context, and the docs suggest adding that destination to the autoMode.environment setting or running /auto-mode-setup. That setting is read from your user settings, managed settings or the --settings flag, not from a project’s own settings file, so a checked-in repository cannot grant itself permissions (auto mode configuration page, checked 2026-10-23).

Fourth, add a human checkpoint. Rules are evaluated in order: deny, then ask, then allow, and the first match decides (permissions, checked 2026-10-23). A permissions.ask rule forces a prompt even in auto mode, and a permissions.deny rule blocks before the classifier is consulted. The docs give this shape:

{"permissions": {"ask": ["Bash(git push *)", "Bash(gh pr create *)"]}}

A Bash rule such as Bash(git push *) matches commands that begin that way, so a push written as git -C . push is not matched. For a check on the full command text, use a PreToolUse hook (the docs describe this). A boundary you only state in conversation can be lost when the conversation is compacted (summarised to free space), so use an ask or deny rule when it must last.

What do I do when the step is risky or cannot be undone?

Stop asking the agent to push it through, and hand it to a person as a short script. This is where we leave the docs. Anthropic describes rules and a manual retry. The Anthropic docs pages we read (permission modes, auto mode configuration, permissions, errors) and the engineering post do not describe a script handover, so what follows is our own practice, not a recommendation from Anthropic.

The pattern, as written in our own rules file:

• The script sits in the project root with a short name, so the one line you type is short. Our rules file records that on 2026-08-11 a long command pasted into chat wrapped at the terminal width and a deploy invocation failed on the corrupted path.
• The same file records that on 2026-09-02 a handed-over line pointed into a deep scratch folder and was itself about 120 characters of path. Long paths and values live inside the script.
• The first pass is --dry-run, and it actually runs every read-only check, including remote ones. A step that is only printed is not a check.
• The real run needs a typed confirmation word, and it does one kind of irreversible thing per script.
• The script ends by printing counts: what was executed, what was skipped. Secrets are masked before anything is printed.

A sanitised skeleton:

#!/usr/bin/env bash
# run-release.sh: bash run-release.sh --dry-run | --go
set -euo pipefail
MODE="${1:---dry-run}"; TARGET="${TARGET:?set TARGET first}"; EXEC=0; SKIP=0
case "$MODE" in --dry-run|--go) ;; *) echo "usage: $0 --dry-run | --go"; exit 2;; esac
check() { "$@" || { echo "CHECK FAILED: $*"; exit 1; }; EXEC=$((EXEC+1)); }
# Read-only checks: these really run in both modes
check git diff --quiet
check test -f ./release/app.tar
check ssh -o BatchMode=yes "$TARGET" true
check ssh "$TARGET" 'test -w /srv/app'
# The one mutating step: only behind --go and a typed word
if [ "$MODE" = "--go" ]; then
  read -r -p "Type RELEASE to continue: " word
  [ "$word" = "RELEASE" ] || { echo "aborted"; exit 1; }
  scp ./release/app.tar "$TARGET:/srv/app/"   # MUTATES
else
  SKIP=$((SKIP+1)); echo "SKIPPED (dry-run): copy artifact"
fi
echo "RESULT mode=$MODE executed=$EXEC skipped=$SKIP"

Why this fits the control instead of fighting it: the typed word is a specific approval, given by a human, for one named action. That matches what the docs ask of a stated approval. This is our interpretation, not something the docs say. The agent’s job ends at preparing the script and saying plainly what was and was not verified.

What did our own measurement of scripts show?

On 2026-10-22 we read the logs of the first ten scripts built this way, on our setup. Across those ten scripts we logged seven failed real runs, spread over five scripts (one script was verify-only). None of the seven failed at a step the dry-run had executed. Six of the seven were prerequisites the dry-run never touched, such as a web address that returned not-found and a folder owned by another user. The seventh was a bug in our own script library. Real runs per script varied from 1 to 4, so we do not quote a total.

That sounds like a clean win for the dry-run, and it is a weaker result than it looks. “Zero failures at a step the dry-run executed” is a metric that cannot fail: the dry-run only protects the steps it runs. After reading the logs we changed what we count, to failures at a prerequisite the dry-run did not execute. The pattern lowers surprises. It does not remove them. These are our figures from one setup, not a benchmark.

Next step

If you want the habits behind this, such as dry-runs that execute their checks and a summary of counts at the end, see what the AccrueDev course covers, including quality gates and production operations, though the script above is free to copy. If your problem is instructions that Claude Code seems to skip rather than actions it blocks, start with why Claude Code ignores your CLAUDE.md.