Claude Code Just Automated the Decision to Ask You for Permission

Starting today, 14 August 2026, new Claude Code sessions on Pro, Max and Team plans begin in auto mode. Anthropic announced it on 7 August, and the Claude Code documentation now states it in two places: the permission modes page and the auto mode configuration page.

Most of the commentary I have seen frames this as Claude Code becoming more autonomous. That is true, and it is also the least interesting part. What actually changed is smaller and stranger. The question of whether a human should be interrupted has stopped being answered by the human.

What Anthropic actually changed

The wording in Anthropic's documentation is precise, so it is worth repeating exactly rather than paraphrasing into something bigger.

Starting 14 August 2026, auto mode becomes the default permission mode for new sessions on Pro, Max and Team plans. Anthropic says you can switch modes at any time. A default you set yourself stays in place unless you accept the one time switch prompt. A default your organization manages is unchanged. In the weekly release note for the same change, Anthropic adds that the classifier calls auto mode makes no longer count toward usage limits on those plans.

In the announcement post, Anthropic says auto mode remains opt in for now on Claude Enterprise, the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry, to give administrators time to review the change, and that it plans to make it the default across those in the coming month. On Team and Enterprise, administrators can turn auto mode off for the organization with a managed setting.

Auto mode is not the absence of permission checks

This is the claim I most want to get right, because it is the one most likely to be repeated wrongly.

According to Claude Code's documentation, auto mode lets Claude execute without routine permission prompts, and a separate classifier model reviews actions before they run. Anthropic writes that the classifier blocks anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read. Explicit ask rules still force a prompt. The configuration page adds that deny and explicit ask rules are evaluated before the classifier and still block or prompt.

The documented default block list is long and specific. It includes downloading and executing code such as curl piped into a shell, sending sensitive data to external endpoints, production deploys and migrations, mass deletion on cloud storage, granting IAM or repository permissions, modifying shared infrastructure, irreversibly destroying files that existed before the session, force push, and infrastructure destroy commands in Terraform, Pulumi, CDK and Terragrunt. Anthropic documents that by default the classifier trusts only the working directory and the remotes that were configured for it when the session started, and that everything else is treated as external until an organization declares trusted infrastructure.

Auto mode is also not the same thing as bypassPermissions. Anthropic keeps those as separate modes with separate descriptions. bypassPermissions is described as running everything, recommended for isolated containers and virtual machines only. Auto mode is described as everything with background safety checks. Anthropic's own caveat, in its documentation, is that auto mode reduces permission prompts but does not guarantee safety, and should be used for tasks where you trust the general direction rather than as a replacement for review on sensitive operations.

So: not no permissions. Not unrestricted execution. Not the removal of human control. An automated permission decision layer.

The approval decision became a model decision

Here is where my reading starts rather than Anthropic's documentation.

The old loop was simple to describe. The agent proposes an action. You see a prompt. You approve or deny. Whatever else was wrong with that loop, the authority question had an obvious answer. A human was in the path of every action that mattered, at least nominally.

The auto mode loop, as Anthropic documents it, inserts an evaluator. The agent proposes an action. Deny rules and explicit ask rules are checked. If nothing there fires, a classifier model judges the action. Routine actions run. Actions that escalate, reach outside the environment or look driven by hostile content are blocked, and Claude Code shows a notification and lists them under a recently denied tab where you can retry with a manual approval.

That is a real safety architecture, and I want to be fair about it. But notice what moved. Everyone is talking about reducing approval fatigue. What I think actually matters is that the decision to require human approval is now itself an automated decision.

We spent two years asking whether an agent should be trusted to act. The question this change raises is different: what should be trusted to decide when the agent needs our permission?

Humans were already approving almost everything

The uncomfortable part of Anthropic's case is that it is well evidenced.

In the announcement, Anthropic reports that users approve 97 percent of permission prompts in Claude Code, and that when Claude presents a plan for approval users reject 39 percent of them, while the rejection rate for individual permission requests is 3 percent. It reports that as of June 2026, 49.5 percent of active CLI users had manually created a Bash allow rule, that 62 percent of users have used bypassPermissions or clicked don't ask again on Bash, and that 25 percent of interactive sessions start in bypass permissions mode.

Anthropic also describes a controlled study with 1,053 paid testers, run through a research vendor in a test environment rather than in participants' own codebases. Partway through each session a single permission prompt was swapped for a clearly dangerous command. Anthropic reports that testers caught it 13.6 percent of the time, 143 of 1,053, while auto mode blocked 89 percent of the same commands, 937 of 1,053. Anthropic states that approving the prompt never resulted in anything dangerous being run.

Separately, Anthropic's February 2026 research post on measuring agent autonomy found that among new Claude Code users roughly 20 percent of sessions use full auto approve, rising to over 40 percent as users gain experience, and that among the longest running sessions the time Claude Code works before stopping nearly doubled in three months. Anthropic does not present that research as the reason auto mode exists, and I am not going to claim it is. I am reading it as context for why a prompt based control was under strain.

Put together, the honest summary is this. The permission prompt was already not doing the work people believed it was doing. Replacing a control that was mostly being clicked through is a defensible engineering decision. It is still worth being clear about what replaced it.

Oversight did not disappear. It moved up a layer.

The framing I want to resist is that humans are being removed. They are not. What is changing is the granularity at which humans participate.

Before, a person evaluated individual tool calls, badly and repetitively, but individually. Now a person configures the system that evaluates which tool calls deserve interruption. Anthropic's configuration documentation is essentially a manual for exactly that: declare which repositories, buckets and domains your organization trusts so the classifier stops blocking routine internal operations, add a human checkpoint for pushes and pull requests with an ask rule, review denials, adjust.

That is a genuinely different job. It is less frequent, more consequential and much harder to audit by feel. A person who approved 400 prompts last week produced a bad but visible record of decisions. A person who configured a trust environment produced one decision that silently governs thousands.

There is a nice illustration of the fragility of the informal version in Anthropic's own documentation. The classifier treats boundaries you state in conversation as block signals, so telling Claude not to push blocks matching actions. But Anthropic writes that boundaries are not stored as rules, that the classifier re reads them from the transcript on each check, and that a boundary can be lost if context compaction removes the message that stated it. For a hard guarantee, Anthropic says, add a deny rule instead.

