At this point why not make the agents use a restricted subset of python, typescript or lua or something.
Bash has been unchanged for decades but its not a very nice language.
I know pydantic has been experimenting with https://github.com/pydantic/monty (restricted python) and I think Cloudflare and co were experimenting with giving typescript to agents.
Being unchanged for decades means that the training data should provide great results even for the smaller models.
They use bash in ways a human never would, and it seems very intuitive for them.
I'll add that agents (CC/Codex) very often screw up escaping/quoting with their bash scripts and waste tokens figuring out what happened. It's worse when it's a script they save and re use because it's often a code injection vulnerability.
Agents really do not care at all how "nice" a language is. You only need to be picky with language if a human is going to be working with the code. I get the impression that is not the use case here though
I've had LLMs write some pretty complex powershell on the fly. Still a shell language but a lot nicer.
Ideally something like nushell but they don't know that well
Bash is ubiquitous and is not going away any time soon. Nothing is stopping you from doing the same thing with your favorite language.
just-bash comes with Python installed, so in a way that's what this has done. I've used this for some prototypes with AI tools (via bash-tool), can't really productionise it in our current setup, but it worked very well and was undeniably pretty cool.
Codex has a JS REPL built in now. And pydantic have a minimal version of Python called Monty.
I feel like Deno would be perfect for this because it already has a permissions model enforced by the runtime
At least for me codex seems to write way more python than bash for general purpose stuff
I came across a coding harness using Lua as its control plane yesterday: https://github.com/hsaliak/std_slop/blob/main/docs/lua_integ...
> std::slop is a persistent, SQLite-driven C++ CLI agent. It remembers your work through per-session ledgers, providing long-term recall, structured state management. std::slop features built-in Git integration. It's goal is to be an agent for which the context and its use fully transparent and configurable.
TIL about Monty. A number of people have tried to sandbox [python,] using python and user space; but ultimately they've all concluded that you can't sandbox python with python.
Virtual Machines are a better workload isolation boundary than Containers are a better workload isolation boundary than bubblewrap and a WASM runtime.
eWASM has costed opcodes; https://news.ycombinator.com/item?id=46825763
From "Show HN: CSL-Core – Formally Verified Neuro-Symbolic Safety Engine for AI" (2026) https://news.ycombinator.com/item?id=46963924 :
> Should a (formally verified) policy engine run within the same WASM runtime, or should it be enforced by the WASM runtime, or by the VM or Container that the WASM runtime runs within?
> "Show HN: Amla Sandbox – WASM bash shell sandbox for AI agents" (2026) https://news.ycombinator.com/item?id=46825026 re: eWASM and costed opcodes for agent efficiency
> How do these userspace policies compare to MAC and DAC implementations like SELinux AVC, AppArmor, Systemd SyscallFilter, and seccomp with containers for example?
> [ containers/bubblewrap#sandboxing , cloudflare/workerd, wasmtime-mte, ]
"Microsandbox: Virtual Machines that feel and perform like containers" https://news.ycombinator.com/item?id=44137501
microsandbox/microsandbox: https://github.com/microsandbox/microsandbox :
> opensource self-hosted sandboxes for ai agents
[dead]
This is a really interesting idea. I wonder if something like Luau would be a good solution here - it's a typed version of Lua meant for sandboxing (built for Roblox scripting) that has a lot of guardrails on it.
https://luau.org/