QuickJS Sandbox

Run code you did not write without pretending the host process is a sandbox.

QuickJS Sandbox gives TypeScript applications a controlled QuickJS WebAssembly guest runtime for user-provided, plugin, or AI-generated JavaScript and TypeScript, with explicit host capabilities and structured results.

sebastianwessel.github.io Demo Repository

Enterprise pressure

Why it matters

Enterprise products increasingly need to execute code they did not write: AI-generated scripts, workflow rules, customer formulas, plugin logic, data transforms, and playground examples. `eval`, `new Function`, and casual VM wrappers are not enough as a product boundary.

Product answer

What changes

QuickJS Sandbox makes the guest runtime explicit. Code runs inside QuickJS compiled to WebAssembly. The host decides which capabilities exist through `env`, optional `fetch`, optional virtual filesystem access, mounted modules, execution timeout, stack limits, and memory limits.

Operating model

How the model holds

The enterprise app wraps QuickJS WASM in outer controls, exposes only selected capabilities through env, fetch, filesystem, and module gates, and receives structured success or error results from guest code.

isolation boundary QuickJS Sandbox

QuickJS WASM executionTimeout + memoryLimit + env

capability gates

env allowFetch allowFs mountFs nodeModules result

Decision path

QuickJS Sandbox is for product teams that want extensibility without surrendering the host process.

AI transformation makes this problem visible fast. The enterprise wants generated scripts, customer formulas, workflow rules, data transformations, playgrounds, and plugin logic. Security, legal, and operations want to know what that code can access, how long it runs, how much memory it can use, and how the result is captured.

The package gives the application a controlled QuickJS WebAssembly guest runtime. Capabilities such as environment values, fetch, filesystem access, mounted modules, timeout, stack limits, and memory limits are explicit product decisions.

It should still sit inside defense-in-depth: workers or processes, containers where needed, egress policy, logging, validation, and monitoring. The point is to make the application-level execution boundary visible, reviewable, and repeatable.

Enterprise relation

Where this connects to enterprise pressure.

Security teams can review the execution boundary because host capabilities are configured instead of accidental.

AI-generated or customer-provided scripts can be paired with timeout, memory, stack, timer, and host API controls.

Data handling is explicit through env, fetch adapters, virtual filesystem options, and mounted module decisions.

Auditability improves when script execution returns structured results and sits inside outer logging, worker, process, or container controls.

Capabilities

QuickJS Sandbox turns pressure into an operating model.

QuickJS runtime compiled to WebAssembly

JavaScript and TypeScript execution from a TypeScript host package

Explicit host capability gates through env, fetch adapters, filesystem options, and mounted modules

Execution controls such as executionTimeout, maxStackSize, memoryLimit, maxTimeoutCount, and maxIntervalCount

Browser and server-side usage with worker/pool integration patterns

Enterprise use cases

Where decision makers should care.

Running AI-generated scripts before trusting their output inside enterprise workflows

Building customer or plugin extension points with reviewable host capabilities

Powering playgrounds, REPLs, and documentation examples

Executing low-code business rules while pairing the runtime with outer platform controls

Links

Website sebastianwessel.github.io Demo Demo Repository Repository