OpenAI Codex Sandbox Flaws Turn Repository Analysis Into Host-Level Command Execution

Two vulnerabilities in OpenAI Codex allowed agent-controlled operations to escape their intended security boundaries and affect a developer’s host system. One worked even under the strictest read-only policy, while the other bypassed workspace-only write restrictions.

Researchers named the flaws Heapjack and Overpatch. Heapjack affects Codex Desktop and can lead to unsandboxed command execution without an approval prompt or visible warning. Overpatch affects the open-source Codex CLI and can modify files outside the permitted project directory, including the user’s .zshrc.

Both vulnerabilities were reported to OpenAI on August 12, 2026. OpenAI addressed them within eight days, releasing Codex Desktop build 26.818.21641 for Heapjack and Codex CLI 0.149.0 for Overpatch.

No CVE identifiers or formal CVSS scores have been disclosed. There is also no reported evidence that either vulnerability was exploited in the wild.

Heapjack Breaks the Read-Only Security Boundary

Heapjack is the more serious of the two findings because it can cross from sandboxed code analysis into host-level activity. A developer could trigger the attack by opening another person’s repository in Codex and asking the agent a question about its contents.

The exploit remains effective when Codex is configured in read-only mode. Under that policy, users would normally expect the agent to inspect files without changing the system or executing unsandboxed host operations.

Instead, Heapjack targets the node_repl component installed by Codex Desktop. During installation, Codex Desktop adds this component to the global configuration file at:

~/.codex/config.toml

The component is enabled by default. It does not require a separate opt-in, and no dedicated option for disabling it has been disclosed. Because the configuration is global, Codex CLI users can also inherit the tool without receiving another authorization request.

This means the vulnerable capability is not confined to a single repository or one explicitly approved session. It becomes part of the user’s shared Codex environment.

A Secret Token Stored Beside Untrusted JavaScript

The vulnerable node_repl design uses one Node.js process containing two separate JavaScript contexts. One is trusted and runs OpenAI code. The other is untrusted and executes code controlled by the agent.

The trusted context communicates with a native parent process running outside the sandbox. It authenticates each request using a randomly generated token created for that run.

Separating the JavaScript contexts does not, however, separate their underlying memory. Both contexts use the same Node.js heap, leaving the authentication token within reach of code running in the untrusted context.

The Heapjack proof of concept calls:

v8.getHeapSnapshot()

It then examines the resulting V8 heap snapshot for strings matching the expected UUID-like structure of the token. Finding candidate values is only the first step. The exploit also needs to determine which candidate is valid.

Researchers accomplished that by observing how the parent process responded to different requests. An incorrect token caused an authorization failure. A correct token submitted with an invalid argument produced a different validation error. That distinction acted as an authentication oracle, confirming when the genuine token had been recovered.

The untrusted context could then write a forged request into the same communication pipe used by the trusted component. Because the message contained the valid token, the unsandboxed parent accepted it and performed the requested operation.

In the demonstrated attack, the parent invoked the system open command to launch an application outside the Codex process tree. The operation generated no approval prompt and no visible on-screen indication inside Codex.

The reported technical findings also identified Unix sockets as a potentially valuable target. A reachable Docker daemon socket could be particularly consequential because it may expose capabilities well beyond ordinary repository analysis. The researchers also found access to a tool able to edit the global Codex configuration.

Overpatch Expands Write Access Beyond the Workspace

Overpatch attacks a different control in the open-source Codex CLI. It affects workspace-write mode, which is intended to let the agent modify project files while preventing writes elsewhere.

Direct shell attempts to write into the developer’s home directory are rejected under this policy. The bypass instead uses Codex’s own apply_patch tool.

The problem lies in how apply_patch determines its authorized write scope. The tool calculates permissions from the parent directories of paths included in a patch. Those paths can be supplied through agent-controlled patch content.

The working exploit includes two changes. The first references /tmp, not because the attacker necessarily needs to alter a file there, but because that path causes the tool to broaden its permission scope to the filesystem root.

The second change follows a symlink and appends an attacker-controlled command to the developer’s .zshrc file. With the /tmp entry present, the external write succeeds. Removing that entry causes the same operation to be denied.

The injected command does not execute immediately. It runs outside the Codex sandbox when the developer later opens a terminal that processes .zshrc.

Overpatch therefore creates a delayed execution and persistence path. The agent appears to be working inside the project, but its patch operation changes shell startup behavior in the user’s home directory.

Both Flaws Put Enforcement in the Wrong Place

Heapjack and Overpatch use different techniques, but their underlying design failure is similar: the restricted component is allowed to participate in enforcing its own restrictions.

In Heapjack, a privileged authentication secret is stored in memory shared with hostile JavaScript. The security model trusts a token that the untrusted execution environment can recover and replay.

In Overpatch, the patching component derives its authority from paths provided by the agent it is supposed to constrain. A hostile patch can therefore influence the calculation used to determine where writing is allowed.

These are confused-trust problems rather than ordinary parsing bugs. The agent does not need to break a kernel sandbox directly if it can persuade a trusted external mechanism to perform the sensitive action.

Comparable agent trust-boundary failures involving Cursor, Codex, Gemini CLI, and Google’s Antigravity were reported in July 2026. In those cases, an agent could remain technically inside its sandbox while arranging for a more trusted tool to execute a file the agent had created.

The recurring lesson is narrow: sandboxing the agent process is insufficient when helper tools, shared memory, configuration handlers, or external executors accept agent-influenced inputs.

Developers Should Patch Both Codex Products

Users should install Codex Desktop build 26.818.21641 or later to address Heapjack. They should separately upgrade Codex CLI to version 0.149.0 or later to fix Overpatch.

Applying only one update is insufficient because the vulnerabilities affect different components and security modes.

Until updates are deployed, developers should avoid opening repositories from untrusted authors in Codex. Read-only analysis should not be treated as a complete defense against repository-supplied instructions or agent-controlled execution.

Defenders and affected users can also review:

• ~/.codex/config.toml for unexpected node_repl configuration or other unauthorized changes.
• .zshrc and other shell startup files for unfamiliar appended commands.
• Codex-related invocations of the system open command.
• Unexpected access to Unix sockets, especially Docker daemon sockets.
• Patch activity involving /tmp, filesystem-root scope, or symlinks leading outside a project.
• Applications launched outside the expected Codex process tree.

Heapjack may leave fewer obvious traces because it does not require a normal file write and can execute without a visible prompt. Process telemetry, socket-access logs, and command-execution records may therefore be more useful than checking the repository alone.

Overpatch is more likely to leave a persistent artifact in .zshrc, but the malicious command may not run until the next terminal session.

Exploitation Has Not Been Reported

No evidence currently indicates that attackers used Heapjack or Overpatch against Codex users before the fixes became available. Their absence from reported attacks does not reduce the exposure created by opening an attacker-controlled repository.

No CVE identifiers, CVSS scores, affected-version ranges, or CISA Known Exploited Vulnerabilities catalog entries have been reported. The precise vulnerable builds preceding the fixed releases are also not known.

The actionable boundary is therefore the patched version: Codex Desktop build 26.818.21641 and Codex CLI 0.149.0. Any installation below those respective releases should be upgraded rather than relying on read-only or workspace-write mode for protection.