How Codex Built a Node.js Runtime in Just Two Weeks

How long does it take to build a Node.js runtime? The Wasmer team notes that integrating a JavaScript engine, event loop, file, network, and threading support typically requires deep C++ work and can take about a year, but they completed it in two weeks.

“We’re already moving out of the IDE, barely touching code, just guiding it where we want to go.” – Syrus Akbary, CEO of Wasmer

What They Actually Built

The two‑week effort produced Edge.js , an open‑source runtime that is “a Node.js‑compatible JavaScript runtime.” It is not Node.js itself but a separate implementation that mirrors Node’s APIs and can run on V8, JavaScriptCore, or QuickJS.

Edge.js’s purpose is to let existing Node.js applications run unchanged inside a WebAssembly sandbox, eliminating the need for Docker.

For edge‑computing and serverless scenarios, traditional Node.js cannot be safely isolated without containers or hardware virtualization, and existing solutions like Deno or Cloudflare Workers require a new API subset, fragmenting the ecosystem. Edge.js takes the opposite approach: it retains full Node compatibility and isolates only the unsafe parts.

The core design splits the sandbox into two components:

JS engine : exposed via a custom NAPI; the JavaScript layer is already sandboxed, so no extra hardening is needed.

OS calls and native code : file I/O, threading, networking, etc., are isolated using WASIX.

By sandboxing only the dangerous sections, compatibility and speed are preserved. Official data shows compatibility up to Node.js v24 , with 3,592 of 3,626 Node test suite cases passing. In --safe sandbox mode, performance ranges from 70 % to 95 % of native JavaScript speed, incurring only a 5 %–30 % overhead. Edge.js reuses Node’s underlying libraries such as libuv, ada, and llhttp to keep behavior consistent.

What Codex Did

The key question is how the two‑week timeline was achieved. Wasmer says Codex, running on the GPT‑5.5 model, was involved from initial architecture design through final polishing, delivering a 10‑ to 20‑fold speedup.

The most surprising benefit was not code generation but debugging. Runtime bugs often hide deep in the stack. Akbary notes that some bugs were unexpected, yet Codex dove into console logs, traced call stacks, and used low‑level debuggers like LLD to inspect assembly‑level behavior, rapidly identifying root causes and proposing fixes.

“There are subtle pitfalls we didn’t even know about because we’re not C++ experts. Codex uncovered them early.”

This highlights that while the team was technically skilled, they lacked deep C++ and systems expertise. Codex filled that gap, enabling a small company to accomplish work that previously required large‑scale resources.