Security researchers discovered two ways to escape the OpenAI Codex sandbox and reach resources on the host computer. OpenAI reportedly fixed both vulnerabilities within eight days, but one flaw enabled command execution from the strictest sandbox mode.
Researchers Discover Two Codex Flaws
Oren Yomtov of Accomplish AI and fellow researchers reported both vulnerabilities to OpenAI on August 12.
The first technique, named Heapjack, affected a component used by Codex Desktop and Codex CLI. According to the researchers, it could execute commands outside the sandbox without requesting approval or displaying visible activity.
The second flaw, called Overpatch, allowed Codex’s patching tool to write beyond the permitted project directory.
OpenAI fixed Heapjack in Codex Desktop build 26.818.21641. Meanwhile, the company addressed Overpatch in Codex CLI version 0.149.0.
Users should install these versions or any later releases.
Heapjack Targets Shared Memory
Heapjack targeted a component called node_repl. Codex Desktop added the component to the global Codex configuration file during installation.
According to the researchers, users did not need to enable the feature manually. Moreover, the global configuration allowed Codex CLI users to inherit the tool.
The component ran a single Node.js process with two JavaScript execution contexts. One trusted context contained OpenAI’s code, while an untrusted context handled the agent’s code.
The trusted context authenticated itself with a random token created during each session. However, both contexts operated inside the same Node.js process and shared the same memory heap.
Consequently, the untrusted context could search the shared memory for the authentication token.
Untrusted Code Finds the Secret Token
The researchers used Node.js functionality to capture a snapshot of the process memory.
The untrusted code then searched for strings matching the expected token format. It submitted potential tokens and observed the responses.
An incorrect token produced an authorisation error. However, the correct token combined with an invalid argument returned a different validation response.
This behavioural difference confirmed when the code had identified the valid token.
The attack could then write its own request to the communication channel used by the trusted context. That channel connected to a native parent process running outside the sandbox.
Because the request included the valid token, the parent process accepted it as trusted.
Heapjack Enables Host Command Execution
The Heapjack proof of concept used the host system’s open command to launch an application.
This application ran outside Codex’s process tree. Therefore, the sandbox could no longer control its activity.
According to the researchers, the same access could reach Unix sockets and other host resources. Potential targets included Docker daemon sockets and tools that modify the global Codex configuration.
The attack reportedly worked in read-only mode, which provides the strictest sandbox restrictions. In this mode, the agent should not write files or execute commands outside its isolated environment.
The Codex sandbox escape therefore undermined the main protection designed to contain untrusted repository content.
Malicious Repository Could Trigger Heapjack
The researchers described a scenario involving a malicious software repository.
A developer could open another person’s repository in Codex and ask the agent a routine question about its code. Hidden instructions inside the repository could then influence the agent.
Those instructions could direct Codex to exploit Heapjack. As a result, the repository’s creator could potentially execute unsandboxed commands on the developer’s computer.
The developer would not need to approve the action. Furthermore, the interface might show no visible warning while the attack ran.
This attack path made the vulnerability particularly serious. Developers commonly use coding agents to inspect unfamiliar repositories, troubleshoot projects and explain source code.
Overpatch Bypasses Workspace Restrictions
The second Codex sandbox escape, named Overpatch, affected the open-source Codex CLI.
In workspace-write mode, Codex can modify files inside the active project directory. However, the sandbox should block attempts to write elsewhere.
For example, a direct shell command targeting the user’s home directory should fail.
The researchers found that Codex’s apply_patch tool could bypass this restriction. The tool calculated its own write permissions from the paths included in a patch.
When a patch referenced a directory, the system granted access to that path’s parent directory. Therefore, a carefully selected path could broaden the permitted area.
Patch Exploit Reaches the Home Directory
The researchers created a patch containing two changes.
The first change referenced a temporary directory. Although it performed no meaningful modification, it expanded the area that the patch tool could access.
The second change targeted a symbolic link leading into the user’s home directory. Through that link, the patch appended a command to the .zshrc configuration file.
Without the first change, the sandbox rejected the write. However, including both changes allowed the operation to succeed.
The malicious line would then run outside the sandbox when the developer opened a new terminal session.
Unlike Heapjack, Overpatch required workspace-write mode. Nevertheless, it still crossed a boundary that should have restricted changes to the project folder.
Both Flaws Share the Same Design Problem
Heapjack and Overpatch affected different components, but the researchers identified a common security mistake.
In both cases, the system trusted information controlled from inside the environment it aimed to restrict.
The patch tool calculated permissions from attacker-controlled paths. Meanwhile, node_repl stored its authentication secret in memory shared with untrusted code.
Therefore, the protected component helped determine whether an action should cross its own security boundary.
A stronger design would enforce the boundary through a separate process or component. Untrusted code should not access the secret or control the data used to calculate permissions.
AI Coding Agents Face Wider Sandbox Risks
The Codex sandbox escape findings reflect a broader challenge affecting AI coding tools.
Coding agents routinely interact with untrusted source files, configuration data and project instructions. At the same time, they need enough system access to run tests and modify code.
Attackers can abuse this combination through malicious repositories. Hidden instructions may convince an agent to create files or trigger trusted tools outside its sandbox.
Researchers demonstrated related techniques against several coding agents in July 2026. Those attacks kept the agent inside its sandbox but created files that trusted external tools later executed.
Therefore, securing the agent alone may not provide enough protection. Developers must also consider how sandboxed actions interact with software running on the host.
Codex Users Should Update Immediately
OpenAI reportedly resolved both vulnerabilities within eight days of receiving the researchers’ report.
Users should update Codex Desktop to build 26.818.21641 or later. They should also install Codex CLI version 0.149.0 or a newer release.
Developers should exercise particular caution when opening unfamiliar repositories with AI coding agents. A project may contain malicious instructions even if its source code appears harmless.
Keeping Codex updated closes the two reported vulnerabilities. However, developers should continue treating untrusted repositories as potentially dangerous content.
0 responses to “Researchers Escape OpenAI Codex Sandbox to Run Host Commands”