Codex Sandbox Escapes Show Why Agent Guardrails Can’t Live Inside the Agent

Most developers treat a cloned repository as something to read. A coding agent treats it as something to act on. That gap is where two newly disclosed flaws in OpenAI’s Codex did their work.

Oren Yomtov of Accomplish AI found two ways out of the Codex sandbox and named them Heapjack and Overpatch. Both let code run on the host machine with no approval prompt and nothing on screen. He reported them to OpenAI on August 12. OpenAI fixed both within eight days. Accomplish published the details on September 15.

The bugs are patched. The pattern behind them is the part DevOps teams should keep. A developer laptop often holds SSH keys, cloud credentials, and a path into production pipelines. Code that escapes the sandbox can reach whatever the developer can reach.

Start with Heapjack. Codex Desktop installs a helper called node_repl without asking the user to opt in. It runs JavaScript in one Node.js process with two contexts. One is trusted and holds a secret token. The other runs code from the agent. Both share a single memory heap.

That was enough. Untrusted code called v8.getHeapSnapshot() and scanned the result for a string shaped like the token. With the token, it sent forged requests over a pipe it shared with the parent process. The parent checked the token and nothing else. Then it ran the requested commands outside the sandbox.

The trigger is ordinary. Someone opens a cloned repository in read-only mode, the strictest setting, and asks Codex a question. Whoever wrote that repository gets command execution on the host.

Overpatch lives in the open-source Codex CLI. Its apply_patch tool works out what a patch may write by looking at the parent directory of each path the patch names. Name /tmp, and the granted access reaches the root of the disk. Yomtov built a patch with two entries. One wrote to a .zshrc file through a symlink into the home directory. The other named /tmp. That second entry failed, but the wider permissions stayed in place. The next time a shell started, the modified .zshrc ran code outside the sandbox. That change sticks around, too, because the file runs every time a shell opens. This one worked in workspace-write mode, again with no approval prompt.

The fixes are in Codex CLI 0.149.0 and Codex Desktop build 26.818.21641.

Yomtov’s summary of the root cause is short: “The thing doing the enforcement was sitting inside the thing being enforced.” In Overpatch, the patch tool decided its own permissions. In Heapjack, the trust token sat in memory that untrusted code could read.

This isn’t the first time researchers have found that shape. In July, Pillar Security’s Eilon Cohen, Dan Lisichkin and Ariel Fogel reported sandbox escapes across Cursor, Codex, Gemini CLI and Google Antigravity. Their mechanics were different. The agent stayed inside its sandbox but wrote files that trusted tools outside it later ran. Workspace configuration files, Git integrations, and Docker sockets all played a part. One Codex issue involved a command allowlist that trusted “git show” by name, even though the way it was invoked allowed writes. OpenAI fixed that one in version 0.95.0. Cymulate documented a similar configuration-based escape across Claude Code, Gemini CLI, and Codex CLI in April.

Different mechanics, same lesson.

Mitch Ashley, vice president and practice lead for CIO & technology buyers and software lifecycle engineering at The Futurum Group, puts the lesson in terms DevOps teams know. “A sandbox the agent can modify enforces nothing. Enforcement has to run in a layer the agent cannot reach, which means the control plane. CI teams settled this years ago when they stopped letting jobs grant themselves permissions.”

So what should teams do? Update first. Check every place Codex runs: laptops, the desktop app, the CLI, and CI runners. The desktop app and the CLI carry separate version numbers, so checking one doesn’t cover the other. A patched install on one machine says nothing about the rest.

Treat repositories you didn’t write as untrusted input, even when the agent is in read-only mode. Read-only mode did not stop Heapjack.

Don’t count on approval prompts alone. A prompt that never appears protects no one.

Put isolation somewhere the agent can’t reach. Accomplish’s own answer is to run the whole agent inside a VM, keep real credentials on the host, and route traffic through a proxy the agent can’t reach or change. A VM or container won’t be perfect either. But the enforcement lives outside the thing it restricts.

Ashley adds a point for buyers. “Agent deployment is gated by what a team can observe, control, and prove, well before it is gated by model capability. Ask vendors where the enforcement boundary runs, and how fast they patch it.” Eight days from report to patch is one data point.

Coding agents now run with the access CI jobs have long had, plus more autonomy. Repositories they didn’t write are routine input, not an edge case. Sandbox bugs will keep turning up. The design question is who enforces the rules and where that enforcer runs. If the answer is “inside the agent,” expect another Heapjack.