Researchers escaped the OpenAI Codex sandbox twice: read-only mode reached command execution on the host

Eight days, and the strictest mode was never a wall

Eight days is how long it took OpenAI to fix two ways out of the Codex sandbox after they were reported on 12 August 2026. That is fast, and it is to the company's credit. But the number worth sitting with is not eight. It is zero: the number of approval prompts a developer saw before untrusted code from someone else's repository ran commands on their machine, from the sandbox mode that is supposed to let the agent write nothing at all.

The research comes from Oren Yomtov of Accomplish AI, a firm that builds a sandboxed environment for coding agents and therefore has a commercial interest in the finding. That interest does not make the two bugs less real, and both are now closed in shipped code you can inspect. We have read the primary write-up, OpenAI's own Codex sandbox documentation, the Codex CLI release notes and the pull requests that carry the fixes, and this briefing rests on those rather than on the coverage.

The two escapes are named Overpatch and Heapjack. One defeats the everyday workspace-write mode of the open-source Codex CLI and hands the agent write access to the whole disk with no prompt. The other defeats read-only, the strictest mode Codex has, in the closed-source Codex Desktop app, and ends in unsandboxed command execution on the host. They are different bugs in different components, but they fail in the same way, and that shared shape is the point of this piece.

What the Codex sandbox is a claim about

Before the escapes, it is worth reading what OpenAI says the sandbox is for, because the marketing and the mechanism are not the same thing. OpenAI's own documentation is clear and, to its credit, careful. The sandbox is described as the boundary that lets the agent act autonomously without unrestricted access to your machine. When a task stays inside the boundary the agent keeps moving; when it needs to cross, an approval prompt takes over. Sandboxing and approvals are two separate controls: the sandbox defines the technical limit, the approval policy decides when the agent must stop and ask.

The documentation names three modes. In read-only the agent can inspect files but cannot edit them or run commands without approval. In workspace-write, the default for local work, it can read, edit inside the project folder, and run routine commands, but network access is off and writing outside the workspace needs approval. Only danger-full-access removes the boundary. Both escapes take a mode that is meant to hold and get past it: Overpatch out of workspace-write, Heapjack out of read-only.

The most honest sentence in OpenAI's own docs is this one, about why the model matters: you are not just trusting the agent's intentions, you are trusting that it is operating inside enforced limits. That is exactly the claim these two bugs falsify. And the enforcement is real engineering, not a prompt: on macOS Codex uses Apple's Seatbelt through sandbox-exec; on Linux it uses bubblewrap plus seccomp; on Windows it uses a native Windows sandbox, or the Linux implementation under WSL2. A defender should know which of these is actually in force on each machine, because the answer differs by operating system and by whether the developer runs the CLI, the desktop app or the IDE extension.

The two escapes, from Accomplish AI's write-up of 15 September 2026 and the Codex CLI 0.149.0 release notes of 20 August 2026

Detail	Overpatch	Heapjack
Product	Codex CLI (open source)	Codex Desktop (closed source)
Mode defeated	workspace-write	read-only (strictest)
Component	apply_patch tool	node_repl JavaScript tool
Result	Write anywhere on disk, no prompt	Unsandboxed command execution on host
Affected	codex-cli 0.148.0 and earlier	Codex Desktop 26.623.141536 and earlier
Fixed in	Codex CLI 0.149.0	Codex Desktop 26.818.21641

Heapjack: the secret sat in the same memory as the code it was meant to exclude

Heapjack is the more serious of the two, so take it first. Codex Desktop writes a node_repl tool into the global ~/.codex/config.toml file when it installs. There is no opt-in and no setting to turn it off, and because the entry lives in the shared config, plain Codex CLI users on the same machine inherit the tool without ever being asked. That default-on, no-opt-out design is itself a finding: it widens who is exposed well beyond the people who chose to run the desktop app.

The tool is a native, unsandboxed helper that can open applications, connect to Unix sockets and edit the global config file. It launches a Node.js process through the Codex sandbox, so the JavaScript inside is sandboxed. Within that one process there are two execution contexts: a trusted one holding OpenAI's own code, and an untrusted one running the agent's code. The trusted context proves it is trusted by presenting a random token, generated fresh each run.

The flaw is architectural, not a typo. Both contexts live in one process and share one memory heap, so the token is just a string sitting in memory the untrusted side can read. The untrusted code takes a snapshot of the heap and tries every string shaped like a token; a wrong guess is rejected, a correct one with a deliberately bad argument comes back with a real validation error, which confirms the guess. With the token in hand, the untrusted code writes its own request onto the same pipe the trusted context uses to talk to the unsandboxed native parent. The parent checks the token, sees a valid one, and does the work.

The proof of concept used the system's open command to launch an application outside the sandboxed process tree entirely. The same access reaches any Unix socket, with a Docker daemon socket the obvious target, and a tool for editing the global config. All of it runs at read-only, where the agent is supposed to write nothing, and Codex never asks to approve anything. In the researchers' own summary of the practical attack: open a cloned repository in Codex in read-only mode, ask it a question about the code, and whoever wrote that repository gets unsandboxed command execution on your computer, with no prompt and nothing shown on screen.

Overpatch: the patch tool worked out its own permissions from attacker input

Overpatch is simpler and sits in the open-source CLI, so the mechanism can be read in the fix itself. In workspace-write mode the agent may only write inside the project folder, and a shell command aimed at the home directory is refused. The researchers got Codex's own patch tool, apply_patch, to write there anyway.

The tool grants write access to the parent folder of each path named in a patch. Name a path under /tmp and it grants write access to the root of the disk. The working exploit uses a patch with two changes: one names a path that only widens the permission and does nothing useful, and one appends a line to the shell startup file .zshrc through a symbolic link into the home directory. Remove the widening change and the write is refused. Keep it, and the next terminal the developer opens runs the attacker's line, unsandboxed.

