Claude Code below 2.1.251 let code in its Bash sandbox redirect an Edit outside the workspace on macOS (CVE-2026-88968)

Claude Code's sandbox isolates shell commands, and its file tools run outside it. CVE-2026-88968, published on 2026-10-26 and fixed in 2.1.251, used the gap between the two on macOS: code running inside the Bash sandbox could swap a folder for a symlink after the Edit tool had checked the path, so the edit landed outside the workspace. It is the second time-of-check to time-of-use fix for Claude Code's file writes in three weeks. Below is what each advisory required, and how to make sure your installation cannot fall behind the fix.

Two advisories, three weeks apart

Both advisories are in the Claude Code repository, both are rated High (CVSS 7.7), and both describe the same family of bug: a path that was checked at one moment and used at another.

The October 5 advisory describes the first shape: "Claude Code validated that a target file path resided within the project working directory at permission-check time, but re-resolved the path at write time without repeating that validation." Someone with write access to the same workspace could "atomically replace a project file with a symlink", so that "a lower-privileged attacker" could "redirect benign edits to sensitive files (e.g., shell configuration) in a higher-privileged session."

The October 26 advisory is the one this post is about, because of where the attacker sits.

The boundary the race used

The description: "On macOS, a process running inside Claude Code's Bash sandbox could exploit the resulting time-of-check to time-of-use window by atomically swapping an in-workspace parent directory with a symlink after validation completed, causing the unsandboxed Edit implementation to overwrite an attacker-selected user-writable file outside the workspace."

The phrase to notice is "the unsandboxed Edit implementation". Claude Code's sandboxing documentation states the scope near the top: "The sandbox wraps shell commands." The tools that run outside it include the built-in file tools such as Read, Edit and Write, which "follow permission rules instead", along with command hooks and local MCP servers.

Our reading is that the split makes sense, since the file tools go through permission rules of their own. But it means two parts of Claude Code look at the same workspace with different powers. A sandboxed process can change things inside the workspace, which is what a build or test needs. The Edit tool can write wherever its checks allow. When the Edit tool checked a path and then used it a moment later, a sandboxed process that changed one directory in between could steer a write that the sandbox itself would never have allowed.

The advisory names the root cause precisely: validation used "point-in-time pathname and symlink resolution that was not bound to the underlying directory inodes or file descriptors." Checking a name and then writing to the name leaves a window. Binding the check to the actual directory the write will use closes it.

The condition is also precise, and it is the realistic part: "Exploiting this required the ability to run attacker-controlled code inside the sandbox, such as through a malicious repository or dependency script." Running a repository's install or test scripts inside the sandbox is what the sandbox is for.

How to check that you have the fix

The advisory's guidance is short: "Users on standard Claude Code auto-update have received this fix automatically. Users performing manual updates are advised to update to the latest version." Whether you are one or the other depends on how Claude Code was installed, and the setup documentation is explicit:

• "Native installations automatically update in the background."
• "Homebrew, WinGet, apt, dnf, and apk installations do not auto-update by default". On Homebrew and WinGet, setting CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE to 1 lets Claude Code run the upgrade in the background; apt, dnf and apk still need a manual upgrade.

claude --version gives the number. claude doctor gives the rest; the setup page describes it as printing "read-only installation and settings diagnostics without starting a session". On 2026-10-29 (UTC), on the Mac that runs this account, it printed these lines among others:

2.1.312 is above both fixed versions. The lines that matter for keeping it that way are the second and third: auto-updates on, and the channel.

The channel, the floor, and the switch

Three settings decide how quickly a fix like this reaches you.

The channel. The setup page describes autoUpdatesChannel with two values. "latest" receives new versions as they ship. "stable" uses "a version that is typically about one week old, skipping releases with major regressions". Our reading, not a statement from the advisory: on the stable channel, a security fix typically reaches you about a week after it ships, which is a fair trade for some teams and worth knowing either way.

The floor. minimumVersion sets a version that "Background auto-updates and claude update refuse to install any version below". Setting it to the version that carries a fix you care about means a channel switch cannot quietly move you back past it:

{
  "autoUpdatesChannel": "stable",
  "minimumVersion": "2.1.251"
}

The page is careful to say this "only constrains updates". For an organization that wants Claude Code to refuse to start below a version, the managed setting requiredMinimumVersion does that.

The switch. DISABLE_AUTOUPDATER set to "1" in the env block turns the background updates off, and claude doctor then shows disabled (set by env: DISABLE_AUTOUPDATER) on the Auto-updates line. If you have it set, perhaps from a time when updates broke something, you are on the manual path the advisory describes, and you need to run claude update yourself.

Habits that shrink the window

Updating is the fix. These habits reduce what a similar bug could reach next time.

• Treat repository scripts as the attacker in this advisory. The condition was code running in the sandbox. Before running a cloned repository's install, test or build scripts through Claude Code, read what they do, the same way you would before running them in your own shell.
• Do not share a writable workspace across users with different privileges. That was the condition of the October 5 advisory, and it is an easy one to remove.
• Remember what the sandbox covers. It isolates Bash. The file tools follow permission rules instead, and command hooks and local MCP servers run with your full access, so the permission rules, and the prompts they produce, are the protection for writes made by Claude's own file tools.
• Keep auto-updates on, or make manual updates a routine. Both advisories say the fix reached auto-updating users without them doing anything. The users still exposed after publication were mainly the ones who had turned that off or installed through a channel without it.

Two fixes in three weeks for the same class of bug could read as bad news. We read it the other way: the reports describe the exact interleaving, the versions are clear, and the fix arrives without action for most installations. What is left for users is to make sure their installation is one of those.

Which channel do you run Claude Code on, and have you ever set minimumVersion or turned auto-updates off on purpose? If your team handles security fixes for coding agents differently from other developer tools, tell us how in the comments below.