I find that one of the most clarifying sentences in the whole documentation set. A stated intention lives in a context window. A rule does not.

Deterministic rules and OS enforcement are still separate things

Anthropic's design does not put everything in the model's hands, and that distinction is the part worth learning from.

Deny rules and explicit ask rules run before the classifier. Repeated blocks trigger a documented fallback: three blocks in a row or twenty across a session and auto mode pauses so Claude Code resumes prompting, with thresholds Anthropic says are not configurable. Anthropic also notes that in auto mode, allow rules broad enough to grant arbitrary code execution are set aside, since they would let commands skip the classifier entirely.

Then there is sandboxing, which Anthropic deliberately treats as a different problem. The sandboxing documentation says permission rules control which tools Claude Code can use and are evaluated before any tool runs, while sandboxing provides operating system level enforcement restricting what Bash commands and their child processes can access at the filesystem and network level. And the sentence that matters most: Claude Code evaluates permission decisions before a command runs, based on the command string and, in auto mode, a classifier's judgment, while the operating system enforces the sandbox boundary on the running process, so it holds regardless of what the model chose to run and even if an allowed command does more than its name suggests.

Read that as a statement of design philosophy and it is striking. Anthropic is not claiming the classifier is sufficient. It is shipping model judgment for the authorization question and operating system enforcement for the containment question, because those are not the same question and they do not fail the same way.

Agent authority is becoming layered

What this change really documents is that permission for agents is no longer a single gate. On current Claude Code, a consequential action passes through something like four distinct kinds of control.

• The agent chooses an action.
• Deterministic permission rules, including deny and explicit ask rules and organization managed settings, are evaluated first.
• A classifier model judges whether the action escalates, reaches outside the environment or is being driven by content Claude read, and may block it or leave it to a fallback that returns the human to the loop.
• The operating system, through the sandbox, separately constrains what a running Bash process can touch, regardless of what was approved.

Each layer answers a different question. Am I allowed. Should someone be asked. Can I physically reach it. Those used to be blurred together inside one prompt that a person clicked.

Agent authority is not only about what an agent can do. It is also about who decides when that authority requires human approval. That second question is the one that just changed hands, quietly, for a very large number of developers.

What the documentation does not answer

Some things I looked for and did not find, and I would rather say so than fill the gap with speculation.

• What exactly counts as routine is not enumerated. The block list is documented in detail. The allow side is defined mostly by what is not blocked.
• What counts as escalating beyond your request is a judgment call made by a model, and the documentation describes the intent rather than the boundary.
• The classifier's evaluation context is described in effect, for example that it re reads stated boundaries from the transcript, but not in full.
• Uncertainty is documented only at the edges. Anthropic says that when the classifier produces no verdict, because a separate safety check refused its request or the response did not parse, Claude Code denies the action without a notification or a recently denied entry, and that such denials do not count toward the fallback thresholds.

None of that is a criticism. Anthropic has published more operational detail about this control path than most vendors publish about anything. It does mean that the reliability of the approval decision is now partly a model property, and model properties are evaluated statistically rather than read off a config file.

The question I would ask my own team

If your engineers are running a coding agent on production adjacent systems this week, the useful questions are not about auto mode specifically.

• Which of our controls are deterministic rules, and which are model judgments?
• Which actions must always reach a human, and are they written as rules rather than stated in conversation?
• When something is blocked or approved, do we have a record we could show someone later?
• Who owns the trust configuration, and when was it last reviewed?
• Would we notice if a boundary we set stopped being enforced?

Anthropic is doing something reasonable here. The prompt was a weak control that felt like a strong one, and they have evidence for that. I am not arguing against the change.

I am arguing that the interesting question has moved. We are past asking whether an agent can be trusted to act. The question now is who decides when it needs permission.

Update, 26 August 2026: the same classifier now decides for the browser

Anthropic says Claude in Chrome is generally available on every paid plan. The extension lets Claude view a page, read its content, click, type, navigate between pages and fill forms, and it does this through a person's existing browser session rather than a separate identity of its own, so it can work with internal dashboards, legacy systems and vendor portals that have no dedicated integration, the same way a person already signed into them would. Anthropic documents three modes on the same drop down: approve every action manually, let a classifier approve routine actions automatically while flagging the rest, or skip review entirely. That is not a new architecture. It is the ask, auto and bypass distinction this piece describes above for Claude Code, offered again for a browser tab. A person can switch back to manual approval at any time, and Anthropic says some actions still require a check regardless of which mode is selected.

The automatic mode's classifier is described as doing two things before an action runs: judging whether the action is safe, and judging whether it matches what the person actually asked for. An action that does not match the original request is the one Anthropic says gets blocked rather than executed. That is the same shape of decision this piece has already described for Claude Code, an evaluator sitting between the agent's proposal and its execution, applied now to a click or a form submission instead of a shell command or a file write.

Browser capability is not the same fact as authority over what a login reaches

Anthropic's own examples of what Claude in Chrome can reach, internal dashboards, legacy systems and vendor portals, are all places a person's own logged in session already has standing access to. That is worth being precise about, because it is easy to read reachability as authorization. A person's employer account, a shared business login or a customer portal being technically open to an agent does not by itself establish that the person was entitled to hand autonomous use of that access to software. Moona Intelligence does not treat the capability described here as evidence of payments, administrative changes, account deletion, sending email or deploying anything, because Anthropic's own material does not establish those as reachable actions; it treats the capability as exactly what is documented: viewing, clicking, typing, navigating and filling forms, inside whatever a person's existing session happens to expose.

Keep four separate facts apart here, because the announcement blends them into one smooth sentence and the smoothness is doing work. A person being authenticated to a site is one fact. The site permitting an action under that authentication is a second fact, decided by the site, not by Claude. The person assigning Claude a task is a third fact. The classifier deciding a proposed action fits that task is a fourth. None of the four establishes that the person was organizationally entitled to delegate the site's access to autonomous software in the first place. That question sits upstream of everything Anthropic documents here, and nothing in this announcement answers it.

What actually bounds a proposed browser action

