Untrusted Code Execution
Safely run LLM-generated or user-submitted code — per-snippet isolation, resource caps, and timeouts.
Safely execute untrusted or LLM-generated Python snippets — each one gets its own throwaway, resource-capped sandbox with a wall-clock timeout, and failures are captured as data instead of crashing the batch.
Setup
Start OpenSandbox in Docker (one-time setup):
bunx alineo-cli initRun it
What it does
Runs three Python snippets in parallel, each in its own sandbox:
well-behaved — a snippet that just prints a value.
raises — a snippet that raises an uncaught exception.
infinite-loop — a snippet that never terminates on its own.
Each sandbox is created with tight resources (250m CPU / 128Mi memory), a 30s container
timeout, and a 5s timeoutMs on the exec call itself. strict: false means a non-zero exit is
returned as data (exitCode, stdout, stderr) instead of throwing, so one bad snippet doesn't
abort the batch. Every sandbox is closed in finally, even on timeout or crash.
Reach for this pattern when...
You're executing code you didn't write yourself — an LLM's generated code, a user-submitted
script, a plugin. Swap runUntrusted()'s body for execCode()/createCodeContext() (see Code
Interpreter) if you want a stateful REPL instead of one-shot scripts.
Server proxy
All examples default to useServerProxy: true — traffic routes through the OpenSandbox server so
Docker bridge IPs don't need to be reachable directly. Set USE_SERVER_PROXY=false to disable
(e.g. when using uvx opensandbox-server on the host).