Agent OS Exec vs QuickJS

How Agent OS Exec and QuickJS differ in isolation model, performance, language coverage, and system surface.

Agent OS Exec and QuickJS both run guest JavaScript, but they sit at different layers. QuickJS is a small, embeddable JavaScript engine: you link it into a host process and call its C API. Agent OS Exec is a full virtualized runtime built on V8, with a kernel, virtual filesystem, and capability policy around the engine. This page focuses on the security and performance characteristics of the core runtime layer.

At a glance

Isolation model

This is the most important difference.

• QuickJS is an interpreter you embed directly in your host process. Guest code shares the host’s address space, and anything the guest can reach is whatever your C bindings expose. There is no process boundary between guest and host by default, so isolation is entirely your responsibility to build and audit.
• Agent OS Exec runs guest code in a V8 isolate behind a virtualized POSIX kernel in the AgentOS sidecar. Guest code never calls real Node.js builtins, never opens a real host socket, and never touches the real disk. Every syscall is routed through the kernel and checked against the VM’s configured permission policy.

The practical consequence: with QuickJS you own the entire VM, including the boundary, the permission checks, and the host-bindings audit surface. With Agent OS Exec the boundary, the kernel, and the policy enforcement are provided and run out-of-process.

Performance

The engines optimize for different things.

• V8 (Agent OS Exec) JIT-compiles hot code to native machine code, so sustained throughput on compute-heavy guest code is far higher. The trade-off is a larger engine and a heavier per-isolate baseline.
• QuickJS compiles to bytecode and interprets it. It has a very small footprint and fast startup for a single embedded instance, but interpreted execution is slower on throughput-bound work.

For Agent OS Exec, cold start includes VM creation and the first language process. Reusing a JavaScriptRuntime keeps the VM, filesystem, and mounts alive, while each execute() call starts a fresh guest process.

Language and ecosystem coverage

• Agent OS Exec runs full modern ECMAScript on V8, the same engine as Node.js and Chrome, so language features land as V8 ships them. Real npm packages run unmodified inside the VM, resolved over a faithfully mounted node_modules like a real filesystem, and Node-compatible builtins are wired through the kernel.
• QuickJS implements most of the ECMAScript specification in a compact engine, but it tracks the spec on its own cadence and lags V8 on newer features and edge cases. It ships no Node.js standard library and no npm resolution; any package or builtin support is something you bind in yourself.

System surface

• Agent OS Exec presents a virtualized POSIX environment to guest code: a per-runtime virtual filesystem, a kernel-managed process table (with node:child_process), a socket table for networking, pipes, and PTYs. Guest fetch(), node:http, and raw sockets all flow through the kernel and the permission policy.
• QuickJS has none of this built in. The bare engine exposes only ECMAScript globals; there is no filesystem, no process model, no networking, and no shell unless your host code adds C bindings for them. Every capability the guest needs is host surface you write and must secure.

When to choose which

Choose QuickJS when you need the smallest possible embeddable engine, you are running short, self-contained scripts with no system needs, and you are prepared to build and audit any VM boundary and host bindings yourself.

Choose Agent OS Exec when you need full ECMAScript and npm compatibility, JIT throughput, and a ready-made isolation boundary with a kernel-backed filesystem, process model, networking, and an explicit capability policy you control.