How to Configure Claude Code Auto Mode's Trusted Infrastructure

The default is narrower than most teams expect

Since 14 August 2026, auto mode is the default permission mode for new Claude Code sessions on Pro, Max and Team plans. Instead of a manual prompt before every file edit, shell command and network request, a classifier model checks each action against your request and blocks anything that looks like it escalates beyond what you asked for or reaches outside infrastructure it recognises as yours.

That second part is the part teams hit first. Out of the box, the classifier trusts exactly two things: your working directory, and the git remotes already configured for the repo you're in. Push to your own fork, fine. Push to a colleague's fork, write to your team's shared S3 bucket, call an internal API on your company's network, and the classifier has no way to know that's routine rather than suspicious, so it blocks it. Not because anything's wrong, but because nobody told it what "yours" actually means.

autoMode.environment is that answer. This guide covers how to configure it properly for a team, plus the three related override lists most people don't discover until they're already annoyed by a false positive.

Where the classifier actually reads its configuration

Before touching autoMode.environment, it's worth knowing which settings file the classifier reads it from, because this trips people up. Per Anthropic's auto mode configuration reference, the classifier reads autoMode from:

Notice what's missing: .claude/settings.json and .claude/settings.local.json, both of which live inside the repository itself, are not read for autoMode. That's deliberate. If a checked-in settings file could grant its own repo extra trust, anyone who can open a pull request could quietly widen what the classifier allows. Before Claude Code v2.1.207, .claude/settings.local.json was still read for this; that changed specifically to close this gap, so if you're carrying an old autoMode block in a local settings file, move it to ~/.claude/settings.json instead.

For rules that should follow the project rather than the developer, the classifier separately reads your CLAUDE.md content. An instruction like "never force push" written there steers Claude and the classifier at the same time. Reach for autoMode.environment specifically for cross-project infrastructure, your org's source control, shared buckets, internal domains, not for single-repo conventions that belong in CLAUDE.md.

Entries from every scope combine. A developer can add personal entries on top of what managed settings provides, but can't remove what managed settings grants. That combination is additive rather than a strict hierarchy: because allow rules act as exceptions to soft_deny rules inside the classifier, a developer's own allow entry can override an organisation's soft_deny entry. Keep that in mind if you're relying on soft_deny at the org level to hold a boundary; if it needs to be absolute, it belongs in permissions.deny instead, which runs before the classifier and nothing overrides it.

Setting autoMode.environment

For most teams, environment is the only field worth configuring. It's an array of plain-English descriptions, not regex or tool-call patterns, read by the classifier as natural-language context. Anthropic's own framing is to write it "the way you would describe your infrastructure to a new engineer."

A minimal team rollout, added to managed settings:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}

"$defaults" matters here. It splices Anthropic's built-in entries into the array at that position, so your custom lines add to the defaults instead of replacing them, and you keep inheriting updates to the built-in list as new Claude Code versions ship. Leave it out only if you intend to fully own the section yourself; the docs' recommended way to do that safely is to run claude auto-mode defaults first, copy the printed defaults into your own settings, then edit from there with full visibility into what you're keeping or dropping.

What a thorough environment section covers

Per the reference docs, a complete rollout typically names:

• Organisation and primary use, your company name and whether Claude Code is mainly used for software development, infrastructure automation, or data engineering
• Source control, every GitHub, GitLab or Bitbucket org your developers actually push to
• Cloud providers and trusted buckets, the bucket names or prefixes Claude should be able to read and write
• Trusted internal domains, hostnames for internal APIs, dashboards and services, *.internal.example.com-style patterns work
• Key internal services, CI, artifact registries, incident tooling
• Internal package registry, the private npm or PyPI mirror installs should route through, so an install that bypasses it for a public registry gets flagged
• Sensitive data locations and audiences, buckets, databases or paths holding regulated or confidential data, and who each may be shared with (this and the internal-registry entry require Claude Code v2.1.195 or later; earlier versions read them as plain context without the built-in rules that target them)
• Sensitive remote targets, namespaces or hosts that count as production, so a remote shell or port-forward into them still needs your explicit approval
• Protected IaC scopes, infrastructure resources whose apply or destroy should always require you to name the change explicitly

