Two sandbox escape techniques have been identified in OpenAI's Codex, a command-line and desktop-based coding agent. One of the flaws enables remote code execution on a developer's system from Codex's most restricted mode, executing without user approval or any visible indication to the user.
Oren Yomtov of Accomplish AI reported both vulnerabilities to OpenAI on August 12, with fixes deployed within eight days. The more critical vulnerability, termed Heapjack by researchers, converts a straightforward interaction into code execution: querying code from another person's repository in Codex grants that repository's author unsandboxed command execution capabilities on the querying developer's machine.
Codex operates as a coding agent available through command-line and desktop interfaces. Like competing agents, it executes model actions within a sandbox to prevent untrusted code from accessing the broader system. Both discovered escapes circumvent this boundary from within.
Heapjack
According to Yomtov's technical analysis, Heapjack exploits a component named node_repl, which Codex Desktop installs into the global ~/.codex/config.toml file during setup. No user consent is required and no configuration option exists to disable it. Since this entry resides in a shared configuration file, even command-line Codex users receive the same tool without being prompted.
The node_repl component operates a single Node.js process containing two separate JavaScript execution contexts. One context is trusted and houses OpenAI's proprietary code, while the other is untrusted and executes the agent's code. The trusted context authenticates itself by presenting a randomly generated token created anew with each execution.
The vulnerability stems from both contexts existing within a single Node process sharing one memory heap. Consequently, the authentication token exists as a simple string in memory accessible to the untrusted side. The untrusted code can capture a heap snapshot using v8.getHeapSnapshot() and iterate through every string matching a UUID pattern. An incorrect guess produces an "not authorized" response, while a correct token paired with an invalid argument returns an actual validation error, confirming token validity to the attacker.
Once the token is obtained, the untrusted code can write its own request to the pipe used by the trusted context to communicate with a native, unsandboxed parent process. The parent validates the token, recognizes it as legitimate, and executes the requested action. The proof-of-concept demonstration used the system's open command to launch an application outside Codex's process hierarchy entirely. This same access extends to any Unix socket, with a Docker daemon socket representing the most obvious target, plus tools for modifying the global configuration file.
All of this occurs within read-only mode, the most restrictive sandbox configuration where the agent should not write anything whatsoever.
Overpatch
The second vulnerability, named Overpatch, exists in the open-source Codex CLI. When operating in workspace-write mode, the agent can only write within the project directory, and shell commands targeting the home directory are blocked.
Researchers leveraged Codex's own patch application tool, apply_patch, to write outside these restrictions. This tool grants write access to the parent directory of each path specified in a patch. Specifying /tmp grants write access to the disk's root.
The working exploit employs a patch containing two modifications: one that references /tmp and performs no useful function except expanding permissions, and another that appends a line to .zshrc via a symlink into the home directory. Removing the first modification causes the write operation to be rejected. When present, the attacker's code runs unsandboxed the next time the developer opens a terminal.
The same underlying mistake
Both vulnerabilities follow an identical pattern: the enforcement mechanism existed within the system it was intended to protect. The apply_patch tool determined its own permissions based on attacker-controlled input. The node_repl component stored the secret distinguishing trusted from untrusted code in the same memory space as the untrusted code itself.
In both instances, the sandbox was instructed from within to permit something through. This category of vulnerability is not unprecedented. In July 2026, Pillar Security researchers demonstrated the same concept across Cursor, Codex, Gemini CLI and Google's Antigravity, where an agent operating within its sandbox writes a file that a trusted tool outside the sandbox subsequently executes.
Responding to Yomtov's post on X, commenters raised additional concerns. One noted that "V8 contexts isolate globals, not memory, so the sandbox was really a promise the heap never agreed to." Another characterized the trust boundary as "a room divider." The default-enabled nature of this functionality drew further criticism, with observers questioning why a privileged token was accessible from untrusted JavaScript in the first place.
What to do
OpenAI addressed Heapjack in Codex Desktop build 26.818.21641 and Overpatch in Codex CLI 0.149.0, according to Accomplish. Users should upgrade to these versions or any subsequent release. Yomtov acknowledged OpenAI's responsiveness in resolving both issues within eight days of the initial report.
BleepingComputer contacted OpenAI for comment prior to publication.