From what this record can verify, a browser action is currently bounded by some combination of the original request the classifier checks a proposed action against, the site or domain the action targets, an Enterprise administrator's approved domain list where one is configured, and whichever of the three permission modes is selected. On Enterprise plans, Claude in Chrome was off by default at launch, and starting 10 September 2026 it turns on by default unless an administrator has already disabled it; an administrator can still restrict it to a named set of domains, and on Enterprise custom roles a separate per role capability must also be granted before a given seat can use it.

What this record cannot verify is whether Claude in Chrome carries a protected action taxonomy equivalent to the default block list documented above for Claude Code auto mode, production deploys, force push, mass deletion, irreversible destruction of pre existing files and the rest. Anthropic's own Chrome documentation and this record's independent search did not surface a published list of browser action categories that stay blocked or always require manual approval regardless of mode. Because Anthropic describes Chrome as using the same classifier architecture, it would be easy to assume the same list applies. This record does not make that assumption. A coding environment and a browser session are different execution surfaces, and whether Anthropic's classifier treats a payment form, a delete confirmation or an account setting the same way across both is undocumented in the material this record could verify, not established by extension from the other product.

Two safeguards and one classifier, not three independent systems

Anthropic's own material distinguishes a prompt injection probe, which screens content Claude reads from a page for instructions that were not the person's own, from the action classifier described above, which screens Claude's own proposed action against safety and against the original request before it runs. When the probe flags likely injected content, Anthropic says Claude is warned and may check with the person before proceeding. This record keeps that probe distinct from the action classifier and both distinct from the manual approval mode a person can select, because collapsing three components of one Anthropic implementation into three independent authority systems would overstate how many separate checks are actually happening.

Anthropic reports evaluation results for this combination: in the evaluation Anthropic describes, Sonnet 5, Opus 5 and Mythos 5 recorded no successful attacks, and Fable 5 recorded a 0.3 percent attack success rate, with the successful cases manually assessed by Anthropic as low severity. This record treats that figure the way it treats every vendor supplied benchmark elsewhere in this canonical's own history: as Anthropic's own reported result from Anthropic's own evaluation, not an independently reproduced measurement. Zero recorded attacks in one evaluation run is not proof the mechanism cannot be bypassed, and Anthropic's own documentation says prompt injection remains a moving target. This record preserves that limitation rather than reading a clean evaluation number as a closed question.

What Authority Provenance still leaves open

A few questions this record can name precisely without answering, because the public material does not answer them either. Whether a downstream site sees only the person's own session when Claude acts through it, a distinguishable browser extension identity, both, or neither, is not established by what Anthropic publishes; this matters because an action Claude actually performed may be attributable, from the site's own point of view, solely to a human session that did not perform it. Whether Claude in Chrome keeps any structured, durable record of the original task, the sites or actions it was meant to cover, or the session's intended scope, in a form separate from the classifier re reading the conversation each time, is undocumented rather than confirmed absent. Whether turning off automatic approval, an administrator narrowing an approved domain list, or a browser session expiring reaches an action already proposed or only actions proposed afterward is not documented publicly. And no general undo mechanism for a completed browser action is documented; where recovery exists at all, it is a property of the destination site, not a capability Claude in Chrome itself provides.

None of that is a claim that Anthropic has done something wrong. It is a claim that generally available and classifier reviewed are not the same thing as provenance established. Anthropic has extended the decision this piece opened with, whether a human needs to approve an action, into a browser tab where the access being exercised is not a service account Anthropic issued but a person's own logged in session. That is a real change in where the automated permission decision reaches. It is not evidence that the older question underneath it, whether the person was entitled to hand that session to software in the first place, has been answered. It has only moved to a new address.

Update, 28 August 2026: a session that starts with less, instead of asking less

GitHub's release page records Claude Code v2.1.248 as published at 2026-08-27T22:12:20Z, which its interface renders as 27 August. Converted to Europe/Paris, where this record's clock runs, that same instant is 28 August 2026 at 00:12:20, a few minutes past midnight. The conversion is worth stating plainly rather than skipping, because it is easy to read GitHub's UTC rendering and call this a 27 August release without checking, and the two calendar dates disagree only because the timestamp falls either side of midnight in two different timezones, not because of any real gap in time.

The release note is one line, and it is worth quoting in full rather than paraphrasing: "Added --restricted (or CLAUDE_CODE_RESTRICTED=1): removes the built-in tools that run commands or code and WebFetch (unless named in --tools), keeps file tools inside the working directory, refuses bypassPermissions, and ignores user, project and local settings files." Claude Code's own CLI reference expands the same line with its intended use: restricted mode is for when "an evaluation harness drives claude on a shared machine and Claude Code must not run commands or read that machine's user and project settings."

A different question than the one auto mode answers

Read against everything above, restricted mode is not a seventh permission mode alongside default, acceptEdits, plan, auto, dontAsk and bypassPermissions. Claude Code's own documentation lists exactly those six as the available modes, and restricted mode is not among them. It is a session launch flag that runs underneath whichever mode the session ends up in.

That placement matters more than it sounds. Auto mode's classifier, and every permission mode described above, answers a question about an action a session is already capable of attempting: should this specific tool call proceed. Restricted mode answers an earlier question: does the session hold this tool at all. A classifier that blocks a Bash command is refusing to authorize an available capability. A restricted session that has no Bash tool cannot propose the command in the first place, so there is nothing left for a classifier, a deny rule or a human to say yes or no to. Anthropic is not claiming the second kind of control is safer than the first, and the release note does not compare them. What changed on 28 August 2026 is that Claude Code now documents both kinds, where before this record only had documentation for the second.

What the flag actually removes, precisely

Two things are named directly and two are structural. WebFetch is named, and it is removed "unless named in --tools." The release and the CLI reference name Bash and PowerShell only implicitly, through the phrase "tools that run commands or code," without publishing an enumerated list of which of Claude Code's roughly four dozen built-in tools that phrase covers. The permission modes documentation separately states, in an unrelated section about auto mode, that Claude Code runs Monitor commands through the shell, which reads as the same category even though Monitor is never named in the restricted mode text itself. NotebookEdit, which modifies notebook cells rather than executing them, and Agent, which spawns a subagent rather than running a command directly, are not addressed either way in anything this record could verify. Where Anthropic's own material does not name a tool, this record is not going to guess which side of the line it falls on.

