Two ways out of the OpenAI Codex sandbox: Heapjack and Overpatch

On 15 September 2026 Oren Yomtov, a principal security researcher at Accomplish AI, published a technical account of two separate ways out of the sandbox that surrounds OpenAI's Codex coding agent. Both were reported to OpenAI on 12 August 2026 and both were fixed within eight days, according to his write-up: Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0. Heapjack is the more serious of the two. It needs nothing from the person being attacked beyond opening a repository in Codex and asking a question about the code, and it runs at read-only, the strictest mode the product offers, with no approval prompt and nothing displayed on screen. No CVE was assigned to either flaw and no standalone OpenAI advisory was published, according to the Cloud Security Alliance, and nobody has been reported harmed by them. It is catalogued alongside the year's other agent-control entries in the AI incident archive, where each record carries its source documents, confidence grade and disputed flag.

Heapjack: the token sat in a heap the untrusted side could read

Codex Desktop does not ask before it installs the component Yomtov attacked. At install time it writes a node_repl block into the global configuration file at ~/.codex/config.toml, and Yomtov reports that there is no opt-in and no setting that turns it off. Because the entry lives in the shared configuration rather than in a per-user choice, a plain Codex CLI user inherits the same tool without ever being asked.

The node_repl tool is itself a native program that runs outside the sandbox. It can open applications, connect to Unix sockets and edit the global configuration file. What it starts inside the sandbox is a single Node.js process, and that process holds two JavaScript execution contexts: a trusted one containing OpenAI's own code, and an untrusted one running whatever the agent has been asked to do.

The trusted context proves it is trusted by presenting a random token, generated fresh on each run. That is meant to be the boundary between the two contexts. It is not one, because both contexts live in a single V8 isolate sharing a single memory heap, so the token is a string sitting in memory that the untrusted code can read. A commenter reacting to the disclosure on X put the point more bluntly, in a line BleepingComputer quoted: "V8 contexts isolate globals, not memory, so the sandbox was really a promise the heap never agreed to." That is a characterisation, not evidence; the evidence is the proof of concept.

Yomtov's exploit does exactly what that description implies. Untrusted JavaScript calls v8.getHeapSnapshot(), scans the resulting snapshot for strings shaped like a UUID, and tests each candidate. A wrong guess comes back "not authorized". A correct token paired with an invalid argument returns a genuine validation error instead. The difference between the two error messages is the oracle that identifies the right value.

With the token in hand, the sandboxed process writes its own JSON request onto file descriptor 1 — the same stdout pipe the trusted context uses to reach the native parent. The parent validates the token, finds a valid one, and does the work. In the proof of concept that work was the system open command, which hands the request to launchd and launches the application outside Codex's process tree entirely. The same token permits connections to arbitrary Unix sockets, a Docker daemon socket among them, and reaches a tool for editing the global configuration file.

All of it runs at read-only, the mode a cautious user selects precisely because the repository in front of them is not trusted. No approval prompt appeared at any stage. The practical scenario is short: open a cloned repository in Codex, in read-only mode, and ask a question about the code. Whoever wrote that repository gets unsandboxed command execution on the machine, and nothing on screen says so.

Overpatch: a patch tool that granted the parent of everything it touched

The second flaw sits in Codex CLI, the open-source command-line agent, and it is a permissions bug rather than a memory one. In workspace-write mode the agent may write inside the project folder and nowhere else; a shell command aimed at the home directory is refused. The apply_patch tool was supposed to hold that line. Instead it derived its permissions from the paths named in the patch it was applying, and it granted write access to the parent directory of each one.

Name a path under /tmp in a patch and the grant widens to the root of the disk, because the parent of /tmp is /. That is the whole trick.

The working exploit uses two entries in a single patch. The first names /tmp and does nothing useful — it fails, since a file cannot overwrite a directory — and exists only to widen the grant. The second appends a line to .zshrc through a symlink into the home directory. Remove the first entry and the write is refused. Keep it, and the next terminal the developer opens runs the attacker's line unsandboxed, with the sandbox no longer in the loop at all.

That makes Overpatch a persistence bug rather than a one-shot. The poisoned startup file executes again on every shell the developer opens, until somebody reads .zshrc and notices the appended line — which is why the Cloud Security Alliance's guidance is to go looking for one rather than to wait for a symptom.

Both bugs put the enforcement inside the thing being enforced

Yomtov's own framing is the part that travels beyond Codex. apply_patch computed its own permissions from input an attacker supplied. node_repl kept the secret separating trusted from untrusted code in memory that the untrusted code could read. In each case the sandbox was told, from the inside, to let something through.

