Your Agent Never Escaped the Sandbox. It Did Not Need To.

What is a sandbox escape in an AI coding agent?

It is usually not an escape at all. In the disclosed 2026 cases, the agent did not break out of its container, defeat a hypervisor or exploit a kernel bug. It used its ordinary, intended ability to write files in the project it was working on, and one of those files happened to be an input to a program that runs with the user's full privileges.

Here is the disclosed set, which is worth reading as a list because the pattern only becomes obvious in aggregate.

Read the third column top to bottom. Four of the seven are a write, not a breakout. The agent produced a file; a trusted process consumed it; the trusted process was not in the box.

“

If an agent gets to write the future inputs of systems, it was never sandboxed in the first place.

The CSA calls this the Trust Handoff Flaw, and defines it precisely: the agent "stays inside the box and follows every rule", but writes a file, a hook configuration, a virtual environment interpreter, a Git config entry, a task definition, "that some other, unsandboxed tool consumes after the agent's turn ends."

That definition is doing more work than it looks. It relocates the security boundary from a place you can configure to a relationship you probably have not inventoried: the set of programs on the developer's machine that read project-local files and act on them without asking.

Why do the sandboxes keep failing the same way?

Because four assumptions keep reappearing in sandbox design, and agent behaviour invalidates all four. The CSA note names them, and they are worth stating as design errors rather than bugs, because each one will recur in the next product that ships an agent.

None of these are exotic. They are the standard failure modes of perimeter security, rediscovered in a new place, by teams shipping quickly into a category that did not exist two years ago.

GitSpawn: the same flaw, in the file every repository has

If the pattern still feels abstract, the disclosure from Manifold Security at the start of September 2026 makes it concrete, and it is the cleanest illustration of the whole argument.

core.fsmonitor is a Git performance setting. Its value is a command, which Git runs to work out which files changed. Git reads it from the repository's own .git/config. Coding agents call Git at startup to determine the branch and the changed files, so the command runs immediately, with the user's privileges, before any approval prompt exists to be shown.

Cloning a repository is now enough. There is no malicious dependency, no post-install script, no code to review, and nothing that a scanner reading source files would flag. The payload is in a configuration file most developers have never opened.

Two details deserve emphasis. First, the fixes are per-path rather than per-class: Manifold reported a second route into Claude Code still live on 2.1.252 after the first had been patched. Second, several agents were still confirmed vulnerable at disclosure. If your control is "we upgraded", your control has a version number and a race condition in it.

The mitigation Manifold recommends is worth doing today, takes one command, and is a good illustration of how narrow a per-issue fix is:

# Audit a repository you are about to open with an agent
git config --get core.fsmonitor

# Disable the mechanism globally
git config --global core.fsmonitor false

# Or strip it on individual background calls
git -c core.fsmonitor=false status

That closes core.fsmonitor. It does nothing for core.hooksPath, for .vscode/tasks.json, for a venv interpreter, for a .claude hook, or for the next configuration key someone notices is executable. You cannot patch your way out of a design property.

What a sandbox actually covers, and what it does not

To be fair to sandboxing, which is genuinely worth deploying: it does a real job, and the job is not nothing. It is just narrower than the marketing around it.

The bottom four rows are the ones that matter, and they share a property: the agent does nothing forbidden. Perimeter controls detect boundary violations. None of these are boundary violations.

There is one more failure that belongs here, because it is the most human of all. In March 2026, an issue was filed against Claude Code reporting that the sandbox setting in ~/.claude/settings.json was not applied when the agent ran inside the VS Code or Cursor extension: the extension spawned the native binary without the --sandbox flag, so the macOS Seatbelt profile was never applied even with sandbox.enabled: true. The reporter verified it by writing a file to ~/Desktop from inside a Cursor session. The issue was closed as a duplicate, and the workaround offered was to run the CLI directly or to use PreToolUse hooks as a substitute guard.

Whatever its status today, the class of problem is permanent: a sandbox is a configuration, configurations have surfaces that silently do not apply, and a control you believe is on is worse than one you know is off.

So what do you actually do?

Keep the sandbox. Stop treating it as the control. Then close the handoff, which is where the real exposure is.

This is the step nobody does, and it is the one the CSA calls for. List the programs on a developer machine that consume files from the working directory and act on them: the editor and its extensions, the language server, the Git client, the shell profile, the container runtime, the task runner, the test watcher. That list is your real attack surface. The sandbox does not appear on it.

A denylist requires you to have enumerated the OS. An allowlist requires you to have enumerated your own workflow, which is a problem you can actually finish. And validate what a command does, not what it is called: git show was on an allowlist because of its name.

No agent session should be able to reach the Docker socket, the Kubernetes config or any local endpoint more privileged than itself. This one is free and it removed an entire class from three products.

A change to .git/config, .vscode/, .claude/, .cursor/, a virtualenv interpreter or a CI workflow is not a code change. It is a change to what will execute next. It deserves a different approval path from a change to a React component, and today it usually gets the same one.

Environment variables travel with the process. A perfectly isolated sandbox that inherits AWS_SECRET_ACCESS_KEY has isolated the filesystem and published the credential.

