I really like this!
Claude Code always resorts to running small python scripts to test ideas when it gets stuck.
Something like this would mean I dont need to approve every single experiment it performs.
Monty: A minimal, secure Python interpreter written in Rust for use by AI
101–110 of 179 posts
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#102I really like this! Claude Code always resorts to running small python scripts to test ideas when it gets stuck. Something like this would mean I dont need to approve every single experiment it performs.
Didn’t Anthropic recently acquire some JavaScript engine, though?
I figured that that was because they want tighter integration and a safer execution environment for code written by the LLM. And sandboxing is already very common for JavaScript in browsers.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#103This is very cool, but I'm having some trouble understanding the use cases.
Is this mostly just for codemode where the MCP calls instead go through a Monty function call? Is it to do some quick maths or pre/post-processing to answer queries? Or maybe to implement CaMeL?
It feels like the power of terminal agents is partly because they can access the network/filesystem, and so sandboxed containers are a natural extension?
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#104I got a WebAssembly build of this working and fired up a web playground for trying it out: https://simonw.github.io/research/monty-wasm-pyodide/demo.ht... It doesn't have class support yet! But it doesn't matter, because LLMs that try to use a class will get an error message and rewrite their code to not use classes instead. Notes on how I got the WASM build working here: https://simonwillison.net/2026/Feb/6/pydantic…
This is very cool, but I'm having some trouble understanding the use cases.
Is this mostly just for codemode where the MCP calls instead go through a Monty function call? Is it to do some quick maths or pre/post-processing to answer queries? Or maybe to implement CaMeL?
It feels like the power of terminal agents is partly because they can access the network/filesystem, and so sandboxed containers are a natural extension?
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#105Earlier quoted context omitted.
[flagged]
How do you feel about software engineers who build open source libraries? Open source has been responsible for enormous productivity boosts in our industry, because we don't all have to build duplicates of exactly the same thing time and time again. But think of all of the jobs that were lost by people who would otherwise been employed building the 500th version of a CSS design system, or a template engine, or code t…
Of course comparing open source and AI is like comparing apples and oranges, but the question makes a lot of sense. Just the first thing that comes to mind: open source is about transparency whereas LLMs are opaque by nature. This is a radical shift and challenge for engineering and has consequences way beyond it.
It's about the role of technologies in evolution, responsibility versus utilitarian take, etc. It should be developed and discussed seriously, but not in a buried sub-thread.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#106Earlier quoted context omitted.
Having been doing Python for over a decade and JavaScript. I would pick Python any day of the week over JavaScript. JavaScript is beautiful, and also the most horrific programming language all at once. It still feels incomplete, there's too many oddities I've run into over the years, like checking for null, empty, undefined values is inconsistent all around because different libraries behave differently.
TBF is the Python ecosystem any different? None and dict everywhere, requirements.txt without pinned versions... I'm not complaining either, as I wouldn't expect a unified typed experience in ecosystems where multiple competing type checkers and package managers have been introduced gradually. How could any library from the python3.4 era foresee dataclass es or the typing module? Such changes take time, and I favor a…
It was better because it had no silent errors, like 1+”1”. Far from perfect, the fact it raised exceptions and enforced the philosophy of “don’t ask for permission but forgiveness” makes the difference.
IMHO It’s irrelevant it has a slightly better typesystem and runtime but that’s totally irrelevant nowadays.
With AI doing mostly everything we should forget these past riddles. Now we all should be looking towards fail-safe systems, formal verification and domain modeling.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#107Earlier quoted context omitted.
As discussed on twitter, v8 shows that's not true. But to be clear, we're not even targeting the same "computer use" use case I think e2b, daytona, cloudflare, modal, fly.io, deno, google, aws are going after - we're aiming to support programmatic tool calling with minimal latency and complexity - it's a fundamentally different offering. Chill, e2b has its use case, at least for now.
There's been a constant stream of v8 VM sandbox escape discoveries since its dawn of course. Considering those have mostly existed for a long time before publication it's very porous most of the time. And Python VM had/has its sandboxing features too, previously rexec and still https://github.com/zopefoundation/RestrictedPython - in the same category I'd argue. Then there's of course hypervisor based virtualization a…
> It's all layers of porous defenses.
Also known as the "swiss cheese model" in risk management.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#108Serious question: why won’t JUST use SELinux on generated scripts?
It will have access to the original runtimes and ecosystems and it can’t be tampered, it’s well tested, no amount of forks and tricky indirections to bypass syscalls.
Such runtimes come with a bill of technical debt, no support, specific documentation and lack of support for ecosystem and features. And let’s hope in two years isn’t abandoned.
Same could be applied for docker or nix Linux, or isolated containers, etc… the level of security should be good enough for LLMs, not even secure against human (specialist hackers) directed threads
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#109Earlier quoted context omitted.
3 reasons why Python is much better than JS for this IMO. 1. Large built-in standard library (CSV, sqlite3, xml/json, zipfile). 2. In Python, whatever the LLM is likely to do will probably work. In JS, you have the Node / Deno split, far too many libraries that do the same thing (XMLHTTPRequest / Axios / fetch), many mutually-incompatible import syntaxes (E.G. compare tsx versus Node's native ts execution), and featu…
> In JS, you have the Node / Deno split, You do? Deno is maybe a single digit percentage of the market, just hyped tremendously. > E.G. compare tsx versus Node's native ts execution JSX/TSX, despite what React people might want you to believe, are not part of the language. > which only work if you pray three times on the day of the full moon. It only doesn't work in some contexts due to legacy reasons. Otherwise it's…
> JSX/TSX, despite what React people might want you to believe, are not part of the language.
Similarly: TypeScript, despite what Node people might want you to believe, is not part of the JavaScript language.
Re: Monty: A minimal, secure Python interpreter written in Rust for use by AI
#110Earlier quoted context omitted.
3 reasons why Python is much better than JS for this IMO. 1. Large built-in standard library (CSV, sqlite3, xml/json, zipfile). 2. In Python, whatever the LLM is likely to do will probably work. In JS, you have the Node / Deno split, far too many libraries that do the same thing (XMLHTTPRequest / Axios / fetch), many mutually-incompatible import syntaxes (E.G. compare tsx versus Node's native ts execution), and featu…
> In JS, you have the Node / Deno split, You do? Deno is maybe a single digit percentage of the market, just hyped tremendously. > E.G. compare tsx versus Node's native ts execution JSX/TSX, despite what React people might want you to believe, are not part of the language. > which only work if you pray three times on the day of the full moon. It only doesn't work in some contexts due to legacy reasons. Otherwise it's…
> JSX/TSX, despite what React people might want you to believe, are not part of the language.
I think you misunderstood this. tsx in this context is/was a way to run typescript files locally without doing tsc yourself first, ie make them run like a script. You can just use Node now, but for a long time it couldn’t natively run typescript files.
The only limitation I run into using Node natively is you need to do import types as type imports, which I doubt would be an issue in practice for agents.