Claude Code starts in auto mode by default — all six permission modes compared

A classifier block is not an inline prompt. You approve it afterwards, somewhere else. The docs put it this way: "Claude Code shows a notification and lists the action in /permissions under the Recently blocked tab, where you can approve the action so Claude may retry".

That approval is not a rule, though: "Approving an action doesn't add a permission rule. In auto mode, a retried action goes through the check again, so it can be blocked again."

Whether anything can clear the block depends on which tier the matched rule sits in. Inside the classifier, precedence runs in four tiers.

So the first step is finding out which tier applies. The text in square brackets in the denial is the rule's name, so you can look that rule up.

# Print the full default rule lists as JSON
claude auto-mode defaults

# Read one rule's full wording by label
claude auto-mode defaults --label 'Git Destructive'

For a soft_deny rule, naming the action and the specific thing that makes it dangerous clears it — "Naming the verb alone clears nothing". But "an approval covers the destructive action you named", so it is one action at a time. To stop approving a routine pattern repeatedly, add it to autoMode.allow.

For a hard_deny rule there is no route through inside auto mode. The documented remedy is one line: "To run a step it won't clear, leave auto mode and answer the permission prompt." Cycle the mode with Shift+Tab and approve the ordinary prompt.

One more thing to know: entering auto mode drops broad allow rules — blanket Bash(*), wildcarded interpreters such as Bash(python*), package-manager run commands, and Agent and Monitor rules. "Narrow rules like Bash(npm test) stay in effect", so scope a rule tightly if you want it to survive.

For how the modes differ, see Claude Code starts in auto mode by default and all six permission modes compared.

When Read works and only Edit is denied, the fastest thing to rule out is a setting that applies to the write tools alone.

permissions.blockWritesOutsideWorkingDirectories, added in v2.1.314, makes Write, Edit and NotebookEdit refuse paths outside the working directories in every permission mode. Read is not covered, which is exactly why an identically written Read rule still works.

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true
  }
}

With it on, an allow rule will not get a write through outside the working directories. Either bring the path in with --add-dir or permissions.additionalDirectories, or turn the setting off.

If that is not it, the dontAsk specification is the next place to look. The documentation says that even in dontAsk, "Actions matching your permissions.allow rules and calls approved by a PreToolUse hook run too" — matching an allow rule is supposed to work. These are denied even with a matching allow rule:

The pattern itself is worth re-reading too. A single-segment directory pattern such as Edit(src/**) matches only the src directory in the working directory; use Edit(**/src/**) to match one at any depth. And an allow rule on a path reached through a symlink applies only when both the requested path and the resolved path match.

Writes to protected paths are not auto-approved in any mode except bypassPermissions. For how the modes differ, see Claude Code starts in auto mode by default.

It does not. Per the documentation, a subagent's actions go through the decision order again: "While the subagent runs, each of its actions goes through the same decision order as in the parent session, with the same block and allow rules."

What carries is a rule. A one-off approval you gave in conversation is not a rule, so it has no effect on the subagent's evaluation. For an action that should pass consistently, put it in permissions.allow; allow, ask and deny rules are step one of the decision order and resolve immediately on a match.

The classifier looks at subagents at three points:

Other cases route to the classifier despite an allow rule:

• Writes to protected paths
• rm and rmdir removals targeting a critical path, which no allow rule approves
• MCP tools marked requiresUserInteraction, and connector tools your organization set to ask
• Ask rules that match on a command's content, such as Bash(git push *), which fall back to a permission prompt

The permissionMode detail is the easiest to miss: setting it in a subagent's frontmatter has no effect. For how the modes differ, see Claude Code starts in auto mode by default.

The documentation's "How the classifier evaluates actions" describes auto mode as a fixed four-step decision order where the first matching step wins. Which step your read is landing on is what tells you why it stopped.

Step 2 is the behavior you were expecting: "Read-only actions and file edits in your working directory are auto-approved." A read inside the working directory does not reach the classifier at all. So if one is still being blocked, it is hitting one of that step's exceptions.

The likely causes, roughly in order:

1. Server-side classifier review is in effect. Listed as an exception to that same step: "In a session with server-side classifier review, read-only and sandboxed shell commands wait for that review and are blocked if it flags them." A read-only command waiting on a review and then being blocked is documented only here.
2. The file is outside your working directories. "The first read outside the working directories" prompts you. A context file that lives outside the repository qualifies. Adding it with /add-dir or the additionalDirectories setting changes that.
3. A deny rule matches. Those resolve at step 1, and deny rules block in every mode.
4. The read is from a network (UNC) path. That prompts you even when an allow rule matches.

There is also a documented reason why the denials read as unexplained: "If the classifier blocks, Claude receives the reason. In most sessions the reason names the rule the classifier matched, such as [Data Exfiltration], rather than giving a written explanation."

More detail: Claude Code permission modes.

There is one — four, in fact, all documented on the auto mode configuration page.

First, why "yes" doesn't work. Per the docs, the explicit user intent that overrides a classifier soft_deny is a message that directly and specifically describes the exact action Claude is about to take. General requests don't count: asking Claude to "clean up the repo" doesn't authorize force-pushing, but asking it to "force-push this branch" does. A bare "yes" names no action, so it isn't treated as intent.

The options:

autoMode.allow goes in ~/.claude/settings.json. The classifier does not read autoMode from .claude/settings.json or .claude/settings.local.json — both live in the repo directory, so a checked-in repo could otherwise inject its own allow rules. Include the literal "$defaults" in the array to keep the built-in rules.

{
  "autoMode": {
    "allow": [
      "$defaults",
      "git commit --amend --reset-author on unpushed commits is allowed: it only corrects authorship and never rewrites published history"
    ]
  }
}

To read the full wording of the rule that fired, run claude auto-mode defaults --label 'Git Destructive' (v2.1.208 or later). That rule also clears "when the user asked to amend/reword/fixup", so how you phrase the request can be enough on its own.