Every item above is a hardening measure that a determined path will eventually route around, because they are all static. The thing that closes the class is evaluating the action at the moment it happens, with the ability to refuse it.

That last step is where our own product sits, so read the next three paragraphs with that in mind. The reason we think it follows from the evidence rather than from our roadmap is that the CSA reached the same structural conclusion without selling anything, and the workaround suggested in Anthropic's own issue tracker was a PreToolUse hook.

A hook sits where the sandbox cannot. It evaluates a tool call before it executes, which means it sees the write itself: this session is about to modify .git/config, or add a core.hooksPath, or edit a workflow file that runs on fork events with write permissions, or invoke a tool whose description changed since yesterday. Those are discrete, inspectable events with a subject and an object. A sandbox sees a process writing bytes into a permitted directory and has no basis on which to object, because nothing forbidden is happening.

It is a different question, not a stronger wall. The sandbox asks "is this process allowed to be here". The gate asks "should this specific action happen now". The Trust Handoff Flaw exists precisely because the first question has a satisfying answer while the second one goes unasked.

And it degrades honestly. Rules in the agent's context improve what it proposes, which is a real and probabilistic improvement. Findings in the loop mean a proposed change is reasoned against the repository's actual state. Only the hook is deterministic, and we would rather say which of the three is a control than imply all of them are. The wider version of this argument is in AI coding agent security.

Frequently asked questions

Is sandboxing enough to secure an AI coding agent?

No, and the 2026 disclosures show why with unusual clarity. Of the seven escapes reproduced across Cursor, Codex CLI, Gemini CLI and Antigravity, most did not involve breaking out of the sandbox at all. The agent wrote a file inside its permitted workspace, and a trusted process outside the sandbox executed it later. Sandboxing bounds the damage of a process that misbehaves inside the boundary, which is worth having. It cannot address an agent that behaves perfectly and hands its payload to something that was never in the box.

What is the Trust Handoff Flaw?

It is the name the Cloud Security Alliance gave, in a research note dated 22 July 2026, to the pattern behind the 2026 coding agent sandbox escapes. The agent stays inside its boundary and follows every rule, but writes a file, a hook configuration, a virtual environment interpreter, a Git config entry or a task definition, that some other unsandboxed tool consumes after the agent's turn ends. The note summarises it as: if an agent gets to write the future inputs of systems, it was never sandboxed in the first place.

Which AI coding agents had sandbox escapes in 2026?

Pillar Security's research reproduced escapes in Cursor, OpenAI's Codex CLI, Google's Gemini CLI and Google's Antigravity, seven in total, with at least four receiving vendor patches. Separately, Manifold Security's GitSpawn disclosure in September 2026 covered goose (CVE-2026-72718), Codex (CVE-2026-19592), Claude Code (CVE-2026-55607) and Hermes Agent (CVE-2026-71963), with Qwen Code and Grok Build also confirmed vulnerable at the time of disclosure.

Can a Git repository run code just by being opened?

Yes, and that is the GitSpawn finding. core.fsmonitor is a Git performance setting whose value is a command that Git executes to determine which files changed, and Git reads it from the repository's own .git/config. Coding agents call Git at startup, so the command runs with the user's privileges before any approval prompt appears. Auditing is one command, git config --get core.fsmonitor, and disabling it globally is git config --global core.fsmonitor false.

Should I use a microVM, gVisor or a container for my coding agent?

Pick based on your performance and GPU constraints, because for this threat class the choice barely matters. Firecracker gives you the strongest isolation, gVisor is a reasonable middle ground with a userspace kernel, and containers are the floor. None of the three changes whether an unsandboxed Python extension executes an interpreter the agent modified. Spend the decision effort on what the agent may write and which local programs trust it, and treat the isolation primitive as a blast-radius setting.

Does turning on my agent's sandbox setting actually sandbox it?

Verify it rather than assume it. In March 2026 an issue against Claude Code reported that sandbox.enabled: true in ~/.claude/settings.json had no effect when the agent ran inside the VS Code or Cursor extension, because the extension spawned the native binary without the --sandbox flag and the macOS Seatbelt profile was never applied. The reporter confirmed it by writing to ~/Desktop from a Cursor session. Test your own configuration by attempting a write outside the workspace and observing whether it is refused.

What is agent-time security, and how is it different from sandboxing?

Sandboxing is a perimeter question: is this process allowed to be in this place. Agent-time security is an action question: should this specific operation happen right now, and it can refuse. The difference is decisive for the Trust Handoff Flaw, because the write that causes the eventual execution is not a perimeter violation and looks entirely legitimate to an isolation layer. A gate that evaluates the tool call can see that the target is .git/config and decline it, which no amount of isolation strength will do.

Does this mean coding agent sandboxes are pointless?

Not at all, and abandoning them would be the wrong lesson. A sandbox reliably bounds the damage from a malicious dependency, a destructive command or a runaway loop, and those are common. The correction is to stop describing it as containment for an adversarial agent. It is a blast-radius reducer that sits alongside egress control, credential hygiene and an enforcement point on the actions themselves.