Claude Code auto mode became the default for every interactive terminal and VS Code session on September 28, 2026, on every plan and every provider. Open a session without a permission mode configured and it now starts in auto mode instead of the manual, reads-only mode that used to be the fallback. That change shipped in version 2.1.284 of the Claude Code changelog, alongside a fix to a plugin permission gap. Three days earlier, version 2.1.283 added two managed settings for controlling which models a team can run at all. None of it is optional for anyone administering Claude Code across a team, and the settings to respond with sit across three different docs pages that don't cross-reference each other.
What changed on September 28: auto mode becomes the default
Before this release, the default depended on how a session connected. Claude Code's changelog shows version 2.1.283 already made auto mode the fallback for interactive sessions running on third-party providers or with telemetry turned off, but only when no permission mode was configured. Version 2.1.284 removed that carve-out entirely: interactive terminal and VS Code sessions now start in auto mode with no permission mode set, full stop, regardless of plan or provider. permissions.defaultMode still overrides it if an admin or a developer has set one.
Claude Code ships six permission modes, according to Anthropic's permission-modes reference. default is manual and reads only. acceptEdits and plan sit in between. auto runs everything, backed by background safety checks instead of prompts. dontAsk sits at the restrictive end: it allows reads and pre-approved tools only, and denies anything that would otherwise prompt, which suits locked-down CI and scripts. bypassPermissions sits at the opposite end and skips checks altogether. The gap between default and auto is the whole story here: a session that used to start read-only now starts able to do everything the classifier lets through, and that's a meaningfully wider blast radius for anyone who hasn't looked at their managed settings recently.
Claude Code isn't alone in moving a default this quarter. GitLab shipped a default permission policy for AI agent tool access that gates writes and deletes behind approval while reads run free, and GitHub Copilot's deny, ask, allow permission framework makes an admin's restriction impossible for a developer to loosen locally. Anthropic's change is about which mode a session starts in rather than which tools it can call, but the direction across all three is the same: defaults are moving from developer-configured to admin-configured, a pattern covered more broadly on HighCircl's AI in the engineering workflow: tools, permissions and policy hub.
The same release closed a plugin permission gap
The same changelog entry fixed a separate issue: plugins from marketplaces, claude.ai, and npm were pre-approving their own tools through allowed-tools even under a managed allowManagedPermissionRulesOnly setting meant to stop exactly that. After 2.1.284, only plugins from an official Anthropic source, or a source managed settings explicitly vouch for, keep that pre-approval. Every other marketplace, claude.ai, or npm plugin now has to earn tool access the normal way instead of granting it to itself.
What changed on September 25: new admin model controls
The September 25 changelog entry for version 2.1.283 added two managed settings that answer a narrower but related question: not what a session can do, but which models it's allowed to use at all. deniedModels blocks specific models even when a separate availableModels entry would otherwise allow them, whether the entry is a family alias like "opus" or a specific model ID. availableModelsMatch controls how loosely an availableModels entry gets interpreted: set to "exact", an entry permits only the named model version, so a future release stays blocked until someone adds it by name. Neither setting existed before 2.1.283, and both are scoped to managed settings only. Set them in a user, project, or local config and Claude Code ignores them with a warning, per the settings reference.
How to pin a default permission mode and model policy org-wide
1. Confirm eligibility
Managed settings require a Claude for Teams or Enterprise plan, and only an account with the Owner or Primary Owner role can configure them, according to Anthropic's server-managed-settings docs. If nobody on the account holds that role, start there before touching anything else.
2. Open Admin Settings > Claude Code > Managed settings
That's the console path for writing the policy: Admin Settings > Claude Code > Managed settings in the claude.ai console. This is a separate surface from endpoint-level MDM or registry settings, and it's the one that actually reaches cloud sessions.
3. Write the JSON policy
permissions.defaultMode sets the mode new sessions start in; it applies to any file and takes a string. Pair it with an availableModels array and availableModelsMatch set to "exact" so that allowlist doesn't silently cover future model releases, add deniedModels to block specific models outright, and set permissions.disableAutoMode to "disable" if the goal is to remove auto mode from the mode switcher entirely rather than just override its default.
{
"permissions": {
"defaultMode": "acceptEdits",
"disableAutoMode": "disable"
},
"availableModels": ["claude-opus-5"],
"availableModelsMatch": "exact",
"deniedModels": ["opus"]
}4. Save and deploy
Clients pick up an updated managed policy at their next startup, or during the hourly polling cycle if a session is already running. There's no manual push step beyond saving the policy in the console.
5. Verify delivery
Run claude doctor on a client machine and check for the "Managed settings (remote)" line, which requires Claude Code version 2.1.248 or later. Inside a running session, /permissions shows the effective rules currently in force, which is the faster check if you're already at a terminal.
What this doesn't fix
Setting permissions.defaultMode changes what a session starts in. It doesn't remove auto mode as an option. A developer can still switch to it mid-session, with Shift+Tab in the CLI and JetBrains, or via the mode indicator in VS Code, unless permissions.disableAutoMode is also set to "disable". That's the mistake worth checking for first: an admin sets a strict default, assumes the job is done, and a developer switches to auto mode two keystrokes later because nothing actually blocked it.
There's a second gap worth knowing about if any of your team runs Claude Code in a cloud session rather than a local client. Endpoint-managed settings, the kind pushed through MDM or a registry, don't reach cloud sessions in Anthropic-hosted environments. An organization with any cloud-session users needs the console-based managed settings covered above in addition to whatever endpoint policy already exists, not instead of it.
Pinning a mode and a model list also says nothing about which specific tool calls an agent makes once it's running, which is a separate axis from permission mode. What to gate first when a coding agent's autonomy grows covers that question for a different tool, and the same logic applies here: a permission mode decides how much friction a session has by default, not which individual actions inside that mode are safe to let through unattended.
FAQ
Does setting permissions.defaultMode stop developers from switching to auto mode themselves?
No. Terminal sessions start in whatever mode permissions.defaultMode names, but people can still switch to auto mode from there, with Shift+Tab in the CLI and JetBrains, or via the mode indicator in VS Code. To remove auto mode entirely so nobody can select it, set permissions.disableAutoMode to "disable" in the same managed policy.
What's the difference between deniedModels and availableModels?
availableModels is an allowlist; deniedModels is a blocklist that overrides it. If a model appears in both, deniedModels wins. A family alias like "opus" in deniedModels blocks every model in that family, and a specific model ID without a minor version also blocks later minor releases of that same model.
Does availableModelsMatch: "exact" block new model versions automatically?
Yes, that's the point of the setting. The default behavior, "prefix", lets an availableModels entry cover future extensions of a named model, so "claude-opus-5" would also permit Opus 5.5 once it ships. Switching the match type to "exact" closes that gap: an entry only permits the exact version named, and any new release stays blocked until someone adds it to the list by name.
Is auto mode available to everyone, or only paid plans?
As of version 2.1.284, everyone. Interactive terminal and VS Code sessions now default to auto mode on every plan and every provider when no permission mode is configured. That's wider than the previous behavior in 2.1.283, which only defaulted to auto mode on third-party providers or with telemetry turned off.