OpenAI's fix is visible in Codex CLI 0.149.0. One pull request, titled 'Prevent apply_patch from widening write permissions', stops the tool deriving extra parent-directory access for targets already covered by the sandbox policy. A second, 'Harden unsandboxed patch filesystem access', rejects symbolic links in any path component so a path cannot be swapped for a link after it is checked. The same release also hardened the macOS Seatbelt writable roots against exactly this style of rename-and-redirect trick. The root cause, in OpenAI's own words in that pull request, was that deriving permissions from the parent of a patch target could grant write access outside the intended workspace.

Note what class of fix this is. It is not detection, not monitoring, not a warning added to a prompt. It is the enforcement boundary being corrected so that attacker-controlled input can no longer decide what is inside it. That is the right kind of fix, and it is the kind a defender should look for when they read any sandbox advisory.

The shape both bugs share, and why it matters more than either bug

Strip the two escapes down and they are the same mistake. In Overpatch, apply_patch computed its own permissions from paths an attacker supplied. In Heapjack, node_repl kept the secret that separated trusted code from untrusted code in the same memory as the untrusted code. In each case the thing doing the enforcing was living inside the thing it was supposed to enforce, so the boundary could be told, from the inside, to let something through.

This is why a comforting label is not a control. The word read-only names an intention. It does not, on its own, name the mechanism that enforces it, and Heapjack shows that the mechanism can be present and still be defeated because a trust decision was made in the wrong place. The same trap caught this site's readers three days ago in a different form: on 18 September we covered Plugin4Shell, where a pinned plugin commit felt immutable and was not, because nobody checked what the pinned reference actually resolved to. Pinned, sandboxed, read-only: each is a claim about a boundary, and a claim is not an enforcement point.

What is on the record, and what is conspicuously not

OpenAI resolved both issues within eight days, and Codex CLI 0.149.0 shipped on 20 August 2026 carrying the Overpatch fixes in its public changelog. The Heapjack fix landed in the closed-source Codex Desktop, so the mechanism is not visible in a public commit; the fixed build number comes from the researchers, not from an OpenAI page describing the flaw. As of this writing there is no OpenAI advisory that names Overpatch or Heapjack, and OpenAI's public statement thanks the researchers and says it addressed both issues in August, without describing them.

Neither escape carries a CVE. That is not unusual, but it is worth naming, because the same vendor did assign CVEs to a separate batch of Codex weaknesses at almost the same time. On 1 September 2026 OpenAI, acting as its own CVE numbering authority, published four records for a different class of problem: repositories whose preserved local Git configuration could run attacker-controlled code through settings such as core.hooksPath and core.fsmonitor, outside the sandbox and without a prompt. One of those, CVE-2026-19593, carries a CVSS base score of 9.8. So the absence of a CVE for Overpatch and Heapjack tells you about disclosure choices, not about severity.

What the primary record states and does not state, from OpenAI GitHub releases, the Accomplish AI write-up and the NVD records

Question	On the record	Not on the record
Reported	12 August 2026, to OpenAI	Whether found in the wild before that
Fixed	CLI 0.149.0 on 20 August; Desktop 26.818.21641	A dated OpenAI page describing either flaw
Named advisory	No CVE for Overpatch or Heapjack	Why these were handled without CVEs
Exploitation	None reported by any party	A vendor statement ruling it out

The Git-config CVEs are a useful contrast for another reason: they are the same category of trap. Attacker-controlled configuration inside a repository steered a trusted tool that ran outside the sandbox. Overpatch, Heapjack and the Git-config four all reduce to the agent trusting input from the very artefact it was asked to treat as untrusted.

What an engineering leader should require before trusting an agent sandbox

The reason this matters beyond one vendor is that teams have started to lean on these sandboxes to run agents unattended: overnight refactors, CI-triggered fixes, batch jobs across many repositories. The moment a human is not watching every command, the sandbox is the only thing standing between an untrusted repository and the developer's machine and credentials. So the question is not whether you like Codex. It is what you should demand of any agent sandbox, this one included, before you let it run without a person at the keyboard.

Four things are worth insisting on. First, independent testing: a sandbox that has only ever been tested by the team that built it is a claim, and both of these escapes came from an outside party looking specifically for the boundary to leak. Second, the platform primitive it is built on: Codex's use of Seatbelt, bubblewrap and the native Windows sandbox is genuine OS-level enforcement, which is stronger than a policy the agent applies to itself, and you should be able to name which primitive is in force. Third, what it does on each operating system, because the answer differs: the macOS, Linux, WSL2 and native Windows paths are not the same code and do not fail the same way. Fourth, what happens on escape: if the boundary is breached, is there a second layer, such as running the whole agent inside a virtual machine or container with no real credentials and egress through a proxy the agent cannot reach, so that a breach reaches a disposable guest rather than your laptop.

The question that exposes the gap

This analysis was researched with Claude, made by Anthropic, which is a competitor of OpenAI and whose own Claude Code has a sandbox that the same researchers escaped four days before this one, fixed in Claude Code 2.1.247. That is not a footnote to bury; it is the fairest possible framing. No one in this market has earned the right to point and laugh, and the honest reading is that the whole class of tool is early, and that outside testing is finding the same mistake in every one of them.

So the question to put to any vendor, and to your own teams, is not whether the sandbox held this week. It is a sharper one. If the only thing standing between an untrusted repository and your developer's machine is a boundary that an outside researcher escaped from its strictest setting in a routine question, and that you learned about eight days after it was fixed and never through an advisory, what exactly are you trusting when you let the agent run while nobody is watching?