OpenAI Codex Sandbox Flaws Let Malicious Repositories Execute Commands on Host Systems

OpenAI Codex recently faced two significant security vulnerabilities that allowed malicious repositories to potentially execute commands on a developer’s local system.

These vulnerabilities, identified as Overpatch and Heapjack, were reported to OpenAI on August 12, 2026, and were addressed in under a week.

The more critical issue, Heapjack, emerged when a developer accessed an attacker-controlled repository in Codex and queried the agent about its contents.

This flaw could lead to command execution without any approval prompts or warnings, even when Codex was functioning in its strict read-only sandbox mode.

Overpatch was identified within the open-source Codex CLI and its apply_patch editing tool. In an ideal scenario, Codex should restrict modifications to files only within the active project directory.

However, it was discovered that the apply_patch tool granted permissions based on the parent directories specified in a submitted patch. By incorporating a directory named /tmp in a patch, the tool could mistakenly extend write access starting from the root directory, surpassing the intended workspace limitations.

A proof of concept demonstrated this vulnerability by employing a symbolic link to append a malicious command to the user’s .zshrc file located in the home directory.

Although this specific patch attempt involving /tmp failed because it aimed to overwrite a directory, it still inadvertently expanded the tool’s file-write permissions.

As a result, when the user subsequently opened a terminal, the modified shell configuration could execute code controlled by the attacker beyond the Codex sandbox.

OpenAI Codex Sandbox Flaws

This incident emphasizes that security boundaries should not be determined by paths provided by untrusted content. Since an attacker can influence the patch content, there’s a risk that an editing request could grant access to areas outside the project folder, leading to potential exploitation.

Heapjack impacted the node_repl tool installed by Codex Desktop. Upon installation, Codex Desktop wrote a configuration block to the global ~/.codex/config.toml file, enabling the component’s availability for regular Codex CLI sessions.

Detail	Overpatch	Heapjack
Affected component	OpenAI Codex CLI	Codex Desktop node_repl
Sandbox affected	workspace-write	read-only
Core flaw	apply_patch widened permissions using attacker-controlled paths	Authorization token exposed in shared V8 heap
Bypass	Crafted /tmp path enabled writes outside workspace	Heap inspection recovered the trusted token
Impact	Modify host files, including .zshrc, enabling persistence	Execute unsandboxed host commands
Approval required	No	No
Fixed version	Codex CLI 0.149.0+	Desktop 26.818.21641+

The tool functioned with a parent process written in Rust and a sandboxed Node.js process. In this setup, both trusted OpenAI code and agent-controlled untrusted code operated within separate V8 virtual-machine contexts. The trusted context held a random authorization token meant to verify that requests originated from trusted sources.

The vulnerability arose from the fact that both contexts shared the same V8 isolate and memory heap. An untrusted JavaScript entity could take a heap snapshot and search it for UUID-like strings to locate the valid token.

Once identified, it could send forged requests through the shared standard-output channel to the unsandboxed parent process. These forged requests could potentially invoke the system open command, allowing applications to launch outside of Codex’s intended process structure.

Moreover, the compromised authorization mechanism could enable interactions with Unix sockets, including the Docker daemon socket, or modifications to the global Codex configuration file.

OpenAI responded promptly to these vulnerabilities, addressing Overpatch in Codex CLI version 0.149.0 and Heapjack in Codex Desktop build 26.818.21641.

Users are advised to update both the desktop application and command-line client, particularly if they frequently engage with cloned, third-party, or untrusted repositories.

Ultimately, these vulnerabilities serve as a reminder of overarching security concerns related to AI agents: enforcement logic and sensitive information must remain isolated from environments controlled by untrusted code.

Developers should regard a sandbox as a means to alleviate risk rather than as absolute assurance that content from unfamiliar repositories is safe.

It’s crucial to treat untrusted repositories with caution, maintain up-to-date Codex versions, and not rely solely on read-only mode as protection against potential code execution driven by agents.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC