On this page
- What is a sandbox escape in an AI coding agent?
- Why do the sandboxes keep failing the same way?
- GitSpawn: the same flaw, in the file every repository has
- What a sandbox actually covers, and what it does not
- So what do you actually do?
- Frequently asked questions
- Is sandboxing enough to secure an AI coding agent?
- What is the Trust Handoff Flaw?
- Which AI coding agents had sandbox escapes in 2026?
- Can a Git repository run code just by being opened?
- Should I use a microVM, gVisor or a container for my coding agent?
- Does turning on my agent's sandbox setting actually sandbox it?
- What is agent-time security, and how is it different from sandboxing?
- Does this mean coding agent sandboxes are pointless?
Over several months in 2026, Pillar Security reproduced seven sandbox escapes across four of the most widely deployed coding agents: Cursor, OpenAI's Codex CLI, Google's Gemini CLI and Antigravity. The interesting part is not that the sandboxes failed. It is how. In almost every case the agent stayed inside its boundary and followed every rule it had been given. It simply wrote a file, a hook config, a virtualenv interpreter, a Git setting, a task definition, that something else, running outside the sandbox, picked up and executed after the agent's turn had ended. No rule was broken. The Cloud Security Alliance, summarising the work in a research note dated 22 July 2026, gave the pattern a name and relayed the researchers' one-sentence verdict, which should be on the wall of anyone currently choosing between Firecracker and gVisor.
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, published by Pillar as one post a day, which is worth reading as a list because the pattern only becomes obvious in aggregate.
| Escape | Agent | What happened | Status |
|---|---|---|---|
| Claude hook config | Cursor | A workspace-controlled .claude hook ran outside the sandbox | Fixed 3.0.0, CVE-2026-48124 |
| Docker socket | Codex, Cursor, Gemini CLI | A privileged daemon was reachable from inside | Fixed by Cursor in 3.0.0, GHSA-v4xv-rqh3-w9mc, CVE-2026-73218; OpenAI filed it as informational and shipped nothing, Google called it documented behaviour then denied the sockets in Gemini CLI 0.58.0 |
| Virtualenv interpreter | Cursor | The agent edited a venv, a Python extension ran it | Fixed 3.1.2, GHSA-p9g2-cr55-cw9c, CVE-2026-73217 |
| Git metadata | Cursor | A non-standard Git dir bypassed the path rules | Patched 3.0.0 |
| Git allowlist | Codex CLI | The allowlist trusted the name, not the arguments | Patched 0.95.0 |
| Seatbelt denylist | Antigravity | A denylist profile left OS features reachable | Downgraded by Google, unpatched at disclosure |
| VS Code task | Antigravity | The agent wrote a task the host ran later | Downgraded by Google, unpatched at disclosure |
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, quoting Pillar's researchers, 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.
Delivery is the part to be precise about, and Manifold is: "Cloning a hostile URL does nothing, and neither does fetch or pull." An ordinary git clone does not carry the source repository's .git/config. The repository has to arrive as files, with its .git directory already inside: a shared .zip archive, a synced folder, a shared drive, a USB stick. From there, opening that folder with an agent is 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.
| Agent | Advisory | Status, checked at source on 20 September 2026 |
|---|---|---|
| goose | CVE-2026-72718 | Fixed in 1.44.0 |
| Codex CLI | CVE-2026-19592, OpenAI's own record, which Manifold does not cite | core.fsmonitor flaw fixed in 0.131.0 per the CVE record. Manifold's own Codex report was closed as a duplicate; its post says patched, without a version |
| Claude Code | No CVE cited by Manifold | core.fsmonitor path confirmed on 2.1.193, fixed by 2.1.196, report closed as a duplicate. A second path was still unpatched on 2.1.252 on 1 September |
| Hermes Agent | CVE-2026-71963, assigned by VulnCheck | Confirmed vulnerable in 0.18.2 and 0.21.0, unpatched at disclosure. The CVE record, published 3 September, lists a fix in commit f6234d0 |
| Qwen Code | Reported by Manifold | Confirmed vulnerable in 0.22.3 |
| Grok Build | Reported by Manifold | Confirmed vulnerable in 0.2.93 and 1.0.13 |
| Cursor | Reported by Manifold | Patched; report closed as a duplicate of an earlier one |
Three details deserve emphasis. First, the fixes are per-path rather than per-class: Manifold reported a second route into Claude Code, through a different Git setting, still live on 2.1.252 after the first had been patched. Second, several agents were still confirmed vulnerable at disclosure: Manifold counts eight findings across seven agents, four of them still unpatched at publication. Third, identifiers need care. Manifold cites no CVE for its Claude Code finding, and the Claude Code identifier it is easy to confuse with, CVE-2026-55607, describes a different flaw: a sandbox escape through Git worktree path confusion, present from 2.1.38 and fixed in 2.1.163, well before the 2.1.193 on which Manifold confirmed its own. If your control is "we upgraded", your control has a version number and a race condition in it.
What actually protects you is narrower than it looks, so it is worth being exact. Manifold gives two pieces of advice. If you receive a repository as files, inspect .git/config before you open the directory with an agent, because "any setting that names a program can run it". If you ship an agent, or just a script that calls Git in the background, sanitize the Git config on those calls, for example with git -c core. The third step is ours: update the agent, since the table above shows which versions carry a fix.
# A repository that arrived as files: read its config before an agent opens it
cat .git/config
# In a tool or a script that calls Git in the background, override the key on the call itself
git -c core.fsmonitor=false status
The global setting that is often recommended instead, git config --global core, does not protect you. The Git documentation lists the configuration files in order, system, then global, then the repository's own .git/config, and states that they "are read in the order given above, with last value found taking precedence over values read earlier." The repository's value is read after your global one, so a booby-trapped .git/config wins. The -c option is the exception: per the Git manual, its value "will override values from configuration files."
Even done properly, this handles core.fsmonitor and nothing else. 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.
| Threat | Sandbox | Why |
|---|---|---|
Agent runs rm -rf outside the workspace | Covered | Filesystem confinement is exactly what it is for |
| A malicious dependency executes on install | Covered | Blast radius is bounded to the sandbox |
| Agent exfiltrates a secret over the network | Partly | Only if egress is default-deny, which is rarely the default |
| Agent reads credentials passed as env vars | Not covered | Environment variables cross the boundary with the process |
| Agent writes a hook, task or Git config a trusted tool later runs | Not covered | The write is legitimate; the execution happens elsewhere |
| Agent writes plausible, insecure application code | Not covered | Nothing about the code is a policy violation |
| Agent opens a pull request that nobody meaningfully reviews | Not covered | Different layer entirely, see reviewing agent pull requests |
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 ~ 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. The reporter verified it by writing a file to ~/Desktop from inside a Cursor session. The issue was closed as a duplicate four days later, and the only workaround on record is the reporter's own: run the CLI directly, or 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.
Inventory what reads project-local files without asking
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.
Prefer allowlists over denylists, and model arguments
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 showwas on an allowlist because of its name.Cut the privileged daemons
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. Cursor closed it in one release and Gemini CLI followed in 0.58.0; OpenAI has published no fix for Codex.
Treat config writes as privileged operations
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.Scrub the environment before you scrub the filesystem
Environment variables travel with the process. A perfectly isolated sandbox that inherits
AWShas isolated the filesystem and published the credential._SECRET _ACCESS _KEY Put the decision on the write, not on the perimeter
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 a user left 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 borrows Pillar's one-line summary: 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 by the CSA's count. Separately, Manifold Security's GitSpawn disclosure of 1 September 2026 covered goose (CVE-2026-72718, fixed in 1.44.0), Claude Code (no CVE cited: the core.fsmonitor path was fixed by 2.1.196, a second path was still open on 2.1.252), Hermes Agent (CVE-2026-71963), Qwen Code and Grok Build, the last three still unpatched at disclosure. Manifold also found Codex and Cursor affected, both since patched; OpenAI's own record for the core.fsmonitor flaw in Codex CLI is CVE-2026-19592, fixed in 0.131.0.
Can a Git repository run code just by being opened?
Yes, if it reached you as files rather than through git clone. 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. That is the GitSpawn finding, and Manifold is precise about delivery: an ordinary clone does not carry the source's .git/config, so the repository has to arrive with its .git directory already inside, as a shared .zip archive, a synced folder, a shared drive or a USB stick. Read .git/config before opening such a folder with an agent. git config --global core does not help, because Git reads the repository's file after the global one and the last value wins; only git -c core, on the command itself, overrides it.
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 in ~ 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.