Node.js is now fully supported, Python is in preview and Rust is coming soon.
For a glimpse of the possibilities, check our Claude Code running fully in the browser: https://browsercode.io/claude
binyu 19 hours ago [-]
Been working on something similar based on Webcontainers. How does your Node.js support compare with StackBlitz technology?
Are you running the version of Claude code that Anthropic distributes in the browser or did you have to adapt it to run on your stack?
Cheers
apignotti 15 hours ago [-]
Our technology is much more general that WebContainers, and it's based on a Linux-compatible WebAssembly kernel. It also supports real command line tools, including git, bash and the complete set of busybox utilities.
The version of Claude Code you see running is completely unmodified.
binyu 7 hours ago [-]
Awesome, what approach are you using? Is this a real micro kernel architecture or just containerized VM?
apignotti 6 hours ago [-]
The architecture is a fairly straightforward WebAssembly-native monolithic kernel. Most of the complexities come from making things work well within the browser constraints for real world, large apps.
We have quite a bit of experience on the topic however, these are previous projects of ours:
WebVM (https://webvm.io): x86 Debian shell running client-side in the browser via x86 -> WebAssembly JIT compilation
Oh, you are the author of WebVM, pretty cool! I looked at it while choosing the stack for our project and it seems very solid.
Keep up the great work
apignotti 5 hours ago [-]
As a matter of fact WebVM and BrowserPod share the same kernel, the difference is all on the performance side.
WebVM uses x86 virtualization and hence has a significant performance penalty, with the upside of running any existing software without needing the source code.
BrowserPod on the other hand runs WebAssembly binaries at almost native speed. Source code is required, but that is a fair compromise in the world of sandboxing. Most language runtimes and CLI tools are FOSS anyway, and many closed-source tools (such as Claude Code) are written in scripting languages and run on top of FOSS engines.
incognito124 1 days ago [-]
If you're interested in not reinventing the sandbox for LLMs, consider Judge0: https://judge0.com/
I have absolutely no relation to the project except for the fact that I went to the same Uni as the creator.
simonw 1 days ago [-]
That one looks pretty good - it's been around since 2016, I'm surprise I haven't encountered it before.
It's not quite right for what I'm after because you can't just "pip install" it on multiple platforms.
dizhn 10 hours ago [-]
Do you know if it has any kind of orchestration/queue support or if there's another project that does it embedding Judge0?
incognito124 9 hours ago [-]
No idea, I expect that it does since it's very performant. I would totally reach out to the support
era86 1 days ago [-]
I'm using judge0 for a Leetcode-clone I'm working on. Never thought of using it in the context of LLMs, though.
christoff12 1 days ago [-]
This looks like something I can use for a project I'm working on. Thanks
nicolix 21 hours ago [-]
On linux I devised this strategy for letting llm webuis or coding agent to securely run programs by burying their environment under multiple layers of locally arranged sandboxing.
Basically: run as another user -> run inside firejail sandbox -> run inside a stripped down alpine linux vm with smolvm.
P.S. directories can be easily shared between the sandboxed guest and the host os
P.P.S. to stay a bit more on the safe side I also changed the name of the package manager for the guest os to something else so that when a coding agent would try to autonomously install external packages it will fail. I've then instructed it to (politely) ask for whatever it needs to be eventually manually installed by me
yaodub 19 hours ago [-]
Interesting middle ground between full WASM lockdown and a bare environment. Did you end up needing to block anything else beyond the package manager?
dvt 1 days ago [-]
Literally working on a product that does this, hah :) I really do think that AI + automation + carefully-designed guardrails will unleash a deluge of productivity for normies, and we've barely scratched the surface.
The state of AI apps is absolutely trash right now, it’s embarrassing that these companies that raised millions are releasing the shittiest slop around without any product ethos. Obviously we're seeing what sticks, but come on guys.
I'm using Brett Cannon's `https://github.com/brettcannon/cpython-wasi-build` running inside a WASI rust container with a carefully-designed host SDK (e.g. sandboxed Chromium access, diff, sandboxed filesystem, pandas subset, PDF reading, etc.). Essentially the AI sees a goal, a plan, and essentially treats the "task space" as a WASI-powered Python notebook.
Mainly focused on the user experience, and I think that local LLMs (secure/private) + standard Python + host functions + (some external stuff like screen reading & quarantined web access) is more than enough for 90% of actionable tasks.
P.S. I was casually searching for "sandboxed Python" for an experiment I'm working on, and reached this article that was published "today". Very nice coincidence! Thanks.
The thing that's missing is Windows support and the ability to get everything I need for it in a Python program by "pip install X" for something that includes relevant binaries as well as Python code.
fzysingularity 1 days ago [-]
What’s your experience with Monty? Been looking at it for one of our environments and it seems very promising.
simonw 1 days ago [-]
I've tried it out a bit - it does look solid and it has a good team behind it.
It's a subset of Python though (much more so than MicroPython), which is fine for LLMs since they can easily work around any limitations but does mean you can't use a lot of existing Python code with it. I hope they implement classes soon!
I'm also a little bit nervous about the safety. It's a fresh implementation in Rust, which means plenty of possibilities for edge case security bugs. The thing I like about WebAssembly is that there's a robust, well tested sandbox already - better for defense in depth.
I certainly wouldn't bet against Monty though! It may well prove itself to be a great solution for this.
My use-cases for server-side WASM Python are described here: https://simonwillison.net/2026/Jun/6/micropython-in-a-sandbo... - basically I want to offer end-user customization features that run custom code without buggy or malicious code crashing my app or leaking their data.
andrewaylett 1 days ago [-]
Running arbitrary untrusted code safely is pretty easy nowadays, so long as the code is written in Javascript and you want to run it in a browser. It's only a little harder if the code is written in another language but targets WASM and browser APIs, or if you want to run your WASM inside of NodeJS, and there's even good support for running Python in a browser or Node.
Once you get away from running in a JS environment or away from code that's written with the intention of running in a WASM sandbox, if you don't want to have to modify the code for your environment then you're going to start having problems. This looks like a good step for anyone wanting to run arbitrary Python outside of a browser environment.
simonw 1 days ago [-]
I've actually found it pretty hard in a browser as well - if you want to run untrusted code without it breaking your app or stealing cookies etc.
I've been doing a bunch of work recently with iframe sandbox combined with CSP which appears to be a robust way to do this.
andrewaylett 4 hours ago [-]
Fair -- but I was more meaning that when I browse an arbitrary untrusted website I almost always allow the site owner to run arbitrary untrusted code on my machine. They might not send me any JS, but if they do then my browser will happily execute it.
theanonymousone 1 days ago [-]
For me it is a tool I avail to an LLM so that it can provide correct answers to a certain category of questions, instead of hallucinating nonsense.
roywiggins 1 days ago [-]
The idea is to expose it as a tool to your LLM agent so it can run calculations on its own initiative.
rdksu 1 days ago [-]
Google also released colab-cli a couple of days back and its pretty good at functioning as an isolated sandbox for running random python scriptS .
1 days ago [-]
hmokiguess 1 days ago [-]
Super tangential comment but glad to see I'm not the only one that send typos to sessions and still get good results.
This stuff always gets me anxious for no reason because of the underlying tokenizer and prediction stochastic parrot that runs stuff, makes me wonder if I should rerun the prompt correcting the typo or accept the token tax on some interpreter that spent translating the intention.
simonw 1 days ago [-]
Yeah I'm very loose with my prompting now - I can usually tell from the reasoning traces if it correctly interpreted any typos.
If it looks like it didn't I hit "stop" and then edit and resubmit my prompt.
https://labs.leaningtech.com/blog/browserpod-deep-dive
Node.js is now fully supported, Python is in preview and Rust is coming soon.
For a glimpse of the possibilities, check our Claude Code running fully in the browser: https://browsercode.io/claude
Are you running the version of Claude code that Anthropic distributes in the browser or did you have to adapt it to run on your stack?
Cheers
The version of Claude Code you see running is completely unmodified.
We have quite a bit of experience on the topic however, these are previous projects of ours:
WebVM (https://webvm.io): x86 Debian shell running client-side in the browser via x86 -> WebAssembly JIT compilation
Browsercraft (https://browsercraft.cheerpj.com): Minecraft running unmodified in the browser via our WebAssembly JVM (CheerpJ)
Keep up the great work
WebVM uses x86 virtualization and hence has a significant performance penalty, with the upside of running any existing software without needing the source code.
BrowserPod on the other hand runs WebAssembly binaries at almost native speed. Source code is required, but that is a fair compromise in the world of sandboxing. Most language runtimes and CLI tools are FOSS anyway, and many closed-source tools (such as Claude Code) are written in scripting languages and run on top of FOSS engines.
I have absolutely no relation to the project except for the fact that I went to the same Uni as the creator.
It's not quite right for what I'm after because you can't just "pip install" it on multiple platforms.
Basically: run as another user -> run inside firejail sandbox -> run inside a stripped down alpine linux vm with smolvm.
See the whole procedure here: https://www.reddit.com/r/LocalLLaMA/comments/1tm93ng/how_i_d...
P.S. directories can be easily shared between the sandboxed guest and the host os
P.P.S. to stay a bit more on the safe side I also changed the name of the package manager for the guest os to something else so that when a coding agent would try to autonomously install external packages it will fail. I've then instructed it to (politely) ask for whatever it needs to be eventually manually installed by me
The state of AI apps is absolutely trash right now, it’s embarrassing that these companies that raised millions are releasing the shittiest slop around without any product ethos. Obviously we're seeing what sticks, but come on guys.
I'm using Brett Cannon's `https://github.com/brettcannon/cpython-wasi-build` running inside a WASI rust container with a carefully-designed host SDK (e.g. sandboxed Chromium access, diff, sandboxed filesystem, pandas subset, PDF reading, etc.). Essentially the AI sees a goal, a plan, and essentially treats the "task space" as a WASI-powered Python notebook.
Mainly focused on the user experience, and I think that local LLMs (secure/private) + standard Python + host functions + (some external stuff like screen reading & quarantined web access) is more than enough for 90% of actionable tasks.
Very exciting times ahead.
it's Rust so can be compile to wasm, example: https://github.com/hyper-mcp-rs/monty-plugin
It's a subset of Python though (much more so than MicroPython), which is fine for LLMs since they can easily work around any limitations but does mean you can't use a lot of existing Python code with it. I hope they implement classes soon!
I'm also a little bit nervous about the safety. It's a fresh implementation in Rust, which means plenty of possibilities for edge case security bugs. The thing I like about WebAssembly is that there's a robust, well tested sandbox already - better for defense in depth.
I certainly wouldn't bet against Monty though! It may well prove itself to be a great solution for this.
I’d love to see if we can get GPU access within these runtimes, that’d be awesome.
I have a live demo with datasette-agent-micropython running at https://agent.datasette.io - you need to sign in with GitHub to try it.
I was thinking the client side WASM version would be useful as a platform for beginners to practice a subset of Python in.
I can't really think of any good WASI use cases.
- https://lite.datasette.io - my Datasette app in a browser
- https://simonw.github.io/research/pyodide-asgi-browser/datas... is a new, improved version of that using Service Workers that's still a little experimental - notes here: https://simonwillison.net/2026/May/30/pyodide-asgi-browser/
- https://tools.simonwillison.net/micropython runs a MicroPython playground in the browser via WebAssembly
My use-cases for server-side WASM Python are described here: https://simonwillison.net/2026/Jun/6/micropython-in-a-sandbo... - basically I want to offer end-user customization features that run custom code without buggy or malicious code crashing my app or leaking their data.
Once you get away from running in a JS environment or away from code that's written with the intention of running in a WASM sandbox, if you don't want to have to modify the code for your environment then you're going to start having problems. This looks like a good step for anyone wanting to run arbitrary Python outside of a browser environment.
I've been doing a bunch of work recently with iframe sandbox combined with CSP which appears to be a robust way to do this.
Was reading your https://chatgpt.com/share/6a1e2a5c-58b8-8328-ba1c-0e6aadb0a0... and noticed the "my on Python tools" instead of "my own Python tools" (apologies for the grammar police)
This stuff always gets me anxious for no reason because of the underlying tokenizer and prediction stochastic parrot that runs stuff, makes me wonder if I should rerun the prompt correcting the typo or accept the token tax on some interpreter that spent translating the intention.
If it looks like it didn't I hit "stop" and then edit and resubmit my prompt.