Claude Code v2.1.251, released 28 August 2026, is mostly a bug-fix release: a fix for conversations getting stuck after thinking-only turns, one for Opus 5 failing with an "effort is not supported when thinking is disabled" error, another for agent teams where a teammate's final answer never reached the team lead. Buried in the same release notes is a cluster of six security fixes, none flagged with a CVE or an advisory number, that are worth reading closely on their own, because together they describe several ways Claude Code's permission model could be worked around rather than a single headline bug.
This isn't a report of an active exploit. Anthropic's changelog states what each fix does and nothing more, no severity rating, no disclosure timeline, no evidence anyone used any of these before the patch. What follows is what the release notes actually say, in plain terms, plus what each fix means for how you configure Claude Code.
Why a symlink swap is a security bug in the first place
Several of these fixes share a shape worth naming, because it explains why a fix like this matters even without a published severity score. It's a time-of-check-to-time-of-use gap, sometimes shortened to TOCTOU: a tool checks whether an action is allowed, based on the state of something at that moment, a file path, a permission rule, then performs the action slightly later. If that state can change in between, the check and the action end up disagreeing, and the tool ends up doing something the check would have refused had it run a moment later. A symlink is a convenient way to force exactly that kind of change, since replacing a plain file or directory entry with a symlink is fast and doesn't require any special access beyond write permission to that one entry. None of the fixes below require a sophisticated attack to exploit in principle; they mostly require something else already having write access to a location Claude Code was told to trust.
The symlink escape in Read, Write and Edit
The most consequential of the six: file tools "following a symlink swapped inside the working directory after the permission check, which could read or write outside the approved location." The shape of the bug is a time-of-check-to-time-of-use gap. Claude Code checks whether a path is inside the working directory and covered by your permission rules, then acts on that path. If something replaces a directory entry with a symlink pointing outside the working directory in the window between that check and the actual read or write, the tool follows the symlink rather than re-checking against the now-different target.
This matters most in any setup where Claude Code operates on a directory that isn't fully trusted, a shared build environment, a workspace another process can also write to, or a sandboxed run where the working directory's contents aren't entirely under your control between the moment a tool call is approved and the moment it executes. On a single developer's own machine working on their own repository, the practical exposure is much lower, since nothing else is racing to swap a symlink in mid-operation.
Grep and Glob's parallel gap
A related but separate fix: "Grep and Glob not applying Read(...) deny rules to files reached through a symlinked search path." A Read(...) deny rule is meant to keep Claude from reading a specific path, a secrets file, a .env, anything you've explicitly excluded. Before this fix, a symlink pointing at a denied path could let Grep or Glob read through it anyway, since the deny check wasn't applied consistently across a symlinked route to the same content. This is the same underlying category as the file-tools fix, a place where a symlink offered a way around a check that worked correctly for a direct path.
Plugin commands escaping their own directory
"Fixed plugin commands declared in a marketplace entry being able to point outside the plugin directory; such paths are now rejected with a path-traversal error." A plugin's marketplace entry declares where its commands live. Before this fix, that declaration could point somewhere outside the plugin's own directory, which is the kind of path-traversal bug that matters specifically when you install plugins from a marketplace you don't fully control, since a malicious or compromised plugin entry could have referenced a command file elsewhere on disk rather than staying contained to its own install location. Claude Code now rejects such a path outright with an explicit error rather than silently resolving it.
The Workflow tool's scriptPath bypass
"Fixed the Workflow tool reading (and quoting in errors) a scriptPath outside what the session may read before the permission check ran." The Workflow tool runs a script you point it at. Before this fix, it could read a scriptPath the session wasn't actually permitted to read, and do so before the permission check that should have stopped it, with the added detail that the disallowed path could then show up quoted back in an error message. That's two separate problems in one: the read itself happening ahead of the check it was supposed to pass, and a path the session shouldn't see leaking into error output regardless.
Settings that could enable detailed tracing or raw API body logging
"Fixed project settings being able to enable detailed beta tracing or raw API body logging, and a lower-scope beta tracing endpoint bypassing an OTLP collector pinned by managed settings or a host app." Project settings, .claude/settings.json in a repository, are meant to be a lower-trust tier than user or managed settings, since anyone who can get you to open a repository can potentially influence them. Before this fix, a project's own settings could turn on detailed tracing or raw API request/response body logging, options that are meant to require a higher trust level, since request bodies can carry sensitive content. The same fix closes a path where a lower-scope tracing endpoint could route around an OTLP collector an organisation had deliberately pinned through managed settings, defeating the point of pinning one in the first place.
Managed settings that touch sandbox isolation now require approval
This one isn't described as a vulnerability fix so much as a policy tightening, but it belongs in the same list because it closes the same class of gap: "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." Any of those four behaviours, terminating TLS inside the sandbox, routing sandbox traffic through a proxy you control, injecting credentials, or weakening sandbox isolation generally, is powerful enough that Claude Code now insists on an explicit approval step before it takes effect, rather than applying a pushed managed setting automatically.
ANTHROPIC_CUSTOM_HEADERS gets the same treatment
"Changed ANTHROPIC_CUSTOM_HEADERSfrom managed or project settings to require approval when it sets a credential, org/tenant, routing, or API-behavior header (e.g.Authorization, Host)." Custom headers are a legitimate tool for LLM gateway setups and organisation-specific routing, but a header like Authorization or Host can redirect where a request actually goes or what credential it carries. Setting one of those specific header categories through managed or project settings now requires the same explicit approval, rather than applying silently the moment the setting is present.
A seventh fix, filed under bug fixes rather than security
One more change in the same release is worth flagging even though Anthropic's changelog lists it under "Notable bug fixes" rather than the security section: "Fixed Bash permission checks auto-approving arithmetic expressions in shell variables." Claude Code's Bash permission system is meant to evaluate a proposed command against your allow, ask and deny rules before running it. This fix addresses a case where an arithmetic expression embedded in a shell variable was being auto-approved rather than evaluated against those rules properly, which is the same broad category as the fixes above, a place where the permission check didn't actually cover what it was supposed to. It's not framed as a security fix by Anthropic, but it belongs in the same conversation: a permission check that can be sidestepped through a specific shell construct is exactly the kind of gap the rest of this release closes elsewhere.
What to actually do about this
Update. That's most of it. None of these fixes require you to change how you write permission rules, deny lists, or plugin configurations, they close gaps in how Claude Code enforced the rules you'd already written, not gaps in the rules themselves. Run claude --version to check your current version, and note that Claude Code's auto-update downloads new versions in the background but applies them only on the next launch, never mid-session, so a Claude Code process that's been running since before 28 August is still on the older version until you restart it.
The one place worth a second look is any organisation currently deploying managed settings that terminate sandbox TLS, route sandbox traffic through a proxy, inject credentials, weaken sandbox isolation, or set ANTHROPIC_CUSTOM_HEADERS with a sensitive header. Those now require an approval step they didn't before, and a deployment pipeline built around them applying unattended is worth checking against the new behaviour before assuming nothing has changed.
Troubleshooting
A managed setting I've deployed for years suddenly needs approval. Expected under v2.1.251 if it falls into one of the categories above: sandbox TLS termination, sandbox proxy routing, credential injection, weakened sandbox isolation, or a sensitive ANTHROPIC_CUSTOM_HEADERS value. This is the new approval gate, not a bug.
I want to confirm a Read(...) deny rule actually blocks a symlinked path now. Test it directly: point a symlink at the denied path from inside the working directory and try a Grep or Glob search that would previously have followed it. On v2.1.251 or later, the deny rule should apply the same way it would to a direct path.
A plugin command from a marketplace I trust suddenly fails with a path-traversal error. Check the plugin's marketplace entry for a command path that resolves outside its own plugin directory. This is the new rejection behaviour working as intended; a legitimately-scoped plugin shouldn't trigger it, so treat the error as a signal the plugin entry itself needs fixing rather than something to work around.
I can't tell whether any of this affected me before the update. Anthropic's release notes don't publish exploitation evidence or a disclosure timeline for these fixes, so there's no way to retroactively confirm whether a specific gap was used against a specific setup. The practical response is the same either way: update, and review any managed settings in the categories above.
Where to go next
For the permission model these fixes sit inside, see Claude Code's auto mode classifier rules explained and the --restricted flag for evaluation harnesses and shared machines, which covers a stricter mode built for exactly the kind of lower-trust environment where a symlink-based escape matters most. For the settings layer these fixes touch, see Claude Code's promptCacheTtl setting explained for how managed settings interact with session behaviour more broadly. Browse the full Claude Code changelog at code.claude.com/docs/en/changelog for the complete v2.1.251 release, and the rest of this site's Claude Code coverage at getclaudeskills.com/platforms/claude-code.
Verified 29 August 2026 directly against Claude Code's own changelog at code.claude.com/docs/en/changelog, read in full for the v2.1.251 entry (28 August 2026), which is the sole source for every fix described above. No CVE, advisory number, or third-party confirmation was found or used.
