Earlier quoted context omitted.
They use bash in ways a human never would, and it seems very intuitive for them.
If you present most LLM's with a run_python tool it won't realize that it can access a standard Linux userspace with it even if it's explicitly detailed. But spiritually the same tool called run_shell it will use correctly. Gotta work with what's in the training data I suppose.
Just-bash: Bash for Agents
51–60 of 78 posts
Re: Just-bash: Bash for Agents
#52At 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.
Re: Just-bash: Bash for Agents
#53At 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.
> 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.
Re: Just-bash: Bash for Agents
#54At 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.
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
People do care.
> You only need to be picky with language if a human is going to be working with the code.
Sooner or later humans will have to work with the code - if only for their own self-preservation.
> I get the impression that is not the use case here though
If that's not the use case, there's no legitimate use case at all.
Re: Just-bash: Bash for Agents
#55[flagged]
Re: Just-bash: Bash for Agents
#56At 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.
At least for me codex seems to write way more python than bash for general purpose stuff
I keep telling myself to make a good zx skills or agents.md. I really like zx ergonomics & it's output when it shells out is friendly.
Top comments are lua. I respect it, and those look like neat tools. But please, not what I want to look at. It would be interesting to see how Lua fairs for scripting purposes though; I haven't done enough io to know what that would look like. Does it assume some uv wrapper too?
Re: Just-bash: Bash for Agents
#57At 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.
Re: Just-bash: Bash for Agents
#58At 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.
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
Re: Just-bash: Bash for Agents
#59At 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.
Re: Just-bash: Bash for Agents
#60The unix commandline tools being the most efficient way to use an LLM has been a surprise. I wonder the reason. Maybe 'do one thing well'? The piping? The fact that the tools have been around so long so there are so many examples in the training data? Simplicity? All of it? The success of this project depends on the answer. Even so, I suspect that something like this will be a far too leaky abstraction. But Vercel mu…
I can trivially combine a tool written in rust with one written in js/java/C/whatever without writing bindings