Claude Code Auto Mode: Tune the Permission Classifier

The first hour I ran auto mode it blocked a push to a repository I own, on a branch I created, in an organisation I had used every day for a year. Nothing was wrong. The classifier simply had no way to know that github.example.com/acme-corp was mine, so from where it sat the push was an upload to a host it had never been told about.

That is the whole mental model, and it is worth internalising before you start adding allow rules: the classifier is not judging the command, it is judging the destination against a boundary you have not drawn yet. This post covers where that boundary is defined, the precedence order inside the classifier, the CLI subcommands that let you see what is actually in effect, and the one configuration mistake that silently removes every built-in security rule.

Auto mode is a second gate, not a replacement for the first

The permissions system still runs first. Deny rules block before the classifier is ever consulted and cannot be overridden by it or by anything you say in conversation. Explicit ask rules also run first and always force a prompt. Only what survives both reaches the classifier, which then decides whether the action is safe enough to run unattended.

That ordering matters for anything that must never happen. If the requirement is genuinely absolute, express it as permissions.deny in managed settings — a classifier is a model making a judgement, and a policy boundary should not be a judgement call. Use the classifier for the enormous middle ground where the honest answer is that it depends on where the command is pointing.

Four tiers decide every call, in this order

Inside the classifier the precedence is fixed, and knowing it tells you which list to edit when something is wrong:

1. hard_deny blocks unconditionally. Neither user intent nor an allow exception clears it. The built-in list here is the data-exfiltration rule.
2. soft_deny blocks next. These are destructive actions — force push, deleting remote branches, curl piped into a shell, production deploys — that your explicit intent can clear.
3. allow rules then act as exceptions that override matching soft_deny rules.
4. Explicit user intent overrides whatever soft blocks remain, but only when your message directly and specifically describes the exact action.

That last tier is narrower than people expect. Asking Claude to clean up the repo does not authorise a force push; asking it to force-push this branch does. A general request is not intent, which is why vague prompts get blocked and precise ones do not.

autoMode.environment fixes most false positives

For most teams this is the only field you need. It tells the classifier which repos, buckets, hosts and registries are inside your boundary, and by extension what external means — anything not listed is a potential exfiltration target. The entries are prose, not regex and not tool patterns. Write them the way you would describe your infrastructure to a new engineer on their first day.

// ~/.claude/settings.json — the classifier does NOT read
// .claude/settings.json or .claude/settings.local.json, because
// both live in the repo and a build step could inject allow rules.
{
  "autoMode": {
    "environment": [
      "$defaults",
      "Organization: Acme. Primary use: software development",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Internal package registry: npm installs route through artifacts.example.com",
      "Sensitive remote targets: the prod-* Kubernetes namespaces",
      "Protected IaC scopes: everything under infra/terraform/prod/"
    ]
  }
}

The literal string of dollar-sign defaults splices the built-in entries in at that position, so your custom lines sit before or after them and you keep inheriting updates as the built-in list changes across releases. A reasonable rollout is to start with the defaults, add your source-control org and key internal services — which clears the most common blocks immediately — then add domains and buckets, and fill in the rest as denials come up.

Where the classifier reads its config, and the repo it deliberately ignores

The classifier reads autoMode from user settings, from managed settings, and from an inline settings payload. It does not read it from .claude/settings.json or .claude/settings.local.json. Both of those live inside the repository, and a checked-in file or a build step could otherwise inject its own allow rules — a supply-chain hole that would let a cloned repo widen its own permissions. If you have an autoMode block in a local project file today, move it to your user settings; it stopped being read in v2.1.207.

Three ways to draw a boundary, from softest to hardest:

// A content-scoped ask rule is evaluated BEFORE the classifier
// and always prompts, even in auto mode. This is how you keep a
// human checkpoint on the two actions that leave your machine
// while auto mode handles everything else.
{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

See what is actually in effect before you change anything

Four subcommands turn this from guesswork into reading. The one I use most is config, because it prints the merged result rather than what you wrote — the difference between the two is where most confusion lives.

# Print the built-in rules as JSON — read these before you
# ever replace a list, because replacing one discards them.
claude auto-mode defaults

# Read one rule without piping through jq (v2.1.208+).
# Matching is a case-insensitive prefix on the rule label.
claude auto-mode defaults --label 'Git Destructive'

# What the classifier ACTUALLY uses: your settings merged over
# the defaults, with "$defaults" expanded in place.
claude auto-mode config

# Ask Claude to critique your custom rules — it flags entries
# that are ambiguous, redundant, or false-positive machines.
claude auto-mode critique

# Remove the autoMode block from ~/.claude/settings.json.
# Managed settings and --settings rules still apply.
claude auto-mode reset --yes

The narrow-allow-rule hole, and classifyAllShell

By default a narrow shell allow rule stays in effect in auto mode and resolves before the classifier runs. Claude Code suspends only the broad rules that grant arbitrary execution, such as a wildcard Bash rule or a wildcarded interpreter. That leaves a real gap: a narrow rule can pass a destructive argument the rule's prefix never anticipated — a script path, an unexpected flag — straight through without the classifier ever seeing it.

Setting autoMode.classifyAllShell to true suspends every Bash and PowerShell allow rule while auto mode is active, so the classifier evaluates each shell command regardless of your allow list. The trade is latency for coverage: a command an allow rule would have approved instantly now waits for a classifier decision, and each one counts as a classifier call. It applies only while auto mode is active and your allow rules behave normally in every other mode.

Reading denials instead of guessing at them

Open the permissions dialog and select the Recently denied tab; every classifier denial is recorded there, and pressing r marks one for retry so Claude is told it may run that call again. The reason shown is usually the fixed text about being blocked by the classifier rather than an explanation, because the classifier scores actions on an internal severity scale instead of writing prose. Pick the fix from what the call was reaching for:

• A destination Claude needs throughout the task — a registry, an internal domain, a repo host — belongs in autoMode.environment.
• A command you want to run unreviewed from now on belongs in an allow rule.
• A one-off you genuinely intended just needs you to state that intent specifically in your next message and let Claude retry.

Auto mode is worth the setup, but treat the environment block as documentation of your infrastructure rather than a list of workarounds. Every entry you add is a claim about what is inside your boundary, and the classifier will act on it for every session afterwards. Write the entries you would be comfortable defending in a review, keep the built-in rules spliced in, and put the things that must never happen in a deny rule where no judgement is involved at all.