Product1 publisher3 min readPublished
Codex's read-only mode handed a cloned repository command execution on the host
Oren Yomtov of Accomplish found two ways out of the Codex sandbox, both silent and neither stopped by an approval prompt. OpenAI patched them within eight days, and other researchers have found the same design in rival agents.
The Product Desk · Product desk
What happened
- Oren Yomtov of Accomplish disclosed two OpenAI Codex sandbox escapes, Heapjack and Overpatch, both of which ran code on the host with no approval prompt and nothing shown on screen.
- Heapjack reached unsandboxed command execution from Codex's read-only mode by pulling a trust token out of a V8 heap shared between the trusted and untrusted contexts.
- Yomtov reported both issues on August 12, 2026, and Accomplish says OpenAI fixed them within eight days, with the fixes landing in Codex CLI 0.149.0 and Codex Desktop build 26.818.21641.
- Pillar Security researchers reported escapes in July across Cursor, Codex, Gemini CLI and Google Antigravity, and Cymulate documented a configuration-based escape in Claude Code, Gemini CLI and Codex CLI in April.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- constraint Anyone whose risk register lists the agent running in read-only mode as the mitigation is relying on the setting Heapjack ran from. The control that survives this has to sit outside the agent process.
- exposure Exposure follows the developer's credentials, not the repository's contents. A curious clone opened on a laptop with cloud keys and pipeline access puts the pipeline within reach of whoever wrote the repo.
- decision Patching becomes an inventory problem: someone has to find every laptop, desktop install, CLI copy and CI runner below the fixed builds, and agent CLIs rarely appear in an asset register.
- precedent With three separate write-ups now touching Codex, Cursor, Gemini CLI, Antigravity and Claude Code, the defensible default for the next agent release is to treat its sandbox as one layer among others.
Walk Overpatch through slowly. The apply_patch tool decides what a patch may write by looking at the parent directory of every path the patch names, so a patch that names /tmp is granted access reaching the root of the disk [7]. Yomtov's patch had two entries. One wrote to a .zshrc file through a symlink into the home directory; the other named /tmp, failed, and left the wider permissions already granted in place [8]. The next shell to open ran the modified .zshrc outside the sandbox, and it runs on every shell after that. Codex was in workspace-write mode, and no approval prompt appeared [9].
Heapjack asked even less of the user. Codex Desktop installs a helper called node_repl with no opt-in, and that helper runs the trusted context holding a secret token and the agent's untrusted code in one Node.js process on one heap [4]. The untrusted side called v8.getHeapSnapshot(), scanned the dump for a string shaped like the token, then forged requests over the pipe it shared with the parent process, which checked the token and nothing else before running commands outside the sandbox [5]. The trigger was a developer opening a cloned repository in read-only mode, the strictest setting Codex offers, and asking a question [6].
Read-only is the mode a team writes down in a security review. Cloning an unfamiliar repository and asking the agent what it does is what developers actually do, and the agent acts on that clone [22]. The laptop it acts on tends to hold SSH keys, cloud credentials and a path into production pipelines [19].
"The thing doing the enforcement was sitting inside the thing being enforced," Yomtov said of the root cause [14]. In Overpatch the patch tool decided its own permissions; in Heapjack the token sat in memory the untrusted code could read [21].
The same design has produced different bugs. One earlier Codex issue came from a command allowlist that trusted "git show" by name even though the way it was invoked allowed writes, and OpenAI fixed it in version 0.95.0 [17].
Timing matters for whoever owns the rollout. Yomtov reported both bugs on August 12, 2026 and OpenAI fixed them within eight days [10]; Accomplish published the details on September 15 [11]. The patch was therefore available for roughly 26 days before anyone outside the two parties knew why to install it [13].
Mitch Ashley, vice president and practice lead at The Futurum, said: "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." [15]
Two lines per host will tell you where you stand: the credential the agent can reach from there, and the thing outside the agent process that would have stopped Heapjack. Where the second line says "the approval prompt" or "read-only mode", both bugs have already answered it. Accomplish's own advice is narrower and immediate, and it is the part to do first: Codex CLI 0.149.0 or later, Codex Desktop build 26.818.21641 or later, checked in every place Codex runs including CI runners, with unfamiliar repositories treated as untrusted input [12][20].
What to watch
- Whether OpenAI moves node_repl to opt-in or splits the trusted and untrusted contexts into separate processes, instead of patching the token check.
- Whether the next agent escape lands somewhere with no pinned fixed version to roll out.
- Whether Pillar Security or Cymulate publish escapes in other products that use the same parent-directory permission check as apply_patch.