Both tools execute inside a sandbox — the JavaScript side under permissions you grant explicitly, the Python side in WebAssembly — so the blast radius is whatever you opened, not your shell. Install-on-demand is what makes it useful for verification rather than just execution: an agent can pull an unfamiliar package and find out whether it does what its docs claim.
A server with two execution tools — one runs JavaScript or TypeScript, the other runs Python — each inside its own sandbox, and each able to pull in packages by name at the moment they are imported.
- JavaScript and TypeScript executed in a permissioned runtime, with network access closed until you grant it
- Python executed inside a WebAssembly environment rather than against a system interpreter
- Packages imported by name and fetched on demand from npm, JSR or PyPI — nothing installed on your machine first
- A mapping option for Python packages whose import name differs from the name they are published under
- An explicitly configured window onto one host directory, for code that has to touch real files
- Either language switched off, so you can expose only the runtime you want an agent to have
- A quiet mode that keeps package-install chatter out of the tool output
A JavaScript runtime on the machine. The documented setups either call a sandboxing runtime directly or have the Node package manager fetch it on demand, so there is nothing to install ahead of time. Filesystem access is closed until you name a host directory, and outbound network access on the JavaScript side is closed until you grant that permission.
One command — deno add jsr:@mcpc/code-runner-mcp