Claude Code's Auto Mode Tab: Editing Classifier Rules from /permissions

What shipped, and when

Claude Code v2.1.246, released 25 August 2026, added an Auto mode tab to the /permissions dialog. Anthropic's own auto mode configuration reference describes it plainly: it lets you view and edit the classifier's rules "without opening a settings file." Before this, changing what auto mode allows, blocks or treats as trusted meant hand-editing an autoMode block in JSON, in ~/.claude/settings.json or a managed settings file, and remembering the exact array structure each time.

If you have not yet read up on what auto mode actually is or how to configure its trusted infrastructure, those two articles cover the underlying mechanics this tab is a UI on top of. This piece is specifically about the tab: what it shows, what you can do from it, and how it fits into the classifier's decision-making that both of those earlier pieces already describe.

The tab only appears when auto mode is available to your session, which it is by default for Pro, Max and Team plans as of mid-August 2026, unless an administrator has set permissions.disableAutoMode in managed settings.

Opening it

Run /permissions as you normally would to review Bash, file and MCP permission rules, then select the Auto mode tab. It sits alongside whatever other tabs your session shows, including Recently denied, covered below.

What the tab actually lists

The tab lists the same four fields the autoMode settings block accepts, pulled together from every scope the classifier reads:

Each rule is a plain-English sentence, not a tool pattern like Bash(rm *). A claude auto-mode config dump makes the shape concrete. One of the built-in soft_deny entries reads, in full:

Git Destructive [named+specifics, must name: the destructive operation and its target]:
Force pushing (git push --force), deleting remote branches, tags, or releases, or
rewriting remote history. Also git commit --amend when the commit being rewritten is
not the agent's own unpushed work: either no prior git commit is visible (HEAD
pre-dates the session), or a git push of the current branch is visible after the
most recent commit (it has been pushed). Clears when the user asked to
amend/reword/fixup, or when it is a message-only reword (--amend -m …, nothing
newly staged) of a commit the agent visibly created this session.

That is the level of detail the Auto mode tab surfaces for every built-in rule, not a summary of it. Reading through the tab once is a genuinely useful way to understand what auto mode is actually checking for, beyond the one-line descriptions in Anthropic's docs.

Scope and read-only entries

The tab pulls rules from every scope the classifier reads: your personal ~/.claude/settings.json, managed settings your organisation deploys, and inline JSON passed via --settings. Entries from managed settings or --settings show up read-only, since only an administrator or the invoking process controls those scopes. Anything you add, edit or delete from the tab writes to your own ~/.claude/settings.json, the same file /auto-mode-setup writes to when you accept its draft.

What you can actually do from the tab

Three concrete actions, per Anthropic's documentation:

Add, edit or delete a rule in allow, soft_deny or hard_deny. The first time you add a rule to a section that previously had none of your own, Claude Code automatically inserts the literal "$defaults" marker into your list for that section. This matters because omitting "$defaults" from an array replaces the entire built-in list for that section, so the tab protects you from silently discarding Anthropic's force-push, curl | bash, or data-exfiltration protections the moment you write your first custom rule.

Turn a section's built-in rules off or on. Once you have at least one rule of your own in a section, the tab exposes a toggle for that section's defaults. Toggling it off removes "$defaults" from your list; toggling it back on re-adds it. You need at least one custom rule before the toggle appears, which is a deliberate guardrail: there is no path to an empty, defaults-off soft_deny list by accident.

Edit environment as one document. Unlike the other three sections, environment opens as a single block of text in your editor rather than a list of discrete rules, because environment entries read more like a prose brief than a set of independent policies. If you have not configured any environment entries yet, Claude Code first asks whether to replace the built-in environment, then opens your editor pre-filled with the full built-in text so you are editing from something concrete rather than a blank page. Saving replaces your autoMode.environment array with whatever the document contains, so include the "$defaults" line yourself if you want to keep the built-in entries alongside your edits.

A worked example

Say auto mode keeps blocking a routine deploy to your team's staging namespace, and you have confirmed staging is genuinely low-risk (isolated from production, resets nightly). From /permissions, Auto mode tab:

1. Select Add rule under allow.
2. Write the exception in plain language: Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly.
3. Save. Claude Code inserts "$defaults" into your allow list automatically, since this is your first custom entry there.

The equivalent hand-edited ~/.claude/settings.json looks like this, and the tab is now doing exactly this write for you:

{
  "autoMode": {
    "allow": [
      "$defaults",
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly"
    ]
  }
}

Confirm it took effect with claude auto-mode config, which prints the classifier's effective rule set with "$defaults" expanded in place, regardless of whether you edited the file directly or used the tab.

