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 is off by default, and an administrator turns it on and can restrict it to a named set of domains.

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.