I wrote about what sandboxing actually is two days ago, using it to explain why GhostJacking worked. I didn’t expect to be back here again this fast, but a fresh disclosure landed this week that’s really the same story showing up for the fourth documented time this year.
The newest one: a stealth security startup called Accomplish flagged sandbox-leak issues to Anthropic, Cursor, and OpenAI. Cursor and OpenAI shipped fixes in about a week. Anthropic’s fix, for a comparable issue, took 50 days. Accomplish’s actual point isn’t “gotcha” — it’s that these are becoming structural, not one-off bugs.
Here’s why that framing holds up: the same underlying pattern has been independently rediscovered by four separate research groups this year, each giving it a different name. Cymulate called it “Configuration-Based Sandbox Escape” back in April, after finding it in Claude Code, Gemini CLI, and Codex CLI. Pillar Security found seven variants across Cursor, Codex CLI, Gemini CLI, and Antigravity in July — a Cursor hooks file, a modified Python virtualenv, non-standard Git metadata, all reaching code execution outside the sandbox boundary. Most recently, a researcher group called Manifold published findings under the name GitSpawn, tracing the exact same shape through a repository’s .git directory triggering an unsandboxed helper process at session startup.
The mechanism is consistent across all four: the agent writes a file inside its own sandbox — a config, a git metadata file, a modified interpreter. That part is safely contained. The problem is a second, separate piece of “trusted” tooling on the host — the editor’s Python extension, a VS Code task runner, Git’s own fsmonitor — later reads that file and acts on it, outside the sandbox entirely. The sandbox never gets breached directly. It just becomes the delivery mechanism for a file that something else, sitting right next to it with more privileges, will trust.
The part that actually stopped me: when Manifold retested on September 1, fixes had shipped for goose, Claude Code, and Cursor — but Hermes Agent, Qwen Code, and Grok Build were still executing repository-supplied commands through the identical pattern. I’ve covered both Hermes Agent and Qwen Code on this site. Neither post mentioned this, because neither existed when I wrote them. It’s a good reminder that a tool being actively maintained doesn’t mean every known class of vulnerability affecting the category has been checked against it yet.
If there’s a lesson from watching this recur four times with four different names, it’s that “the agent runs in a sandbox” is necessary but not sufficient. The sandbox boundary was never actually crossed in any of these — the vulnerability lives in the handoff to whatever trusted tool reads the agent’s output next, which is exactly the fifth layer worth double-checking beyond the four I listed there.
