February 3, 2026
Sandbox or sandtrap?
Show HN: Sandboxing untrusted code using WebAssembly
AI agents in a padded cell—devs cheer, skeptics grill the locks
TLDR: Capsule runs AI tasks in a secure WebAssembly sandbox with strict resource limits, but the community is split: Python’s missing native plugins irk devs, some say “use JS,” others want clearer agent examples and network throttles. It matters because safe, controlled AI code execution is now table stakes.
Capsule wants to put AI agents in a digital panic room, running each task inside a WebAssembly sandbox—think code in a sealed box with strict CPU, memory, and time limits. It even auto-retries and logs every move, returning tidy JSON receipts. Sounds safe, right? The crowd’s split. One camp is hyped: “neat decorator!” The other camp is clutching pearls over Python plugins like pandas being off-limits (those native C bits don’t play nice), with a cheeky chorus asking if we should just make the AI write JavaScript instead. Meanwhile, standards watchers are side-eyeing the future: WASI (a system interface for WebAssembly) is the path to cross-language harmony, but commenters want clarity on WASI 0.3 and component tools like componentize-py and jco WebAssembly WASI. Practical folks demand more examples: should the agent live entirely in the sandbox, or should we pipe AI-generated code into it on the fly? Trust issues flared too—simonw loves the decorator but wants the WASM code in a separate file to see exactly what runs. And the safety posse? They’re asking for network limits to stop agents from turning into data vacuums. The vibe: promising, polished, and just spicy enough to spark a standards-and-safety showdown.
Key Points
- •Capsule runs AI agent tasks in isolated WebAssembly sandboxes with configurable CPU, memory, and timeout limits.
- •Developers define tasks with Python (@task decorator) or TypeScript/JavaScript (task() via @capsule-run/sdk), requiring a "main" entry task.
- •Code is compiled to WebAssembly and executed in dedicated sandboxes; the host enforces CPU via Wasm fuel metering, memory limits, and timeouts.
- •Each task returns a JSON envelope including success, result, error details, and execution metrics (task_name, duration_ms, retries, fuel_consumed).
- •Quick start instructions and documentation (v0.5.1) outline installation, basic examples, and configuration options (name, compute levels, RAM).