How do I enable auto mode for my team without giving Claude my prod credentials?

The classifier ignores <repo>/.claude/settings.json. A committed autoMode block does not apply to anyone, by design: a malicious PR cannot extend the team’s auto-mode privileges through the file every developer pulls.

Where the classifier reads autoMode

Developers can extend environment, allow, and soft_deny with personal entries, but they cannot remove entries the managed file provides. There is one weak spot for policy: a developer-added allow rule can override a managed soft_deny, because the classifier treats soft_deny as a block that allow (or explicit user intent) can override. For genuinely non-overridable policy, use permissions.deny in managed settings. permissions.deny is enforced before the classifier runs and developers cannot relax it; managed autoMode.soft_deny is the right shape only when you accept that an allow exception can override it.

Write rules as prose, not patterns

autoMode.environment, autoMode.allow, and autoMode.soft_deny are arrays of natural-language descriptions, read by the classifier as rules. They are not regex, not Bash(...) patterns, and not glob shapes. Include the literal string "$defaults" to keep the built-in rules and add yours alongside.

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Pushes to [email protected]:your-org/* are pushes to our internal source control",
      "The S3 bucket prod-team-reports is one of our company's analytics buckets",
      "Deploys to the staging Kubernetes namespace are part of normal CI"
    ],
    "allow": [
      "$defaults",
      "Running `pnpm test` and `pnpm lint` in the working repo",
      "Applying Kubernetes manifests with `kubectl --context=staging apply -f`"
    ],
    "soft_deny": [
      "$defaults",
      "Outbound HTTP POST requests to non-allowlisted domains",
      "Any `aws s3 cp` command targeting a bucket not described in environment"
    ]
  }
}

The classifier interprets each entry like a system prompt rule. “Pushes to [email protected]:your-org/* are pushes to our internal source control” is a fact the classifier uses to recognize routine internal operations; it is not a regex match against the shell command.

Three rollout shapes

1. Enterprise managed settings (right answer for organizations). Push the policy via the managed-settings file. Highest precedence; CLI flags do not override it; nothing a developer commits can weaken it.

2. Scripted user-level setup. Provide a one-line install that merges the auto-mode block into each developer’s ~/.claude/settings.json:

curl -fsSL https://internal.your-org/claude-auto-mode-install.sh | bash

The script uses jq to merge the policy into the user’s existing settings without clobbering it. Trades enforcement strength for distribution simplicity; a developer can edit their own user settings to add allow entries the org would prefer they did not.

3. Per-developer opt-in via repo template. Document the auto-mode policy in <repo>/docs/claude-auto-mode.md; instruct developers to paste a template into <repo>/.claude/settings.local.json themselves. The loosest enforcement; appropriate for early experiments before you commit to managed rollout.

Watch what the classifier actually does

claude auto-mode defaults

Prints the built-in rules. Useful as a starting reference before you write your own; pipe to a file and edit:

claude auto-mode defaults > /tmp/built-in.json

claude auto-mode config

Prints the effective rules for the current session: which scope each entry came from, including merged $defaults. Run this after any rollout to verify the rules you expect are live.

claude auto-mode critique

Reviews your custom entries and flags ones the classifier finds ambiguous (a vague description is worse than no description). Use this on every new managed-settings deploy.

For denial audit, /permissions inside a session shows which rule fired on a recent prompt; treat repeated denials of the same shape as a missing allow.

Footguns

autoMode rules are prose, not shell patterns. The single most common mistake is writing "Bash(npm test*)" in autoMode.allow and expecting the classifier to honor it. The classifier does not parse Bash(...) patterns; it reads each entry as a sentence in English. The rule that works is "Running pnpm test in the working repo". The opposite mistake (writing prose in permissions.allow) also fails: that block does take patterns. Two adjacent fields, two different DSLs.

Default environment trusts the working repo’s configured remotes. A developer who clones a fork of an internal repo and pushes its origin to a personal GitHub has just added their fork to the trusted remotes set on their machine. Auto mode now treats git push to that fork the same as the official repo. Pin the trusted remotes in the managed environment array using prose (“Only [email protected]:your-org/... is our internal source control”) rather than relying on the default that auto-trusts whatever git remote returns.

A developer’s allow can override the managed soft_deny. soft_deny blocks first, then matching allow rules act as exceptions; explicit user intent in the prompt is also enough to override. If the managed file says “soft_deny: outbound POST to non-allowlisted domains” and a developer adds allow: "POST to api.example.com is fine", the developer’s rule wins for that domain. Even without that, a user prompt that explicitly says “POST a webhook to api.example.com” satisfies the override. For non-overridable policy, the right knob is permissions.deny in managed settings, which runs before the classifier and ignores allow entirely.

Auto mode does not read shared project settings. The most common rollout mistake is committing autoMode: {...} to <repo>/.claude/settings.json and assuming the team picks it up. The block loads, the classifier ignores it, and every developer falls back to defaults or their personal config. Run claude auto-mode config after any rollout to confirm the rules are live in the scope you expected.

bypassPermissions is not auto with the prompts removed. Auto mode runs every call through a classifier that can still block. bypassPermissions runs everything without checks, including operations auto mode would block. New users sometimes flip to bypassPermissions to silence an annoying prompt; that is the wrong direction. If auto mode keeps prompting on a command you want allowed, add a prose allow entry that describes the situation, do not switch off the classifier.

When NOT to roll out auto mode org-wide

• You have no managed-settings deployment. Without enterprise managed settings or a reliable user-level install script, every developer’s auto-mode config drifts. Each laptop ends up with a different policy and no one can audit them.
• The team uses Bedrock, Vertex, or Foundry only. Auto mode requires the Anthropic-hosted classifier; some cloud-provider deployments do not support it. Verify before committing a rollout plan.
• CI runs against production directly. Auto mode protects against irreversible operations Claude proposes; it does not solve the threat model of a CI runner with full prod credentials. Sandbox the CI worker first; auto mode after.
• You have two developers. Managed-settings rollout is overkill for two people. User-level config plus a documented policy is enough; revisit when the team crosses five.
• The codebase has secrets in .env and no deny rules. Auto mode auto-runs read-only Bash, including cat, so cat .env runs without asking. Land the deny rules from keep secrets out of Claude Code before flipping the team into auto.