Codex Read a Repository and Ran Its Owner's Code

Source code open in an editor on a computer screen, lit in warm orange Photo by Daniil Komov on Pexels

AI & ML · 22 Sep 2026 —

22 SEP 2026 — A researcher at Accomplish AI found two ways out of the sandbox OpenAI Codex uses to contain the code it runs. The more serious one works from read-only mode, the setting meant to be the safest. In that mode the agent is supposed to look and not touch.

Both were reported on 12 August and fixed within eight days. Neither has been reported used against anyone.

What Heapjack actually does

Codex Desktop ships a JavaScript evaluation tool called node_repl, which runs inside the sandbox. Inside that tool, trusted and untrusted JavaScript share a single V8 heap.

Sharing a heap means sharing whatever is sitting in it. The research write-up describes calling v8.getHeapSnapshot() to dump that memory, then trying every string in it shaped like a UUID. One of those strings is the token that proves the trusted context is trusted. Holding it, an attacker can forge requests the unsandboxed parent process accepts.

The delivery method is the striking part. Open somebody else's repository in Codex and ask a question about it. That is the entire attack. Whoever wrote that repository gets command execution on the machine, outside the sandbox, with no approval prompt, from the mode that grants the agent no write access at all.

The second escape and its symlink

Overpatch is quieter, and needs the agent to be in workspace-write mode rather than read-only. It abuses apply_patch, the tool Codex CLI uses to edit files.

apply_patch grants write access to the parent folder of every path named in a patch, and does not first check those paths against the workspace boundary. Name /tmp in a patch entry and the parent folder is /, the root of the disk.

The working exploit is a patch with two entries. One appends a line to .zshrc through a symlink pointing into the home directory. The other names /tmp, and that is what widens permission far enough for the first entry to land. Removing the /tmp entry causes the attack to fail, which is how the researcher confirmed it was the source of the widened permission.

The appended line runs the next time a terminal opens, outside the sandbox.

8 daysFrom report on 12 August to fix

Read-onlyThe mode Heapjack escapes from

0.149.0Codex CLI version that closes Overpatch

26.818.21641Codex Desktop build that closes Heapjack

What OpenAI changed

Heapjack is fixed in Codex Desktop build 26.818.21641. Overpatch is fixed in Codex CLI 0.149.0. Earlier releases on either track are affected.

OpenAI told BleepingComputer that it had "addressed both issues in August" and has since shipped "recent updates that tighten controls on where agents can write files and expand testing of those protections across platforms".

Why this keeps happening

Neither flaw is really about breaking the sandbox. Each works by writing something that a trusted process outside the sandbox later picks up.

Pillar Security made that argument in July, after finding escapes in Cursor, Codex, Gemini CLI and Google's Antigravity inside a single week. Its write-up states the shape directly. "In almost every case, the agent did not need to break the sandbox directly. It only had to write something that a trusted component outside the sandbox would later run."

The same post offers the sentence that generalises it. "An agent's blast radius is not the agent process; it includes everything the agent can write that the host later trusts."

Those were different bugs, and the distinction matters. Pillar's Codex findings were a Docker socket route and a git allowlist bypass patched back in version 0.95.0, not Heapjack or Overpatch. Across four products and two months, the pattern repeats even though the defects differ.

What is not known

OpenAI has not published a security advisory mapping either name to a version range. The public changelog is not much help either. Its visible history now begins at Codex CLI 0.154.0, released on 9 September, so whatever was written against 0.149.0 is no longer on the page.

For now, a developer can only check an installed version against a build string quoted in a research post, not a vendor advisory. For anyone who opens unfamiliar repositories in Codex Desktop, that check is the only remediation available.

Sources & cross-checks

Primary: Accomplish AI, 15 September 2026 — for both techniques and their names; the shared V8 heap between trusted and untrusted contexts in node_repl; the v8.getHeapSnapshot() call and the search for UUID-shaped strings; the forged requests to the unsandboxed parent; the read-only delivery by opening a malicious repository; the apply_patch grant of write access to each named path's parent folder; the /tmp entry widening permission to the disk root; the two-entry patch and the symlink append to .zshrc; the finding that removing the /tmp entry makes the attack fail; the 12 August report date, the eight-day fix, and the fixed versions 26.818.21641 and 0.149.0.
Also reported: BleepingComputer, 20 September 2026, independently for the disclosure timeline and the fixed version numbers, and for OpenAI's statement, which is quoted here from that report rather than from any OpenAI advisory. Pillar Security, 20 July 2026, for the cross-product pattern and both quoted sentences, and for its own Codex findings — a Docker socket route and a git allowlist bypass patched in 0.95.0.
Verified: ⚠ Pillar's findings are not these findings. That post predates this disclosure by two months and concerns different vulnerabilities in Codex. It is cited as independent evidence that the write-then-execute pattern recurs across agents, never as corroboration of Heapjack or Overpatch. ⚠ We could not confirm the Codex CLI changelog entries for 0.149.0. The vendor changelog we checked lists nothing earlier than 0.154.0 of 9 September, so no changelog text is quoted here. ⚠ No exploitation has been reported by any source we read, which is not the same as none having occurred. ⚠ The minimum affected versions, and any variation between operating systems, are not established by the sources above.

Tags: #Developer-Tools #AI-Security #Vulnerability-Disclosure

Maya Lin

Digital Platforms Analyst

Maya Lin covers SaaS platforms, workflow automation, creator tools, and productivity software for RECATOOLS.

View author profile → · Editorial policy

About this byline Maya Lin is a RECATOOLS editorial persona used for platform and productivity coverage. Articles are produced and reviewed under RECATOOLS editorial supervision.

Corrections policy