You don't need every line on day one. Anthropic's own suggested rollout is to start with the defaults, add source control and key internal services first, since that resolves the most common false positive (Claude pushing to your own org's repos), then layer in buckets and domains as they come up.

One heuristic worth knowing before you configure it: by default the classifier treats any host or namespace whose name contains prod or production as a sensitive remote target, so protective rules are active immediately, before you've named anything. Naming concrete targets in the sensitivity slots replaces that broad heuristic with your specific list instead of adding to it.

The three override lists

Beyond environment, three more autoMode fields let a team replace the classifier's built-in judgment calls rather than just feeding it context:

• hard_deny: unconditional boundaries. Neither user intent nor an allow entry can override these.
• soft_deny: destructive-by-default actions that explicit user intent can still clear. Force pushes and production deploys ship here by default.
• allow: named exceptions to soft_deny rules.

{
  "autoMode": {
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

Same rule as environment: omit "$defaults" from any one of these three arrays and you discard the built-in rules for that specific section, including, for soft_deny, the built-in rules against force pushes and curl | bash, and for hard_deny, the built-in data-exfiltration rule. Each list is independent, so setting environment alone doesn't touch the other three, they keep their defaults untouched.

Precedence inside the classifier runs in a fixed order: hard_deny first and absolute, then soft_deny, which an allow entry or a sufficiently explicit user request can clear, and finally explicit user intent as the last override for anything still blocked by a soft rule. "Explicit" is doing real work in that sentence: Anthropic's documentation is specific that a general request like "clean up the repo" doesn't authorise a force push, but "force-push this branch" does. General intent doesn't count; naming the specific action does.

classifyAllShell: closing the narrow-rule gap

By default, existing narrow Bash or PowerShell allow rules, Bash(npm test), for instance, still resolve before the classifier runs even inside auto mode. Auto mode only suspends the broad rules, Bash(*) or a wildcarded interpreter. That means a narrow rule can still let a destructive argument through if it's outside what the rule's prefix anticipated, since the classifier never sees a command that already matched an allow rule.

{
  "autoMode": {
    "classifyAllShell": true
  }
}

Setting this to true routes every Bash and PowerShell command through the classifier while auto mode is active, regardless of your existing allow list. It costs latency, a command an allow rule would have approved instantly now waits on a classifier call, and each shell command becomes a billable classifier check on providers where those count. Requires Claude Code v2.1.193 or later; earlier versions ignore the key.

Verifying your configuration actually took effect

Three CLI subcommands exist specifically for this, and skipping them is the most common way teams end up debugging a setting that was never applied:

# Print Anthropic's built-in rules, before your settings are applied
claude auto-mode defaults

# Print what the classifier is actually using right now,
# your settings layered over the defaults
claude auto-mode config

# Get feedback on custom allow/soft_deny/hard_deny rules you've written
claude auto-mode critique

Run claude auto-mode config after saving any change to managed or personal settings, and confirm your new entries appear in the output. As of Claude Code v2.1.198, this prints the full three-part environment breakdown (context, trust and sensitivity slots); versions before that print only the first five trust slots, so an older client can make a correctly configured setup look incomplete. claude auto-mode critique is worth running once after writing your own soft_deny or hard_deny rules specifically, it reviews them for ambiguity and rules likely to cause false positives, which is easy to miss when you're writing prose rules rather than testable code.

Troubleshooting

A developer keeps hitting the same block on infrastructure that should be trusted. This is almost always a missing environment entry, not a bug. Add the specific destination, then re-run claude auto-mode config to confirm it's present before assuming it's fixed. If the block happens repeatedly for the same destination across multiple developers, that's the signal it belongs in managed settings rather than everyone's personal ~/.claude/settings.json.

You set autoMode.environment in .claude/settings.json and nothing changed. That file isn't read for autoMode at all, only ~/.claude/settings.json and managed settings are. Move the block.

An org-level soft_deny rule keeps getting bypassed. Check whether a developer's personal allow entry is clearing it, since allow rules override matching soft_deny rules by design, and that combination is additive across scopes rather than a strict top-down hierarchy. If the rule needs to be unconditional, move it to hard_deny, or better, to permissions.deny, which the classifier never gets a chance to override in the first place.

You're not sure whether a rule change actually reduced false positives, or just moved them. Use /permissions and the Recently denied tab to see what auto mode has actually blocked in a session. That's the ground truth for what to add next, rather than guessing at what infrastructure might be missing.

Where to go next

For the change that made this configuration worth doing in the first place, see Claude Code's Auto Mode Is Now the Default, which covers what the classifier blocks out of the box and how to opt back into manual review entirely. If your team is also running self-hosted Claude Code runners, the same managed-settings distribution mechanism described here is the one to use for pushing autoMode configuration across a fleet. Browse the current Claude Code skill catalog at getclaudeskills.com/platforms/claude-code, or everything indexed at getclaudeskills.com/skills.