OpenAI Codex Sandbox Escapes: Update Desktop and CLI for Heapjack and Overpatch

By AiCybr Editorial · Published September 20, 2026

Security researchers at Accomplish disclosed two sandbox escapes in OpenAI Codex that were reported to OpenAI on August 12, 2026 and fixed within eight days. The flaws, named Heapjack and Overpatch, reached different trust boundaries: Heapjack enabled unsandboxed host actions from the strict read-only mode, while Overpatch allowed Codex CLI's patch path to write outside the workspace in workspace-write mode.

The researchers identify Codex Desktop build 26.818.21641 as the minimum fixed build for Heapjack and Codex CLI 0.149.0 as the minimum fixed release for Overpatch. Users running older builds should update both components where applicable. Current independent reporting from BleepingComputer corroborates the disclosure timeline, affected paths and fixed versions.

Heapjack's demonstrated path crossed the host boundary without an approval prompt. Accomplish demonstrated the issue by opening an untrusted repository in Codex, asking a question about the code and reaching an unsandboxed native parent process through the Desktop-installed node_repl helper.

Fixed versions and exposure at a glance

The version guidance comes from Accomplish's September 15 technical disclosure. The researchers say both issues were reported on August 12 and fixed within eight days. No CVE identifiers are included in the reviewed disclosure, so inventory should use the affected component and fixed-build information instead of waiting for a CVE-based scanner rule.

Heapjack crossed the read-only boundary through a shared V8 heap

Heapjack targeted node_repl, a helper that Codex Desktop placed in the global ~/.codex/config.toml configuration. According to Accomplish, the helper used a native Rust parent process outside the sandbox and a sandboxed Node.js child containing two V8 vm contexts.

One JavaScript context ran trusted code and received a random authorization token. The other ran untrusted agent code. Both contexts occupied the same V8 isolate and shared the same heap.

The researchers used v8.getHeapSnapshot() from the untrusted context to enumerate UUID-shaped strings and identify the authorization token through response differences. With that token, untrusted code could send a request over the same pipe used by the trusted context. The native parent accepted the request as authorized.

Accomplish's proof of concept invoked the system open command, causing an application to launch outside Codex's sandboxed process tree. The researchers also report that the same privileged interface exposed Unix-socket access and global Codex configuration editing. A Docker daemon socket is one example of a high-impact local interface where such access can materially expand the blast radius.

The demonstrated chain worked in read-only mode and produced no approval prompt. BleepingComputer independently corroborated these disclosure details in its September 20 coverage.

Overpatch widened workspace-write permissions through patch input

Overpatch affected the Codex CLI patching path. In workspace-write mode, normal shell commands are constrained from writing outside the project workspace. Accomplish found that apply_patch derived temporary write access from parent directories named by the patch itself.

The proof of concept included a patch entry naming /tmp. Because its parent is /, that input widened the permitted write scope to the filesystem root. A second patch operation then followed a symlink into the user's home directory and appended content to .zshrc.

The injected shell-startup content would execute when the user next opened a terminal, outside the Codex sandbox. Removing the permission-widening patch entry caused the write to be refused in the researchers' test, tying the escape to the patch permission calculation instead of ordinary workspace access.

Why untrusted repositories matter for coding agents

Coding agents routinely inspect repository-controlled files, execute developer tools and invoke privileged helper interfaces. A repository therefore supplies more than source code: it can influence the inputs an agent evaluates and the tool operations the harness attempts.

Heapjack demonstrates the risk when a privileged helper's authorization secret is accessible to untrusted execution in the same process. Overpatch demonstrates a separate failure mode where untrusted tool input participates in calculating the boundary that is supposed to constrain that input.

For teams using coding agents on third-party repositories, forks, pull-request branches or downloaded samples, repository trust should be part of the workstation threat model. Sandboxing reduces exposure only when the enforcement boundary remains outside the reach of the code and tool inputs being constrained.

What Codex users should do

First, update Codex Desktop to build 26.818.21641 or later and Codex CLI to 0.149.0 or later, using a newer approved release when available. Inventory the two separately because Desktop and CLI have different fixed-version identifiers and may coexist on the same developer machine.

Second, restart the relevant application and verify the version actually being launched. Enterprise software inventories should distinguish an installed package from the executable reached through shell paths, desktop launchers or managed application deployment.

Third, treat patching and incident review as separate tasks. Teams that used older affected builds with untrusted repositories should review endpoint telemetry, shell-startup files such as .zshrc, unexpected Codex configuration changes and suspicious child or host processes according to their normal incident-response policy. The public research demonstrates exploitability; it does not establish that a specific workstation was compromised.

For high-risk repository review, disposable VMs or similarly strong host isolation can provide an additional boundary around the entire agent runtime. This is especially relevant for security research, unknown repositories and automated agent workflows that combine repository-controlled content with local credentials or privileged developer tooling.

The broader agent-sandbox lesson

OpenAI's own Codex engineering documentation describes sandboxing as the mechanism that constrains agent file writes and network access while allowing developer workflows to proceed. The two disclosed flaws show why the location of enforcement is as important as the nominal sandbox mode.

Heapjack placed an authorization secret in memory shared with untrusted JavaScript. Overpatch allowed patch-controlled paths to influence the write-permission scope. Both were fixed before public disclosure, according to the researchers.

For agent-platform designers, privileged brokers should authenticate requests using state unavailable to the untrusted execution environment, and filesystem policy should be derived from an external trusted boundary instead of paths supplied by the operation being authorized. Those principles apply beyond Codex to coding agents, MCP-style helpers and other systems that combine untrusted project content with host-side tools.

Bottom line

Accomplish's disclosure documents two distinct, fixed Codex sandbox escapes with practical developer-workstation impact. Heapjack crossed from read-only execution into an unsandboxed native helper, while Overpatch expanded workspace-write beyond the intended project directory.

The immediate response is version-based: run Codex Desktop 26.818.21641 or later and Codex CLI 0.149.0 or later. Teams that processed untrusted repositories on older builds should pair the update with targeted endpoint review and use stronger host isolation for workflows where repository provenance is uncertain.

Sources

• Accomplish — Escaping the OpenAI Codex sandbox, twice
• BleepingComputer — Researchers escape OpenAI Codex sandbox to run commands on host
• OpenAI — Building a safe, effective sandbox to enable Codex on Windows