The shape is not new. BleepingComputer, which reported the disclosure on 20 September 2026, notes that in July 2026 Pillar Security researchers demonstrated the same idea across Cursor, Codex, Gemini CLI and Google's Antigravity, where an agent that stays inside its sandbox writes a file that a trusted tool outside the sandbox later executes. What marks the Codex pair out is the read-only bypass in Heapjack and the absence of any setting to disable the component that carries it.

The fixes, and what OpenAI has and has not said

OpenAI fixed Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0, according to Accomplish. Both landed within eight days of the 12 August report — by 20 August, on a plain reading of that timeline — and Yomtov credited OpenAI with the turnaround.

OpenAI published no standalone security advisory for either flaw, and no CVE identifier was assigned; the Cloud Security Alliance records both absences in a research note dated 22 September 2026. Asked for comment, an OpenAI spokesperson told BleepingComputer: "We thank the researchers for contacting us and sharing their findings. We addressed both issues in August, but we're continually strengthening our sandboxes, with recent updates that tighten controls on where agents can write files and expand testing of those protections across platforms."

That statement confirms the fixes and says nothing about the mechanisms. It does not say whether the August changes removed the design pattern or closed the two specific paths out of it. Nobody outside OpenAI has said so either.

What is established, and what rests on one researcher

The archive files this entry as a research finding, severity high, region global, confidence B — documented, but from a single or secondary source — not disputed, with no real harm recorded. That grade is the right lens for reading the rest of this piece, because the split between what several parties confirm and what only the finder asserts runs through the whole story.

Established, in the sense that more than one party says it:

• The disclosure exists and is dated. Yomtov's write-up was published on 15 September 2026; both flaws were reported to OpenAI on 12 August 2026 and, by his account, fixed within eight days.

• OpenAI confirms it acted in August. Its spokesperson told BleepingComputer that both issues were addressed, which corroborates the report-and-fix timeline independently of the finder, even though the company published no advisory and no technical account of its own.

• The fixed versions are stated consistently. Build 26.818.21641 for Codex Desktop and version 0.149.0 for Codex CLI are given by Accomplish, repeated by BleepingComputer, and carried in a 22 September 2026 advisory from the Uganda National Computer Emergency Response Team and Coordination Center, which rated the pair "Red".

• No CVE, no vendor advisory, and no reported exploitation. The Cloud Security Alliance note of 22 September 2026 records the absence of both a CVE and a standalone OpenAI advisory, and reports no confirmed cases of an organisation finding Overpatch's persistence mechanism in place.

• The archive does not dispute any of it. The record is marked disputed false, and its confidence grade reflects the sourcing pattern rather than any disagreement about the facts.

Not established, or established by nobody but the finder:

• The mechanism detail is Yomtov's. The heap-snapshot oracle, the shared file descriptor, the parent-directory grant — all of it comes from his write-up and his proof of concept. The Cloud Security Alliance, whose note is the most detailed third-party summary in circulation, describes synthesising his account and BleepingComputer's reporting, and does not state that it reproduced either exploit or tested either fix. CERT.UG's advisory compiles the same material.

• The vulnerable version ranges were never published. Only the fix versions are named, so there is no list of which earlier builds carried each flaw.

• Whether a patched install is safe from the class of bug, rather than from these two instances, is unstated. OpenAI's "continually strengthening our sandboxes" is a general commitment, not a claim about a specific mechanism.

• Nobody has been reported exploiting either flaw. That is an absence of reporting, not a finding of absence, and the proof of concept shows the Heapjack path leaves nothing on screen for a user to notice.

What a user can act on

Anyone on a Codex Desktop build older than 26.818.21641, or a Codex CLI version older than 0.149.0, sits on the vulnerable side of the line Accomplish draws, and updating is the only remedy the disclosure offers. Beyond that, the Cloud Security Alliance recommends auditing past Codex Desktop sessions that involved untrusted repositories for launchd or open activity and for Docker socket connections, and reading shell startup files — .zshrc, .bashrc and their equivalents — for commands that were appended rather than written by the user.

The same note advises against treating read-only mode as protection when the repository is untrusted, which is the conclusion Heapjack forces on its own. Its structural recommendations go further: physical process and memory isolation instead of shared secrets and convention, credentials kept outside the agent's reach, and patches that reference paths outside the project treated as suspicious on sight. Those are proposals from a third party. Whether OpenAI has adopted any of them beyond the two version bumps is not public.

Two things are worth keeping apart at the end. One is a pair of bugs in a widely used coding agent, reported on 12 August 2026, fixed inside eight days, and closed in two build numbers. The other is the design question Yomtov names — whether a sandbox can be enforced by the code it is supposed to contain — and that question is not something a version number answers. Neither Accomplish nor OpenAI has said the August changes settle it.