The CLI reference also says a removed tool can be added back by name "in --tools, not through its default preset," which implies --tools accepts at least a named list and a default preset as different things. Claude Code's own CLI flags reference, current as of this record's check, documents --allowedTools and --disallowedTools as separate flags and carries no row for a flag literally named --tools, despite naming it twice, once inside the --allowedTools entry and once inside the --restricted entry. That is a gap in Anthropic's own published reference, not an inference this record is making, and it means the exact mechanism for opting a specific tool back into a restricted session is not fully documented in any current public source this record can point to.

File tools keep a boundary that already existed

The release says restricted mode "keeps file tools inside the working directory." Claude Code's own CLI reference is more precise: it links the confinement to the working directories Claude Code's permissions documentation already defines, which covers the session's primary working directory and any additional directories added with --add-dir, /add-dir, or the persisted additionalDirectories setting. Restricted mode does not narrow that concept to a single folder; it applies the ordinary working-directory boundary and refuses to let Claude's built-in file tools reach outside it. Because restricted mode ignores project, local and user settings files, an additionalDirectories entry set in any of those three would no longer apply inside a restricted session, following the same precedence Anthropic documents elsewhere; a directory added with the --add-dir flag at launch, or one set through managed settings or --settings, still would. Nothing in Anthropic's own material calls this read-only. Write, Edit and NotebookEdit are not disabled; they are bounded to the same directories Read already was, which is a location control, not a mutation control, and this record is treating it as exactly that rather than the stronger claim.

bypassPermissions: refused at launch, because it was never available any later

Claude Code's permission modes documentation states plainly, in the bypassPermissions section: "Claude Code refuses bypassPermissions in a session you start with --restricted." The same paragraph opens by establishing the general rule that bypassPermissions can only ever be turned on at launch, through a flag or a defaultMode setting: "You can't enter bypassPermissions from a session that was started without it enabled." Read together, restricted mode's refusal is not a special override sitting on top of an otherwise switchable mode. There is no mid-session path into bypassPermissions in Claude Code at all, for any session; restricted mode refuses the one enabling step, at launch, through which that mode could ever have entered the cycle. This record is not going to describe that as restricted mode closing a door that would otherwise stay open during the session, because Anthropic's own documentation does not describe any such door.

One adjacent detail is worth separating out precisely, because it is easy to misattribute. The same documentation page describes a one-time warning dialog, asking a person to accept responsibility for actions taken without permission checks, the first time an interactive session enables bypassPermissions; Claude Code saves that acceptance to user settings so the dialog appears only once. That dialog belongs to bypassPermissions itself, not to restricted mode, and a restricted session, which refuses bypassPermissions outright, would never reach it. This record is keeping the two apart rather than reading the dialog as something restricted mode itself shows.

What keeps reading a restricted session, and what "settings file" does not cover

The release says restricted mode "ignores user, project and local settings files." Claude Code's own settings documentation names five sources in strict precedence, managed settings highest, then command line arguments passed with --settings, then project local, shared project, and user settings lowest. Restricted mode's own CLI reference entry says plainly what remains: it "loads only managed settings and --settings." That is the two highest-precedence sources in Anthropic's own stack, kept intact, with the three lower ones removed. An organization's managed policy, and whatever a person launching a restricted session passes with --settings, still constitute the session's configuration. Nothing this record found establishes a managed-settings key that forces a session into restricted mode in the first place; the flag and the environment variable are what current documentation shows, and only the process invoking claude appears able to select it.

The more consequential gap is what "settings file" does not name. Claude Code's own documentation treats .mcp.json, the file that declares MCP servers, and the plugins loaded with --plugin-dir or --plugin-url, as configuration surfaces separate from settings.json, and nothing this record could verify says restricted mode's settings exclusion reaches either. Hooks are a sharper case still: Claude Code's own permissions documentation describes a hook as a custom shell command a settings file registers, evaluated at runtime, before a tool call proceeds. Because managed settings and --settings remain active in a restricted session, a hook configured through either of those two surfaces keeps its ability to run an arbitrary shell command on the host, outside anything restricted mode's own tool removal touches. That is not a flaw this record is alleging; it may be exactly the surface an organization's own managed hooks are meant to keep working through. It does mean the honest description of what restricted mode removes is narrower than "Claude cannot cause a command to run": the release documents the removal of Claude Code's own built-in command and code execution tools, and Anthropic's material does not establish the same removal for MCP-provided tools, plugin-provided tools, or hook-triggered shell commands, each of which is configured rather than built in.

Capability, authorization and containment, one more time

This record has already drawn a line, above, between deterministic permission rules, a classifier's authorization judgment, and the operating system's sandbox enforcement on a running process, each answering a different question about the same tool call. Restricted mode adds a layer that sits before all three: whether the tool exists in the session's context at all. Anthropic's own sandboxing documentation, already cited above for the boundary between permission decisions and OS enforcement, does not mention restricted mode, and restricted mode's own documentation does not mention the sandbox. The two read as independent controls a session can combine: a restricted session that also enables the Bash sandbox, where Bash remains available at all, would carry OS-level enforcement on top of a narrower built-in tool set, but nothing this record found describes restricted mode as itself providing OS-level containment. Removing a tool from a session's context is not the same claim as constraining what a process can reach once running, and Anthropic's own material keeps those two claims as separate as this record has argued they should be kept.

What this leaves genuinely open, rather than answered narrowly, is who is entitled to constitute a session's capability envelope in the first place. Anthropic's own documentation describes who can select restricted mode, a flag or an environment variable at launch, and what remains configurable once selected, managed settings and --settings. It does not describe, and this record found nothing establishing, whether an organization can require restricted mode the way it can require a managed defaultMode or disableBypassPermissionsMode setting; whether a session's restricted state is recorded anywhere a later audit could read back, separately from ordinary knowledge that a session ran with fewer tools than the model otherwise has; or whether a session begun restricted can be widened mid-task rather than only relaunched from a fresh start. Restricted mode is evidence that a coding agent's authority can now begin narrower than its full built-in capability, rather than beginning wide and being authorized down after the fact. It is not yet evidence about who gets to decide that narrowing on an organization's behalf, or how that decision would be shown to have been theirs to make.

