Hacker News

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.

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/

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.

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

Codex has a JS REPL built in now. And pydantic have a minimal version of Python called Monty.

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.

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.

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

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

What problem were you trying to solve ? ( not that you need to solve one. I’m just curious )

I did a slightly less ambitious prototype a few weeks ago where I created added lazy loading of GCS files into the just-bash file-systems, as well as lots of other on-demand files. Was a lot of fun.

Jails are alien magic and typescript is safe and familiar

Shell programming is high density inter-language glue. You simply have more options of implementations to call out to and so less to write.

I can trivially combine a tool written in rust with one written in js/java/C/whatever without writing bindings

If you want a better guess: It's because of the man pages for all the tools are likely duplicated across so many media for the LLM training that there's just an efficient pipeline. They go back to the 70s or whatever.

So, mostly re-enforcement along multiple vectors.

In practice it is actually extremely fast because there is no process fork. You're talking nanoseconds for common commands

[Disclaimer: I made the thing]

Performance of the tools doesn't really matter when you have a full LLM inference loop in between each tool call.

I would not over-read into that doc. In practice, the only missing stuff are extreme edge cases of the type that is actually not consistent between other implementations of bash.

In practice it works great. I haven't seen a failed command in a while

[Disclaimer: I made the thing]

Incompatibilities don't matter much provided your error messages are actionable - an LLM can hit a problem, read the error message and try again. They'll also remember that solution for the rest of that session.

No, they use it because there's a lot of training material.

pro-tip: vercel's https://agent-browser.dev/ is a great CLI for agent-based browser automation.