A futuristic Codex coding interface shows sandbox folders, protected systems, and red security threats.
OpenAI Codex users should verify both their CLI and desktop installations after researchers disclosed two sandbox escapes that could let untrusted repository content exceed Codex’s promised filesystem and process boundaries. The fixes are already available—Codex CLI version 0.149.0 for the Overpatch flaw and Codex Desktop build 26.818.21641 for Heapjack—but the practical risk is broader than an ordinary command-line update because the desktop application can install a globally configured helper that plain CLI sessions may also use.

Accomplish AI researcher Oren Yomtov disclosed the findings on September 15, and BleepingComputer subsequently reported the details. OpenAI’s public Codex repository independently confirms the CLI-side repair: a change merged on August 20 is explicitly titled “Prevent apply_patch from widening write permissions,” and adds regression coverage for symlink escapes beyond the workspace. That is important corroboration for one half of the report. The full Heapjack desktop helper is not public source code, however, so its reported exploitation path and the stated desktop build threshold remain dependent on Accomplish’s research rather than a fully auditable OpenAI patch.

The immediate operational conclusion is straightforward: a Codex version check alone may not establish that every relevant component is patched. Teams using Codex from Windows Terminal, WSL, macOS terminals, IDE launchers, or the desktop app should inventory each route separately, then restart any long-running agent sessions after updating.

Overpatch let a patch expand its own authority​

Overpatch affected Codex CLI’s apply_patch path while the agent was operating in workspace-write mode. That mode is meant to allow changes in a selected project while preventing writes elsewhere on the machine. According to Accomplish, the patch tool calculated additional permission based on parent paths named in a proposed patch, allowing attacker-controlled patch content to enlarge the permitted area.

The reported proof of concept used a harmless-looking patch entry naming /tmp to cause the tool to treat the filesystem root as writable. A second change then followed a symlink to modify a shell startup file outside the approved repository. The persistence consequence was especially significant: rather than needing an immediate visible shell execution, the altered startup configuration could run an attacker’s command the next time the developer opened a terminal.

OpenAI’s public pull request confirms the underlying condition. Its description says the previous implementation derived permissions from the parent of an already writable patch target, potentially granting write access outside the intended workspace. The repair skips targets already covered by the sandbox policy before calculating extra parent-directory access, and tests workspace-directory targets, already-writable parents, and symlinks leading outside the workspace.

That record establishes more than a vague claim of a “sandbox issue.” It shows that a path supplied in agent-controlled patch data had influenced the code deciding where that same agent could write. In security terms, the authorization boundary was partially computed from untrusted input.

The published exploit chain uses Unix-style paths and .zshrc, so it does not demonstrate an identical native-Windows persistence payload. Windows administrators should not turn a macOS or Linux proof of concept into a claim that PowerShell profiles or registry Run keys were affected in the same way. But the CLI permission bug itself was in shared Codex code, and Windows users running Codex through WSL are directly within the kind of Unix environment used in the report.

Heapjack put the secret inside the sandbox​

Heapjack is the more severe design failure described by Accomplish because the reported chain worked in Codex’s read-only sandbox mode—the mode intended to prevent writes entirely. The researchers said an attacker only needed a victim to open an untrusted repository in Codex and ask a question about its code. No approval prompt was required in the proof of concept.

The issue centers on node_repl, a helper that Codex Desktop reportedly writes into the user’s global Codex configuration. Accomplish says the helper runs a Node.js process containing two V8 vm contexts: one for trusted OpenAI code and another for untrusted agent code. The trusted context receives a fresh authorization token for communicating with a native parent process, while the untrusted context does not.

The flaw, according to the report, was that the two contexts shared a single V8 isolate and memory heap. The secret was therefore not outside the untrusted environment; it was merely stored in another JavaScript context in the same process. Accomplish says untrusted code could inspect the heap, recover the token, and send a forged request over the same standard-output channel used by trusted code to communicate with the native helper.

The claimed end result was host-level command execution outside Codex’s process tree. The demonstration used the macOS open command, with the launched application started by the operating system rather than as a sandboxed Codex child. Accomplish also said the privileged helper could access Unix sockets and modify global Codex configuration.

OpenAI’s public repository contains a related August 18 change that prevents the Node REPL authorization token from being inherited by model-reachable child processes. That is a meaningful hardening measure, but it is not enough by itself to prove how the shared-memory issue was corrected. The public change addresses token inheritance through environment variables; Accomplish’s account describes token recovery from an in-process heap and reuse over a shared protocol channel. Those are different paths.

This distinction matters because the desktop component is closed-source. OpenAI has not, as of September 20, published a public Codex security advisory for Heapjack or Overpatch comparable to its earlier advisories for past sandbox-bypass defects. The stated fixed desktop build is useful for remediation, but administrators cannot independently inspect the full Heapjack remediation from the public repository.

Desktop and CLI installations need separate checks​

The most easily missed detail in the disclosure is that Codex Desktop’s node_repl configuration was reportedly written to the global ~/.codex/config.toml file. If that configuration persists, a developer who normally runs only the CLI can still inherit a desktop-installed helper. Treating the desktop application and the CLI as independent products therefore creates a blind spot.

For managed endpoints, record the executable path and reported version for every normal launch path: a terminal-installed CLI, WSL installation, IDE integration, desktop app, scheduled automation, and CI runner. An update performed under one user account or one package manager does not update another installation automatically.

On Unix-like systems, codex --version identifies the running CLI version, but it should be run from the exact shell environment or automation account that uses Codex. The codex mcp list command can help identify configured MCP servers. On Windows, check both a native installation and any WSL distribution separately; their home directories, package stores, configuration files, and update channels are not the same.

There is also a Windows-specific reason to verify instead of trusting an update prompt. A GitHub issue filed against OpenAI’s Codex repository reported that the Windows in-product updater offered version 0.151.0 but ran a generic npm installation that resolved back to 0.149.0, then declared success. That report is a single user’s account, not evidence that every Windows update failed—and version 0.149.0 is already the published minimum fix for Overpatch. Still, it demonstrates why endpoint inventory should rely on the version actually executed, not an installer’s completion message.

Patch the boundary, then review exposure separately​

Organizations that used versions older than the stated fixes should update first, restart the desktop app and active Codex processes, and then assess prior use involving untrusted repositories. Do not confuse updating with proving that no compromise occurred. The disclosure establishes a route from malicious repository material to actions outside an expected boundary; it does not establish that a particular workstation was exploited.

A focused review should look for activity outside approved workspaces during the affected period: unexpected shell-profile changes, modifications under a user home directory, unfamiliar Codex configuration changes, or application launches with no corresponding approved task. For the Heapjack scenario, a process tree limited to children of Codex may miss relevant activity because the reported technique launches work through an operating-system-level helper.

Keep the response proportionate. The available reporting does not establish mass exploitation, a CVE identifier, or a need to rotate every credential on every device that had Codex installed. It does establish that the product’s internal sandbox controls were bypassable in two distinct ways, including one confirmed by OpenAI’s own CLI patch record.

The practical deadline is not the disclosure date. It is the last time a developer or automated task ran an affected Codex component against code it did not fully trust.