Recently denied: the log next to the editor

The Auto mode tab tells you what the classifier is configured to do. The Recently denied tab, alongside it in /permissions, tells you what it has actually blocked in this session. Each denial is a candidate for one of three fixes:

• A destination the whole task needs (an internal domain, a package registry, a repository host): add it to autoMode.environment from the Auto mode tab.
• A command you want to stop reviewing entirely: add an allow rule.
• A one-off action you genuinely meant: press r on the denied entry to mark it for retry. Claude Code sends a message telling the model it may retry that specific call and resumes the conversation, no settings change required.

The reason shown next to a denial is usually the fixed text Blocked by classifier, since the classifier scores actions on an internal severity scale rather than writing an explanation for every call. Some sessions run a classifier model that does write a short explanation; when one appears, treat it as a hint about which destination or intent the classifier was missing, not as documentation of the rule itself.

Precedence still works the same way underneath

Nothing about the tab changes how the classifier actually decides. The order is still fixed:

1. hard_deny blocks unconditionally. Neither an allow entry nor stated user intent overrides it.
2. soft_deny blocks next, but an allow exception or sufficiently explicit user intent can clear it. "Force-push this branch" clears it; "clean up the repo" does not, because the classifier requires the specific action to be named, not implied by a general request.
3. allow rules act only as exceptions to matching soft_deny rules.
4. permissions.deny and permissions.ask rules, set separately from autoMode, run before the classifier is consulted at all and cannot be overridden by anything above.

If a boundary genuinely must never be crossed regardless of what a user types into a prompt, it belongs in permissions.deny, not in autoMode.hard_deny. The classifier is still a model making a judgment call; permissions.deny is enforced by Claude Code itself before the classifier ever runs.

The tab versus hand-editing settings.json

Nothing the tab does is impossible to do by hand, editing ~/.claude/settings.json directly still works exactly as before, and organisations distributing rules through managed settings still have to do that as JSON. What the tab removes is the two mistakes that are easy to make by hand:

• Forgetting "$defaults". Writing your first custom rule directly into a JSON array is one missing string away from silently discarding Anthropic's built-in protections for that section. The tab inserts it automatically the first time you add a rule, and only exposes a defaults on/off toggle once that safety net already exists.
• Malformed JSON. A settings file with a syntax error is not just a broken auto mode configuration, it can break other settings that live in the same file. Editing through the tab means every save is already valid.

The trade-off is scope. The tab edits ~/.claude/settings.json only, so a personal customisation is exactly that, personal. Rolling out autoMode rules across a whole organisation, per configuring trusted infrastructure, still means writing the JSON directly and deploying it as managed settings, since there is no equivalent tab for editing another person's configuration.

Troubleshooting

The Auto mode tab is not showing up in /permissions. Confirm you are on Claude Code v2.1.246 or later (claude --version), and that auto mode is actually available to your session. If your organisation has set permissions.disableAutoMode in managed settings, the tab does not appear, and no personal setting can bring it back.

I added a rule but it does not seem to apply. Run claude auto-mode config to confirm your rule appears in the effective configuration. If it does not, check whether a higher-precedence scope, managed settings in particular, has already replaced the section you edited without "$defaults", which would silently discard entries from lower scopes for that section.

The toggle to turn off built-in rules is missing. You need at least one custom rule in that section before the toggle appears. Add a rule first; the toggle for that section's defaults shows up once you have.

A rule I want to edit is greyed out. It came from managed settings or --settings, and only an administrator or the invoking process controls that scope. Add your own overriding rule in allow, soft_deny or hard_deny from your personal settings instead of trying to edit the managed one directly.

I edited the environment document and lost my custom entries. If you skip the "$defaults" line when saving the environment document, you replace the whole array, including anything you had added previously in JSON. Re-add "$defaults" and your custom lines together, or run claude auto-mode defaults first to see the built-in text and copy from there.

Where to go next

For what auto mode actually blocks by default and which sessions start in it, see Claude Code's auto mode is now the default. For the full mechanics of autoMode.environment, the three override lists, and rolling this out across a team through managed settings, see how to configure auto mode's trusted infrastructure. Both articles cover ground this piece deliberately does not repeat: the tab is a new way to edit the same configuration, not a new configuration model. Browse the current Claude Code catalogue at getclaudeskills.com/platforms/claude-code, or everything indexed at getclaudeskills.com/skills.

Verified 27 August 2026 directly against Claude Code's own auto mode configuration reference at code.claude.com/docs/en/auto-mode-config, including the "Edit rules from /permissions" section, and the v2.1.246 changelog entry at code.claude.com/docs/en/changelog.