Configuring Auto Mode for Organizations

Why the Classifier Blocks Routine Operations

The auto-mode classifier trusts your working directory and the remotes configured for it when the session starts. Everything else is potentially external. If your developers push to an organization GitHub org, write to internal S3 buckets, or deploy to an internal Kubernetes cluster, the classifier treats those as suspicious until you tell it otherwise. The result: repeated blocks on operations that are completely routine for your team.

The autoMode settings block tells the classifier which infrastructure is yours. Adding your organization's repos, trusted domains, and key services resolves most false positives without loosening any behavioral rules.

Where the Classifier Reads Configuration

The classifier reads from two sources: CLAUDE.md content (for behavior rules and conventions) and the autoMode settings block (for infrastructure). CLAUDE.md instructions like "never force push" steer both Claude and the classifier simultaneously — write them there for project conventions.

For infrastructure configuration, the classifier reads autoMode from these scopes only: user settings (~/.claude/settings.json), local project settings (.claude/settings.local.json), managed settings, and per-invocation CLI/SDK settings. It does not read autoMode from shared project settings (.claude/settings.json) — a checked-in repo cannot inject its own classifier allow rules.

The environment Field: Three Entry Types

The autoMode.environment field contains prose descriptions that tell the classifier what your environment looks like. Entries are natural language, not regex or tool patterns. Write them the way you would describe your infrastructure to a new engineer joining the team.

Three kinds of entries serve different purposes:

• Context slots: Describe your organization, what Claude Code is primarily used for, your cloud providers, repository visibility, CI/CD targets, and similar background information. These don't have specific rules targeting them — they shape the classifier's understanding of every other decision.
• Trust slots: Name what the classifier treats as inside your boundary. Source control orgs, trusted internal domains, cloud buckets, internal services, and package registries. Everything not named here is treated as potentially external.
• Sensitivity slots: Name what the protective rules treat as high-risk. Sensitive data locations (with their allowed audiences), sensitive remote targets (production namespaces, production hosts), and protected IaC scopes. Each defaults to a broad heuristic (anything named "prod" is treated as production) — naming concrete values narrows the heuristic to the specific names.

The $defaults Sentinel

Each of the four configuration arrays (environment, allow, soft_deny, hard_deny) comes with a built-in default list. To extend those defaults with your own entries rather than replacing them, include the string \"$defaults\" in your array:

{ "autoMode": { "environment": [ "$defaults", "Source control: github.example.com/acme-corp and all repos under it", "Trusted internal domains: *.corp.example.com", "Key internal services: Jenkins at ci.example.com" ] } }

Omitting \"$defaults\" replaces the entire built-in list for that section. Replacing soft_deny without \"$defaults\" discards the built-in blocks for force push, curl|bash, and production deploys. Replacing hard_deny without \"$defaults\" discards the data exfiltration and auto-mode bypass rules. This is almost never what you want.

The Four Rule Tiers

Inside the classifier, precedence works in four tiers:

• hard_deny: Unconditional security boundaries. User intent and allow exceptions do not apply. Use for things that must never happen — sending repository contents to third-party code-review APIs, writing to secret manager paths, exfiltrating PII.
• soft_deny: Destructive actions that explicit user intent can clear. If you say "run database migrations now" in your next message, a soft_deny block for migrations is lifted for that specific action. Use for high-risk operations that are occasionally legitimate.
• allow: Exceptions to soft_deny rules. Use when a routine operation keeps getting blocked because it matches a soft_deny pattern.
• Explicit user intent: General requests like "clean up the repo" do not authorize force-pushing. A specific request like "force-push this branch" does — explicit user intent overrides the remaining soft_deny blocks for that action.

classifyAllShell

By default, narrow Bash allow rules like Bash(npm test) carry over into auto mode and resolve before the classifier runs. Set autoMode.classifyAllShell: true to route every shell command through the classifier regardless of your allow list. This trades latency for coverage: a command that an allow rule would have instantly approved now waits for a classifier decision, but the classifier can catch dangerous arguments that the rule's prefix didn't anticipate.

Inspecting and Debugging Your Configuration

Three CLI subcommands help you validate and debug:

• claude auto-mode defaults — prints the built-in environment, allow, soft_deny, and hard_deny lists as JSON. Run this before writing any custom rules to understand what you're extending or replacing.
• claude auto-mode config — prints the effective configuration with your settings applied, with \"$defaults\" expanded in place. Run this after saving changes to confirm the classifier will see what you intend.
• claude auto-mode critique — reviews your custom rules and flags entries that are ambiguous, redundant, or likely to cause false positives. Useful before rolling out configuration to your organization.

When actions are blocked, find them in /permissions under the Recently denied tab. Press r on a denied action to mark it for retry. Use the classifier's stated reason — shown alongside the blocked action in the transcript and on the Recently denied tab — to decide whether the fix is an environment entry, an allow exception, or explicit intent in your next message. Repeated denials for the same destination almost always mean a missing entry in autoMode.environment.

A Recommended Rollout

Start with the defaults and add your source control org and key internal services first — this resolves the most common false positives like pushing to your own repos. Add trusted internal domains and cloud buckets next. Fill in sensitive data locations and protected IaC scopes as you encounter relevant blocks. Run claude auto-mode config after each change to confirm the effective configuration.