Urgent.News

What's breaking now, across thousands of outlets.

Tech

Codex Sandbox Escapes Show Why Agent Guardrails Can’t Live Inside the Agent

Two patched OpenAI Codex vulnerabilities, Heapjack and Overpatch, exposed how coding agents can escape sandboxes and reach developer systems without approval prompts.

Codex Sandbox Escapes Show Why Agent Guardrails Can’t Live Inside the Agent

Most developers view a cloned repository as an object to examine, while a coding agent perceives it as a task to execute. This disparity is where two recently disclosed vulnerabilities in OpenAI’s Codex operated. Oren Yomtov of Accomplish AI discovered two escape routes from the Codex sandbox, naming them Heapjack and Overpatch.

Both allowed code to run on the host machine without requiring an approval prompt or displaying anything on the screen. Yomtov reported these issues to OpenAI on August 12, and OpenAI resolved them within eight days. Accomplish disclosed the details on September 15. The bugs have since been patched. However, the underlying pattern serves as a cautionary tale for DevOps teams.

A developer's laptop frequently contains sensitive information such as SSH keys, cloud credentials, and paths to production pipelines. Escaped code from the sandbox could potentially reach these sensitive areas. The first vulnerability, Heapjack, involves Codex Desktop automatically installing a helper called node_repl without user consent.

This helper operates a JavaScript process in two contexts: one trusted with a secret token, and the other running code from the agent. Both share a single memory space. When untrusted code calls v8.getHeapSnapshot() and searches the results for a string resembling the token, it can extract the token and issue forged requests through a shared pipe.

The parent process then executes the requested commands outside the sandbox. This exploit can be triggered simply by opening a cloned repository in read-only mode and asking Codex a question. Overpatch resides in the open-source Codex CLI. Its apply_patch tool analyzes the parent directory of each path listed in a patch to determine what changes the patch might make.

By naming /tmp, an attacker could gain root-level access on the disk. Yomtov crafted a patch with entries that wrote to a .zshrc file via a symlink in the home directory and named /tmp. The second entry failed, but the expanded permissions remained. The next time a shell started, the modified .zshrc file executed code outside the sandbox.

This effect persists because the file runs automatically with every shell opening. This attack also works in workspace-write mode, again without an approval prompt. OpenAI patched these vulnerabilities in Codex CLI 0.149.0 and Codex Desktop build 26.818.21641. Yomtov summarized the root cause as the enforcement mechanism residing within the entity being controlled.

In Overpatch, the patch tool itself determined its permissions, while Heapjack relied on a trust token that untrusted code could access. This scenario is not unique. In July, Pillar Security's Eilon Cohen, Dan Lisichkin, and Ariel Fogel reported sandbox escapes affecting Cursor, Codex, Gemini CLI, and Google Antigravity. The mechanisms differed, but the agent remained within its sandbox while crafting files that trusted tools later processed.

These incidents underscore the importance of enforcing rules outside the agent's reach. Mitch Ashley, vice president and practice lead for CIO & technology buyers and software lifecycle engineering at The Futurum Group, emphasizes that a sandbox the agent can modify provides no protection. Enforcement must occur in a layer inaccessible to the agent, meaning the control plane.

CI teams recognized this principle years ago when they ceased allowing jobs to grant themselves permissions. To mitigate these risks, teams should update their systems, verify Codex's operation on all devices, including laptops, desktop apps, and command-line interfaces, as well as continuous integration runners. The desktop application and CLI have distinct version numbers, so checking one does not guarantee coverage for the other.

Codex should be treated as untrusted input, even when the agent operates in read-only mode. Disregarding approval prompts is insufficient, as they offer no protection. Isolation is crucial, with the agent confined to a virtual machine or container, with real credentials securely stored on the host machine and network traffic routed through a proxy inaccessible to the agent.

However, even these measures are not foolproof. Ashley advises buyers to inquire about the enforcement boundary and the frequency of patches from vendors. With coding agents now possessing the privileges typically granted to CI jobs, plus enhanced autonomy, it is imperative to understand where the enforcement boundary resides and how swiftly vendors can address vulnerabilities.

Sandboxing bugs will persist, but the critical question remains: who should enforce the rules and where should that enforcement take place? If the answer is "inside the agent," further Heapjack-like incidents are inevitable.

Written by urgent.news from DevOps.com's reporting — not their text. Machine-written — may contain errors; check the original before relying on it.

Read the original at devops.com →

More in Tech

I stopped rewriting the same Electron boilerplate — so I packaged it

Every Electron side project starts with the same three weeks. You wire up window controls, and they look wrong next to the OS chrome. You build a theme system and half your components don't follow it.

  • Author packages Electron boilerplate into reusable framework called electron-shell-framework
  • Framework provides top bar, left sidebar, right panel, and bottom terminal strip
  • Includes dark/light themes, encrypted settings, and robust security measures

Always reach for the asymptotically-optimal data structure — challenged

Everyone reaches for the hash map. O(1) lookup — can't beat that, right? Wrong. For most production lookups, a flat array with a linear scan is faster. I've seen this matter in real systems.

  • Hash maps are commonly chosen for data structures due to their O(1) lookup time.
  • Linear scan through a flat array can outperform hash maps in real-world scenarios.
  • Profiling and understanding data size is crucial for optimal data structure choice.

More from Monday 21 September →