Update, 29 August 2026: v2.1.251 and the gap between a check and its effect

GitHub's release page records Claude Code v2.1.251 as published on 28 August 2026 at 18:19 UTC, which converts to 28 August 2026, 20:19 in Europe/Paris, where this record's clock runs. Unlike the v2.1.248 release above, the two calendar dates agree here, so nothing in this update turns on a timezone conversion. The release note lists six changes this record reads as one family, because each one narrows a gap between a permission decision Claude Code already made and the exact resource, path or execution surface that decision ends up covering.

File tools, Grep and Glob: the path checked is not always the path reached

The release note states plainly: "Fixed file tools (Read, Write, Edit) following a symlink swapped inside the working directory after the permission check, which could read or write outside the approved location." That sentence describes a specific ordering defect, not a general claim about symlinks. Claude Code's own permissions documentation already treats symlinks carefully at the moment a rule is checked: an allow rule requires both the symlink path and its resolved target to match, and a deny rule fires if either one does, so a symlink pointing out of an allowed directory still prompts and a symlink pointing into a denied one is blocked outright. That existing mechanism governs the decision at check time. The defect v2.1.251 fixes sat later, at effect time: because a symlink inside the working directory could be replaced after Claude Code had already approved a read or write through it, a file tool could resolve the new target rather than the one the permission decision actually covered. Anthropic's release note does not claim this was exploited, and this record is not asserting that either. It is reading the fix the way Anthropic states it: a permission decision made about one resource should not silently become authority over a different one because the path resolved differently by the time the tool actually ran.

The same release fixes a related gap one layer up: "Fixed Grep and Glob not applying Read(...) deny rules to files reached through a symlinked search path." Before this fix, a Read deny rule could fail to reach a file if Grep or Glob got to it by following a symlink rather than a direct path, even though the same file reached through Read directly would have been blocked. That is the same authorization target problem in a different tool: the rule was written against a file, and a different way of arriving at that file was not being checked against it.

Workflow's script path: one line, kept small on purpose

The release also fixes the Workflow tool "reading (and quoting in errors) a scriptPath outside what the session may read before the permission check ran." Claude Code's own permissions and settings documentation do not describe the Workflow tool's script loading as a named feature, so this record cannot say more about the mechanism than the release note itself states. What it establishes is narrow but consistent with everything above: a tool read, and in the error case echoed back, a file path before the session's permission to read it had been checked, rather than after. This record is treating it as a small, confirmed instance of the same class of defect rather than expanding it into a larger claim the release note does not make.

Claude in Chrome: one permission pipeline instead of two

The 26 August update above described Claude in Chrome as using the same classifier architecture Claude Code uses in a terminal. The v2.1.251 release note narrows that description: Anthropic "changed Claude in Chrome so browser actions always go through Claude Code's permission checks, including in sessions with telemetry disabled, which previously used the Chrome extension's own prompts." Read precisely, that means at least one execution surface, a session with telemetry disabled, previously reached a browser action through a separate prompt path belonging to the Chrome extension itself, rather than through Claude Code's own permission checks. As of this release, Anthropic states that path no longer exists; every browser action now goes through the same checks as everything else this record has described. This record is not calling the earlier extension prompt path insecure; Anthropic's own note frames the change as consolidation, not as a correction to something unsafe, and this record has no evidence to add beyond that framing. What the release does establish is the property this record's earlier section could only ask about: whether a browser action and a terminal action, taken by the same agent for the same user, answer to the same permission boundary. As of v2.1.251, Anthropic's own material says they do. This record could not verify, and Anthropic's release note does not say, whether every one of Claude Code's permission modes, including restricted mode, now governs a browser action identically to how it governs a built-in tool call, so that mapping stays unconfirmed rather than assumed.

Weakening the sandbox boundary now needs its own approval

The release note states: "Changed server-managed settings that terminate sandbox TLS, route sandbox traffic through your own proxy, inject credentials, or weaken sandbox isolation to require approval before they apply." Claude Code's own documentation gives each of those four phrases a named setting to attach to. Terminating sandbox TLS is the experimental network.tlsTerminate setting, which makes the sandbox's built in proxy decrypt traffic itself rather than passing it through unexamined, a step the documentation says credential masking requires and otherwise recommends leaving off. Routing sandbox traffic through your own proxy is the sandbox's custom and corporate proxy configuration, which tunnels a sandboxed command's allowed connections through an upstream proxy the developer or organization names. Injecting credentials is the credentials mask mechanism, where a sandboxed command sees a placeholder value and the sandbox's own proxy substitutes the real credential only on requests to hosts an injectHosts list names. Weakening sandbox isolation covers settings the documentation already describes in close to that language, including enableWeakerNestedSandbox, which the sandboxing page calls a setting that considerably weakens security and should only be used when additional isolation is otherwise enforced, and turning the filesystem isolation layer off entirely.

None of those four settings is new to v2.1.251; each already existed, and Claude Code's documentation already restricted most of them to settings sources a developer or an administrator controls rather than a checked out repository. What changed is whether applying one of them from a server managed source now stops for the developer's own approval first. Claude Code already documents a security approval dialog for a separate set of server managed settings, hooks, shell command settings such as apiKeyHelper, sandbox binary paths, certain environment variables and managed CLAUDE.md content, and that documentation is specific about the mechanics: the dialog names what is being configured, the developer in the interactive session is the one who approves it, approval is recorded against the organization or the cached settings depending on the credential in use and is shown again when the settings requiring it change, and if the developer rejects the settings Claude Code exits rather than starting with them silently dropped. Anthropic's own material also states plainly that this control is client side rather than a security boundary, and that a user on an unmanaged device does not need administrator access to bypass it. This record could not find that same documentation page's own list of approval triggering settings updated to name sandbox TLS termination, custom proxy routing, credential injection or weakened isolation individually as of this record's check; the four categories currently appear only in the v2.1.251 release note itself. This record is stating that gap rather than papering over it. The mechanism the release note is extending, an approval dialog a developer must accept before a risky server managed setting takes effect, is well documented elsewhere, even where its newest four members are not yet named on that page.

disableAutoMode reaching a session that is already running

The final item is smaller and more precise: "Fixed managed-settings disableAutoMode arriving mid-session not moving an already-running auto-mode session back to default mode." Claude Code's own permissions documentation already describes disableAutoMode as a managed setting that prevents auto mode from being used, most useful, it says, in managed settings, where it cannot be overridden. What that description does not cover, and what this fix adds, is timing: whether a policy change reaches a session already in progress or only sessions started after the change. Before v2.1.251, a session already running in auto mode could apparently keep running in auto mode after an administrator disabled it, until that session ended and a new one started. After the fix, the setting reaches the running session directly, and it moves to default mode without a restart.

This record is keeping two things apart here, the same way it kept auto mode's classifier apart from restricted mode's tool removal above. A live policy change reaching a session's future permission posture is not the same claim as a live policy change reaching backward over an action the session already completed. Anthropic's release note describes the former. Nothing in it, or in anything else this record could verify, describes an already executed action being reversed, and this record is not reading the fix as evidence of that broader capability.

What v2.1.251 adds to the open question above

The closing section of the 28 August update above asked who is entitled to constitute a session's capability envelope in the first place, and said restricted mode does not answer it. v2.1.251 does not answer it either. What it adds is narrower and, on its own terms, more mechanical: across file tools, search tools, a workflow script path and a browser execution surface, a permission decision now binds more consistently to the specific resource it was actually made about, rather than to whatever the same path or the same prompt path happened to resolve to by the time the action ran. And changing the sandbox's own enforcement boundary, terminating its TLS inspection, rerouting its traffic, injecting a credential into it or weakening its isolation, now sits behind the same kind of developer facing approval step other risky managed settings already required, rather than applying from a server push on its own. Both are real narrowings of where an authority mismatch could previously live. Neither one establishes who was entitled to set the managed policy, the sandbox configuration or the restricted session's launch flag in the first place; that question, as this record said above, still belongs to the administrator's own organization, not to anything Claude Code's own documentation can settle.

Update, 3 September 2026: v2.1.259 and what happens after the decision

Anthropic published Claude Code v2.1.259 on 2 September 2026 at 22:33 UTC. Most of its release note is ordinary product repair. Four items are not, and read together they make a point this record has been circling since August: deciding who may act is only half of an authority model. The other half is whether that decision survives contact with the runtime, from the moment it is issued to the moment the work it governs actually ends.

No human present is not the same fact as no approval needed

The first item adds --permission-prompts none for unattended headless hosts. Anthropic's wording is exact: anything that would prompt is denied automatically while the active permission mode, including auto mode, keeps deciding. That is worth reading twice, because the obvious way to build this flag is the opposite one. A headless host has nobody to ask, so the convenient behavior is to treat the absent human as tacit agreement and continue. This does the reverse. An action that would have needed a person becomes a denial, and every other decision the current mode would have made on its own is untouched.

So this is not bypassPermissions with a different name, and it is not a headless allow mode. It is closer to the opposite: the set of actions available without a human gets smaller, not larger. What this record cannot tell you from the release note alone is the precise interaction surface, whether an explicit ask rule, an auto mode escalation that would have fallen back to a prompt, and a tool that prompts for its own reasons all resolve through the same single path. Anthropic describes one behavior for anything that would prompt, and this record states it at that level rather than inventing a per rule breakdown the source does not contain.

A policy that cannot be read is not a policy that does not apply

The second item is the one an administrator should care about most. Before v2.1.259, if the managed settings file, a drop in, the MDM plist or the Windows HKLM value could not be parsed, managed settings could silently go unenforced. Claude Code now refuses to start and names the source that failed.

The failure that fix describes is the quiet kind. Nobody removed the policy. The policy file was still sitting on the machine, still deployed by whatever fleet tool put it there, still visible to anyone who went looking for evidence that the organization had configured Claude Code. It simply was not governing anything. An organization checking whether its policy exists would have found it. An organization checking whether its policy was in force would have needed a different question, and until this release the product did not answer that question loudly. A configured policy and an effective policy are separate facts, and the second one is the only one that constrains an agent.

Two boundaries on that claim. This record is scoping the change to the four managed configuration sources the release note names, and it is not extending it into a general statement that every Claude Code configuration error now fails closed. The release note does not say that, and this record has no evidence for it. This record also cannot establish from the note alone whether the earlier silent failure dropped an entire managed source or only the keys inside it that failed to parse, and it is not filling that in by inference.

Stop requested is not the same fact as stopped

The third and fourth items belong together. Stop did not actually stop background agents and workflows in remote control sessions, and killed tasks now stay visible and re stoppable until their processes exit. Separately, resuming a workflow run while its previous stopped run was still exiting could run duplicate copies of its agents.

Revocation is the control everyone assumes is simple. An operator presses Stop, the agent stops, the authority it was using is gone. What the first fix describes is a Stop that reached the control plane and not the execution, in a specific surface, remote control sessions, for a specific class of work, background agents and workflows. This record is bounding it there rather than reading it as a statement about every Stop mechanism Claude Code has. The release note does not say whether a root process was killed while children survived, or whether the effect was confined to state the interface displayed, and this record marks that as unknown rather than choosing the more dramatic reading.

Anthropic's own corrective wording is the interesting part: killed tasks now stay visible and re stoppable until their processes exit. That is an admission that stopping is a period of time rather than an instant, and the interface now says so instead of showing a task as gone while it is still running. Three separate facts sit inside what people usually call stopping. A Stop was issued. A process exited. An effect that was already dispatched was cancelled. The first two are now closer together in this surface. The third one is not addressed here and, in general, is not available: a request that has already left the machine, a file already written, a deploy already accepted, is not recalled by any of this.

The resume race is the same observation from the other end. An operator stops a workflow, believes it is finished, resumes it, and now two executions of one logical workflow can be live at the same time because the first was still exiting when the second began. Nothing here says the duplicate agents held wider permissions than the original; this record is not making that claim, and whether the duplicates inherited the same session, grant and context is not documented in the release note. What is established is smaller and still uncomfortable: one logical workflow is not the same thing as one live agent execution, and the operator's mental model was the thing that was wrong.

The deny rule coverage that came with them

