Claude Code's Edit tool could be raced into writing outside the project. What GHSA-5xjx-9qx6-jcrv says, and what to check

You turned on Claude Code's Bash sandbox on your Mac so the agent's commands stay inside the project. Then you let it run npm install on a repository you had not read. On October 26, Anthropic published an advisory that explains how code in that repository could have used the agent's own Edit tool to overwrite a file outside the project.

The advisory is GHSA-5xjx-9qx6-jcrv, "TOCTOU Race in Edit Tool Allows File Writes Outside the Workspace". It is rated High, 7.7 out of 10. Versions before 2.1.251 are affected, and 2.1.251 has the fix. If you keep Claude Code up to date, you already have it. The rest of this post explains what went wrong, who should still check something, and where the Bash sandbox ends.

It is based on the advisory and Anthropic's docs as of October 29, 2026. We make Sessionboxer, which runs the whole agent in a container; that part is near the end.

What the advisory says

TOCTOU means "time of check to time of use". A program checks that something is safe, then uses it a moment later, and in between someone changes it.

Here, Claude Code checked that the target of an Edit was inside the workspace by resolving the path and its symlinks at one point in time. The advisory says that check "was not bound to the underlying directory inodes or file descriptors". So the folder that passed the check did not have to be the folder that received the write.

On macOS, a process running inside Claude Code's Bash sandbox could wait for that check to pass and then atomically swap a folder in the workspace for a symlink. The Edit tool, which does not run inside the sandbox, then followed the symlink and overwrote "an attacker-selected user-writable file outside the workspace". The sandboxed process could not write there itself. It used the Edit tool to do it.

The advisory is clear about the precondition: exploiting it "required the ability to run attacker-controlled code inside the sandbox, such as through a malicious repository or dependency script". That is an ordinary day for a coding agent. It clones things, installs their dependencies and runs their tests.

It is the second advisory of this kind this month. GHSA-5j29-h97v-84ch, published October 5 and fixed in 2.1.129, describes a similar gap at write time: a file in the project replaced with a symlink so that Claude Code's output landed outside the project. Its example of a sensitive target is shell configuration. And Claude Code 2.1.309 fixed macOS denyWrite rules that did not apply when a folder was reached through a symlink.

Why the sandbox did not stop it

Claude Code's sandboxing docs say what the Bash sandbox covers. It restricts the shell commands the agent runs. Other tools are outside it: "tools such as Read, Edit, Write, WebFetch, and WebSearch follow permission rules instead." Command hooks, local MCP servers and helper commands "run with your full access".

So on your Mac there are two mechanisms side by side. The sandbox confines the commands. Permission rules and path checks inside the Claude Code process confine the file tools. Each can be correct on its own and still leave a gap where they meet. A confined command can shape the files and folders that an unconfined tool then trusts. Symlinks are one way to do that, and three of this month's fixes mention them.

Anthropic's sandbox environments page says the same thing in its own words: "The sandboxed Bash tool on its own constrains only shell commands, so it is not sufficient for fully unattended runs." Its advice for --dangerously-skip-permissions is to run the session "inside a container, a VM, or the sandbox runtime, so that file tools, MCP servers, and hooks are also inside the boundary."

What to check today

The fix is old enough that most people have it. The places to look are the copies that do not update themselves.

1. Run claude --version on every machine you use. Anything at 2.1.251 or later has this fix; the current release on GitHub is 2.1.312.
2. Know how each copy was installed. The setup docs say native installations "automatically update in the background", while Homebrew and WinGet installations "do not auto-update". Run brew upgrade claude-code or winget upgrade Anthropic.ClaudeCode for those.
3. Search your Dockerfiles, dev containers and CI images for a pinned @anthropic-ai/claude-code@ version. A pin below 2.1.251 stays vulnerable until you change it.
4. If you used an older version on a Mac with the sandbox on and with repositories you do not trust, look at the files a write like this would target. The advisory does not list any. The October 5 one names shell configuration, so ~/.zshrc, ~/.bashrc, ~/.profile and what they source are a good start. Check them for lines you did not write.
5. For unattended runs on code you have not read, move the whole agent into a container or VM, as Anthropic's page recommends. Our guide to running Claude Code with --dangerously-skip-permissions safely compares the options.

There is nothing to configure that would have closed this gap on an affected version. It was a bug in how the Edit tool checked paths, and updating is the fix.

Where Sessionboxer fits

Sessionboxer gives each session its own Docker container. The repositories are cloned into the box, or a folder from your machine is copied into it. Claude Code runs in that box with every permission granted: the image sets bypassPermissions and does not turn on the Bash sandbox.

That changes what a race like this one can reach. The Edit tool runs in the same container as the agent's commands, so there is one boundary for both, and a symlink in /workspace that points outside the project points into the container's own filesystem. Your home directory is not mounted in the box. A host folder is a copy, and when you bring the agent's work back with Pull to folder…, the Start a session chapter says that "symlinks that would point outside your folder are never written."

The image pins Claude Code 2.1.272, which is newer than both fixed versions. QEMU · macOS sessions, where the agent runs on a Mac VM, install the same pinned version.

What Sessionboxer does not do:

• Inside the box, the agent can write anything its user can write, including the box's own shell files. If a dependency script tampers with them, it tampers with that session. Deleting the session removes it, and a snapshot taken before the install lets you start again from a clean point; the snapshots and forks chapter shows how.
• The agent's login token is handed to the box, so code that runs there can read it.
• Network egress from the box is not restricted, so whatever it reads can be sent out.
• A container shares the host kernel, so it is a weaker wall than a VM.
• New Claude Code fixes reach the box only when we ship a new image, so for those you wait for us.

The short version

• GHSA-5xjx-9qx6-jcrv, published October 26, describes a race on macOS: a command in Claude Code's Bash sandbox could swap a folder for a symlink and make the unsandboxed Edit tool overwrite a file outside the project.
• It needed attacker code in the sandbox, such as a malicious repository or dependency script. Version 2.1.251 fixed it, and auto-updating installs already have it.
• Check Homebrew, WinGet and pinned container copies, and look at your shell startup files if you ran untrusted code on an old version.
• The Bash sandbox confines shell commands only. For untrusted code and unattended runs, put the whole agent inside a container or VM.