Anthropic shipped a release on Friday that changes the governance posture for every enterprise team running Claude Code through a major cloud provider: version 2.1.207 removes the environment variable that previously kept auto mode opt-in on Amazon Bedrock, Google Vertex AI, and Microsoft Azure Foundry. Autonomous agentic coding — which until Friday required a deliberate flag to activate on those platforms — is now on by default. Teams that want to maintain manual control must now actively set disableAutoMode in managed settings before their next Claude Code update propagates.
The change is one sentence in a changelog. Its operational consequence is a reversal of who bears the burden of action. Before Friday, a security or compliance team that had not explicitly evaluated auto mode was protected by inertia: the feature was off. After Friday, that same team must take affirmative action to keep it off. In regulated industries — where every change to how AI agents interact with production systems potentially triggers a review — that inversion matters more than it sounds.
What Auto Mode’s Classifier Actually Does
Auto mode sits between two extremes that enterprise teams have had to choose between since Claude Code launched in early 2026. Manual mode, the default for interactive CLI sessions, requires a human to approve every file write, shell command, test run, and commit — a friction-generating baseline that Anthropic’s own telemetry found produced approval fatigue, with 93% of prompts being approved reflexively without review. At the other extreme is --dangerously-skip-permissions, which bypasses all safety checks and is genuinely unsuitable for production machines holding SSH keys, secrets, and live credentials.
Auto mode uses a background AI safety classifier as a middle path. Before executing any action — editing a file, running a build, committing code, opening a pull request — a dedicated second model reviews the pending operation against the conversation context and decides whether to allow or block it. The classifier monitors three categories of risk: scope escalation (Claude doing something beyond what the user requested), untrusted infrastructure targets, and prompt-injection patterns that could indicate Claude was manipulated by hostile content in a repository file or web page.
The architectural design matters for understanding the classifier’s limitations. According to Anthropic’s own engineering blog, the classifier receives user messages and tool calls, but not Claude’s own internal reasoning or raw tool results. That means the safety layer judges requested actions and stated intent — not everything Claude may have worked through internally. The practical implication: the classifier is calibrated against observable actions, not against reasoning chains the user cannot see. Anthropic has also documented that natural-language boundaries set conversationally — such as "don’t modify production infrastructure" — are enforced only as long as that message remains in the active transcript. Heavy context compaction in long sessions can clear such a boundary, leaving no classifier record of the constraint. For hard guarantees, organizations should use deny rules in settings files, not conversational instructions.
None of this means the classifier is inadequate. Anthropic red-team exercises, internal documentation, and the pattern of successive releases show it blocking the class of actions most likely to cause irreversible harm — mass file deletion, data exfiltration patterns, force-pushes to shared history, and commands pulling code from external repositories without explicit approval. The classifier’s block thresholds are also self-limiting: if auto mode denies the same action three times consecutively or twenty times in a session, it pauses and resumes manual prompting automatically. The point is not that auto mode is unsafe. It is that enterprise governance teams should understand what the classifier does and does not evaluate before treating its presence as a complete risk answer.
What the Opt-In Phase Established — and What the Default Change Means
Auto mode on Bedrock, Vertex, and Foundry first arrived on May 30, 2026, in v2.1.158 — but only for teams that explicitly set CLAUDE_CODE_ENABLE_AUTO_MODE=1 in their environment. That design was deliberate: give enterprise teams a controlled window to evaluate the capability before it changed their default posture. The variable worked as a governance gate. Compliance teams could pilot auto mode in isolated environments, run security reviews, and decide whether to extend it more broadly — all while the majority of their production fleet remained unchanged.
V2.1.207, released Friday, removes that gate. Auto mode now activates on Bedrock, Vertex, and Foundry without any environment variable. Teams that want to disable it set disableAutoMode in their Claude Code settings file — available in user settings, operator-specified --settings files, and managed remote settings. The critical technical detail: the key is no longer readable from project-resident .claude/settings.local.json files. That exclusion is deliberate. Project-level config files, which can be committed to repositories and modified by contributors, are not a trusted control surface for a governance decision that affects production autonomy. The disableAutoMode key must come from user-level or managed organizational settings to be honored.
This is a meaningful distinction for enterprise fleet management. An organization running Claude Code across hundreds of developer machines cannot rely on per-developer settings files checked into repositories. The correct governance path is managed remote settings, configured by an administrator and pushed across the fleet, not a local file that travels with a repository. Teams that haven’t established managed settings infrastructure as part of their Claude Code deployment should prioritize doing so before this update propagates.
The same v2.1.207 release also changes the default model on Bedrock, Vertex, and the Claude Platform on AWS to Claude Opus 4.8. Teams with cost-sensitive workloads or model-specific approved configurations should verify their managed settings reflect the intended model before the update deploys. Organizations that want to stay on Opus 4.7 should set the model explicitly — once the update propagates, the environment defaults to Opus 4.8 without a specified override.
Why Enterprise Cloud Specifically, and Why It Matters Now
Auto mode launched on the Anthropic API in late March 2026 without an opt-in requirement for organizations using Anthropic’s own infrastructure. The Bedrock, Vertex, and Foundry path was always a separate track — and a more significant one for regulated enterprise buyers.
The reason is organizational, not technical. A financial services firm operating under data-handling requirements or a healthcare organization with audit trail obligations faces a fundamentally different procurement conversation when routing an autonomous coding agent through a new third-party API endpoint than when enabling a feature within a cloud account already cleared for production workloads. Bedrock, Vertex, and Foundry each operate within the customer’s own cloud account and network boundary. Source code and model interactions remain inside the same perimeter that the organization’s legal and security teams have already approved. No new vendor relationship, no additional data-residency review, no separate procurement cycle.
The May 30 opt-in flag was the initial access grant to that perimeter. The July 10 removal of the flag signals that Anthropic considers auto mode ready for general enterprise deployment within those environments — and places the responsibility for restricting it on the organizations themselves rather than on Anthropic’s default design. For CISOs and risk leaders whose teams have already cleared Bedrock, Vertex, or Foundry for production AI workloads, the question is no longer "can we use auto mode?" It is "have we decided whether we should, and documented that decision before the update arrives?"
The v2.1.207 release also includes a security hardening change worth noting independently: ${user_config.*} expansion in shell-form hook commands is now rejected across plugin hooks, monitors, and MCP headersHelper configurations. This closes a potential shell-injection vector through plugin configuration values. Teams using plugins with shell-form hooks should review their configurations before updating, as the change is a breaking change for any plugin hook that referenced user configuration values through shell variable expansion. Anthropic’s recommended alternatives are exec form (args array syntax) for hooks or reading configuration values directly inside the script.
Competitive Context: What This Release Changes for Cloud-Native Rivals
Amazon Q Developer and Gemini Code Assist, the AI coding tools native to the two largest Bedrock and Vertex platforms respectively, benefit from integration depth that Claude Code must work to match. Amazon Q has been generally available since 2024 with deep embedding in the AWS Console; Gemini Code Assist is woven into Google Cloud’s developer tooling. Both carry compliance certifications and billing integration built around their respective cloud accounts.
Anthropic’s counter-position has been model capability and autonomous task execution. Claude Code leads independently measured benchmarks for complex multi-file refactoring (SWE-Bench Verified: 80.8% for Opus 4.6) and agentic computer use (OSWorld: 72.7%). The self-directing edit/test/refine loop, combined with the five-level sub-agent hierarchy, dynamic workflow orchestration, and the safety classifier, represents a depth of autonomous task execution that neither cloud-native competitor has matched in comparable form.
Making auto mode the default on Bedrock, Vertex, and Foundry is Anthropic’s argument that the model quality and autonomous capability advantage outweigh the integration depth gap — and that enterprise teams who have already committed to those cloud environments should be able to deploy Claude Code’s full capability without additional friction. Whether legal and security teams at large organizations agree will depend on their internal review of the auto mode classifier’s design and the security hardening trajectory of successive Claude Code releases.
What Teams Should Do Before the Update Propagates
The practical action list for enterprise teams is short and time-sensitive.
For teams using managed remote settings, verify that the auto mode governance decision has been made explicitly and is reflected in the managed configuration before the update propagates. If your organization wants auto mode enabled, no action is required. If your organization has not evaluated auto mode and wants to maintain the prior manual posture while you do, set disableAutoMode in managed settings.
For teams that have not yet established managed remote settings, this release is a forcing function. Per-developer local settings and repository-resident project files are not appropriate control surfaces for a decision about production AI agent autonomy. Establish managed settings infrastructure now.
For teams with cost-sensitive workloads, verify the model configuration before the update arrives. V2.1.207 changes the default to Opus 4.8 on Bedrock, Vertex, and the Claude Platform on AWS. If your approved configuration specifies Opus 4.7 or requires explicit model pinning for compliance reasons, set the model explicitly in managed settings before updating.
For teams running plugins with shell-form hook commands, review those configurations for ${user_config.*} variable references before updating, as the shell-injection fix is a breaking change. Migrate to exec form or script-internal configuration reads per Anthropic’s updated documentation.
Frequently Asked Questions
What does "auto mode is now default" on Bedrock, Vertex, and Foundry actually mean for my team?
Before v2.1.207, running Claude Code through Amazon Bedrock, Google Vertex AI, or Microsoft Azure Foundry required an explicit environment variable (CLAUDE_CODE_ENABLE_AUTO_MODE=1) to enable autonomous agentic coding. After updating, auto mode is active without any flag. The agent will plan, write, test, commit, and open pull requests without asking for approval on individual actions — a background safety classifier handles each decision instead of a human. If your team wants to maintain manual, per-action approval as the default, you must set disableAutoMode in your managed organizational settings before the update propagates.
What is the disableAutoMode setting and where does it go?
disableAutoMode is a Claude Code managed settings key that suppresses auto mode across a fleet. According to Claude Code’s official permissions documentation, it belongs in user-level settings (~/.claude/settings.json), operator-specified --settings files, or managed remote settings pushed by an administrator — not in project-resident .claude/settings.local.json files, which v2.1.207 explicitly removes from the auto mode read path. For organizations managing Claude Code across multiple developer machines, the correct path is managed remote settings, which administrators can configure and push centrally without relying on per-developer config files.
Is the auto mode safety classifier sufficient for enterprise security requirements?
The classifier monitors scope escalation, untrusted infrastructure targets, and prompt-injection patterns — and it pauses auto mode if it blocks the same action repeatedly, falling back to manual prompting. That said, security researchers have documented that the classifier evaluates observable actions and stated intent, not Claude’s full internal reasoning. Conversational boundary instructions ("don’t modify production") are only enforced while they remain in the active transcript and can disappear after heavy context compaction. For hard governance guarantees, organizations should use explicit deny rules in settings files, establish managed settings infrastructure, scope permissions to least-privilege, and maintain an audit trail of agent actions through their cloud platform’s native logging tools (CloudTrail for Bedrock, Cloud Logging for Vertex, Azure Monitor for Foundry). The classifier is a meaningful risk-reduction layer, not a substitute for organizational governance. The OWASP Top 10 for Agentic Applications 2026 provides a practitioner-oriented framework for assessing agentic AI risks in enterprise environments.
Does this release conflict with v2.1.200, which made Manual mode the interactive default?
No — these two releases govern different deployment contexts. V2.1.200 (July 3, 2026) made Manual mode the default for interactive CLI sessions, where developers are present at a terminal and each action benefits from deliberate human review. V2.1.207 makes auto mode the default for sessions routed through Bedrock, Vertex, and Foundry — environments where enterprises run programmatic and production-configured workloads, often without a developer at a terminal approving each step. The two defaults are designed for different use patterns: human-interactive development (Manual) and cloud-resident agentic pipeline execution (auto mode).
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.