Skip to content
Sign in
Artwork for The Node (and more) Banter
The Node (and more) Banter · Yesterday · 31 min

The Sandbox Was Fine. JavaScript Wasn't

On September 15, Accomplish AI revealed Heapjack, a method that lets someone run any command from OpenAI Codex Desktop, even in its strictest read-only mode, without asking for approval. If you clone a repo and ask a question, the repo’s author could take control of your machine. The issue was reported on August 12 and fixed in eight days. The headline claims the sandbox was escaped, but Matteo and Luca, looking at it from a Node.js perspective, see a different story. The macOS sandbox actually worked. The real problem was with the JavaScript inside: OpenAI ran both its trusted code and the agent’s untrusted code in the same Node process, separated only by a vm context and a secret token. The untrusted code took a heap snapshot, found the token, and sent fake commands through the same channel as the trusted code. A context is not a sandbox. The Node documentation has made this clear, in bold, since 2017. This discussion is about why teams keep making this mistake and what a better design would look like. Matteo and Luca talk about: ✅ What the vm module is really meant for, and why new teams often confuse "context" with "sandbox" every few years ✅ The appealing but incorrect idea that V8’s sandbox could have stopped this, and what Node’s actual position is on the matter ✅ Why a token that lives next to the code it is meant to keep out is not a secret ✅ What OpenAI seems to have changed, and why people outside the company cannot confirm it ✅ Platformatic’s new secure-eval-worker shows what it looks like to run untrusted JavaScript inside Node when you take the warnings seriously. The most honest part is the README, which clearly explains where the security boundary stops. There is a lesson from nine years ago: the system that decides what is allowed should not run inside the thing it is supposed to control. Homework: Before you release an agent, read the second sentence of the vm documentation.

0:00-31:02
Play in

transcript

No transcript — this publisher did not publish one.

show notes

On September 15, Accomplish AI revealed Heapjack, a method that lets someone run any command from OpenAI Codex Desktop, even in its strictest read-only mode, without asking for approval. If you clone a repo and ask a question, the repo’s author could take control of your machine. The issue was reported on August 12 and fixed in eight days.


The headline claims the sandbox was escaped, but Matteo and Luca, looking at it from a Node.js perspective, see a different story. The macOS sandbox actually worked. The real problem was with the JavaScript inside: OpenAI ran both its trusted code and the agent’s untrusted code in the same Node process, separated only by a vm context and a secret token. The untrusted code took a heap snapshot, found the token, and sent fake commands through the same channel as the trusted code. A context is not a sandbox. The Node documentation has made this clear, in bold, since 2017.


This discussion is about why teams keep making this mistake and what a better design would look like. Matteo and Luca talk about:

✅ What the vm module is really meant for, and why new teams often confuse "context" with "sandbox" every few years

✅ The appealing but incorrect idea that V8’s sandbox could have stopped this, and what Node’s actual position is on the matter

✅ Why a token that lives next to the code it is meant to keep out is not a secret

✅ What OpenAI seems to have changed, and why people outside the company cannot confirm it

✅ Platformatic’s new secure-eval-worker shows what it looks like to run untrusted JavaScript inside Node when you take the warnings seriously. The most honest part is the README, which clearly explains where the security boundary stops.


There is a lesson from nine years ago: the system that decides what is allowed should not run inside the thing it is supposed to control.

Homework: Before you release an agent, read the second sentence of the vm documentation.

more episodes

All episodes