The same release extends Bash Read() deny rules to cases they did not previously cover: files supplied as option values, in Anthropic's examples --ignore-revs-file=.env, -f.env and @file; git diff and git grep file operands; and cd DIR && cat FILE compounds. A recursive grep or copy across a directory that holds a denied file now asks. This is the same shape as the v2.1.251 symlink fixes above, one layer further out: the rule was correct about the resource and the command syntax reaching that resource went around it. It does not establish that Bash deny rule coverage is now complete across every syntax, and this record is not claiming that on Anthropic's behalf.

What concurrent sessions were quietly doing to trust

One more item deserves a line. Concurrent sessions could silently revert each other's ~/.claude.json changes, so workspace trust could reset and MCP and project state could be lost when many sessions ran at once. Workspace trust is an authority bearing field: it is part of what Claude Code treats as trusted without asking again. MCP and project state is closer to capability configuration, and losing it could plausibly narrow or widen what a session can reach depending on what was lost. This record is not converting that into a specific widening claim, because the release note does not describe the direction of the drift. It is enough that a security relevant setting could be reverted by a process other than the one that set it, without anybody being told.

What this changes about the record above

Nothing above is withdrawn. The August analysis was about who decides when a human is needed, and the v2.1.251 update was about a decision binding to the resource it was actually made about. This one is about the lifecycle after that: whether a policy that exists is in force, whether an absent human narrows authority or widens it, and whether a revocation that was requested has actually happened. All three had a silent failure mode, and in each case the previous behavior was the permissive one. That is the pattern worth carrying forward. When an authority mechanism fails, the direction it fails in is a design choice, and the convenient direction is almost always the wrong one.

Update, 10 September 2026: the Enterprise default flips to on

Anthropic changes two Enterprise browser controls from default off to default on, starting 10 September 2026, unless an organization has already disabled them. The first is the Claude in Chrome extension. On Enterprise plans it was disabled by default at launch; starting 10 September 2026 it turns on by default unless an administrator has already turned it off. The second is the built in browser in Claude Cowork, which opens in the Cowork side panel inside the Claude Desktop app rather than through the extension. On Enterprise plans it was off by default at launch; starting 10 September 2026 it turns on by default unless an administrator has already disabled it. On Team plans both were already on by default as they rolled out.

The same two enterprise controls turning on by default is a change in the default, not a change in the control set. Both surfaces still run the safety layers Anthropic documents for browser use: per site permission prompts before Claude acts on a new site, a blocklist for high risk sites, and safety checks on every action. An administrator can still restrict Claude in Chrome to a named set of domains, and Anthropic recommends starting with a restrictive allowlist during rollout.

The action mode question moves with it. In the Claude in Chrome side panel that runs as a Cowork session, Automatically approve is the default action mode: Claude keeps working without stopping to ask about every step and does not produce a plan for a person to approve before starting. The classic side panel, by contrast, proposes a plan a person can approve before Claude begins. A person can switch modes at any time, and some actions still require a check regardless of which mode is selected. This is the same ask, auto and bypass shape this record has already described for Claude Code and for Claude in Chrome, except that the default action mode in the Cowork side panel is now the automatic one.

Default enablement is not deployment, and deployment is not authority

Two limits keep this change from reading as a grant of universal action authority, and both come from Anthropic's own documentation. The Claude in Chrome extension is governed by two separate settings on Enterprise: an organization level toggle, and a per role capability that an administrator grants or withholds. The per role capability applies to Enterprise organizations using custom roles. Being on by default at the organization level is therefore not the same fact as being entitled for every seat, because a role without the capability still cannot use it. The built in browser, separately, is rolling out gradually, and Anthropic says the setting may not appear in Organization settings until the rollout reaches an organization. Default enablement does not reach a tenant the rollout has not reached yet.

This record keeps four facts apart, because the announcement's smoothness does work that the underlying facts do not. A browser surface being switched on for an organization is one fact. A given user's role being entitled to use it is a second. The rollout having actually reached that user is a third. The person who owns an authenticated browser session being organizationally entitled to hand autonomous use of that session to software is a fourth, and nothing in this change answers it. The capability described here still reaches whatever a person's existing logged in session happens to expose, and this record still does not treat reachability as authorization, for the reasons set out in the August Chrome section above.

What this does not establish

What this change does not establish is at least as important as what it changes. Anthropic's own material does not state whether the per role capability applies to Team plans the way it applies to Enterprise custom roles, or how the capability interacts with the Cowork built in browser as distinct from the extension. It does not enumerate a protected browser action taxonomy equivalent to the default block list documented for Claude Code auto mode, and this record continues not to assume, by extension from one execution surface to another, that a payment form, a delete confirmation or an account setting is treated the same way in the browser as in a coding environment. It does not state whether an organization that turned the controls off before 10 September 2026 stays opted out indefinitely, or whether a future default change could turn them back on again. And it does not establish that default on means a person's authenticated sessions are now being acted on: the controls still require a user to install the extension or open a Cowork task, and Claude in Chrome acts in a person's existing browser sessions rather than holding an identity of its own. Each of those is marked unknown rather than filled in by inference.

Update, 10 September 2026: v2.1.268, a rule that exists and does not fire

GitHub records Claude Code v2.1.268 as published the same day this record's browser update above concerns, 10 September 2026 at 20:30 UTC, which converts to 22:30 in Europe/Paris, this record's own clock: the same calendar day in both zones, so nothing here turns on a timezone conversion the way the 28 August update above did. This session's own direct curl and git-protocol access to anthropics/claude-code returned an explicit denial, that GitHub access to this specific repository is not enabled for this session, a repository-scope restriction distinct from a network egress block; this session's own automated page-fetch tool reached the release page through a separate path and returned the release note's exact wording, corroborating the upstream evidence bundle this record was itself supplied and adding one further specific this record's own fetch confirms that the supplied bundle's excerpts did not: the named symlinked directories are /etc, /tmp and /var on macOS and /bin on Linux. The fetched and quoted text is retained as a discovery artifact, content addressed and captured through this corpus's own canonical Radar artifact path rather than this record's prose alone (sha256:a1dc68a2780cb989311967f54fb2c17a7fbb4f9d3eb1ba7fee5d84bd210d3cff).

The release note states three changes plainly, and each is worth reading against this record's own running distinction between a policy being declared, a policy being evaluated against the actual target, and a policy being enforced at the moment of effect. The first: "Fixed deny and ask permission rules on symlinked directories (/etc, /tmp, /var on macOS; /bin on Linux) not applying when a path was given by its real location, and Bash commands ignoring deny rules written on a symlinked path spelling." On macOS in particular, /etc is itself a symlink to /private/etc, so a deny or ask rule an operator writes against the conventional /etc spelling governs a resource whose access can be addressed two ways, through the symlink or through the real path it resolves to. Claude Code's own permissions documentation, already cited above for the v2.1.251 update, states that an allow rule requires both the symlink path and its resolved target to match and a deny rule fires if either one does; this release fixes a case that mechanism did not yet reach, where the tool call itself addressed the resource by its already-resolved real location rather than through the symlinked spelling a rule happened to be written against, and, separately, where a Bash command referenced the symlinked spelling directly and the deny rule written on that exact spelling still failed to fire. This is not the same defect v2.1.251 fixed: that release closed a gap where a symlink could be swapped inside the working directory after a permission check had already run, a timing gap between check and effect on a target that moved. This one is a matching gap with no timing element at all, between a rule's own written spelling and the spelling, symlinked or already resolved, that a specific access actually used.

The second: "Fixed a case where a Read or Edit deny rule did not apply when an env -C, eval or similar command the permission checker cannot analyze was on the same line." This is the same family as the Bash Read() deny rule extensions the 3 September 2026 update above already covers, option values, git diff and git grep operands, and cd DIR && cat FILE compounds, generalized one step further: rather than a specific syntax the checker had not yet been taught to parse, this closes a case where the checker states plainly that it cannot analyze the command at all, and the previous behavior treated that inability as a reason not to apply the deny rule rather than as a reason to deny by default. Read together with the symlink fix above, both share one shape this record has not yet stated this precisely: a permission rule can be correctly written, correctly loaded and genuinely intended to cover a resource, and still not fire, not because the resource changed between a check and an effect, but because the checker's own resolution of what the command or path in front of it actually identifies did not reach the form the rule was written against. A rule existing and a rule being evaluated against the right target are separate facts, and this record has been tracking the gap between the second of those and enforcement at effect since the 29 August update; this release adds a case where the gap sits one step earlier still, between a rule existing and it being evaluated at all against the specific identity in front of it.

This record connects both fixes to a Risk Registry weakness for the first time, AEW-017, failed resource resolution inherits the trust of the apparent path, previously held as a candidate on a single vendor's own disclosed and patched mechanism, Cursor's CVE-2026-50549, where a failed path canonicalization fell back to trust a write target's unresolved, apparent path. This record does not read the symlinked-directory fix above as an identical mechanism, no canonicalization step failed with an exception the way Cursor's did, but as the same authority gap generalized: a check meant to establish a resource's or a command's actual, effective identity before a rule is evaluated against it did not reach that identity, and the gap was resolved in the permissive direction until fixed rather than the restrictive one. A second vendor's own disclosed and patched instance, at a different resource boundary, a permission rule matching step rather than a sandboxed write's canonicalization, and reaching a command's own unanalyzable syntax as well as a directory's own symlinked spelling, is the second, independent instance that weakness's own candidate rationale named as the condition for treating this pattern as recurring rather than isolated to one vendor's filesystem handling. This record's own connected AEW-017 evaluation therefore promotes it from candidate to published.

The third change is a different kind of fact: "Improved auto mode denials: the message Claude receives now names the rule that blocked the action and asks Claude to try a safer method and finish unrelated work before stopping to ask you." This is not a permission-binding fix; it is a change to what Claude itself is told once an action is blocked. Read against this corpus's own recurring distinction that a blocked path is not the same fact as a blocked objective, an agent denied one route to a goal has not thereby lost the goal, and a denial that only says no gives an agent nothing to act on besides stopping, this release is a vendor product choice that puts that distinction into the denial message itself: naming the rule that fired tells Claude what was actually judged unsafe rather than leaving it to guess, and the instruction to try a safer method and finish unrelated work before interrupting a person is a direct, shipped instance of treating a blocked action as bounded rather than as a reason to halt everything. This record does not read that instruction as itself a new authority mechanism. It is text delivered to a model, the same category of control this record's own August analysis already distinguished from a deterministic rule, competing with whatever else is in context rather than binding the way a rule does; nothing in the release note states that a safer method Claude selects on its own is itself re-evaluated by the classifier or by any deny rule before it runs, and nothing states what happens if the work an agent judges unrelated is not, in fact, unrelated to whatever the blocked action was for. What is established is narrower and still worth stating: Anthropic's own product design now treats the distinction this record has argued for narratively as worth building into the product's own denial path, rather than leaving an agent that hits a wall with nothing to do but ask.

Update, 13 September 2026: a second, independently admitted upstream evidence bundle for this same release, supplied through Agentic Web Discovery rather than re fetched, carries a fourth change the record's own first bundle for this release did not: "Fixed a respawned in-process teammate picking up tools or a system prompt from a same-named agent file in a folder you have not trusted." On its own text, an in process teammate agent, once respawned, could have its own tools or system prompt supplied by a file matching that teammate's own name found in a folder never trusted, rather than remaining bound to whatever configuration source it was originally, legitimately given. This is a different mechanism from the two matching gaps above: those concern a permission rule's own matching step not reaching a resource's or a command's actual, resolved identity before comparing it against the rule's own written form; this one concerns which configuration source a respawned agent instance's own tools and system prompt are actually drawn from, before any permission rule runs at all. This record does not connect it to AEW-017 above for that reason, and no existing Agent Execution Weakness in this registry precisely owns a respawned agent instance's own configuration provenance question either. Whether the lookup that produced this was name based, path based or some other mechanism, and whether a respawned teammate means the same running instance continuing under altered configuration or a newly spawned instance sharing an existing name, is not stated in the release note and is not inferred here. The bundle's own captured text is retained as a discovery artifact, content addressed and captured through this corpus's own canonical Agentic Web Discovery artifact path (sha256:b17293681f9a3727d37272debb7363b40bc40a23741a38579f9dbc58738175e9).