Why do you think there is a lot of training data? Could it be because it's stable and virtually unchanged for decades? Hmmm.
esafak•Feb 26, 2026
Because bash is everywhere. Stability is a separate concern. And we know this because LLMs routinely generate deprecated code for libraries that change a lot.
gaigalas•Feb 26, 2026
This project runs on all shells, totally portable:
It's a great litmus test, that many have passed. Let me know when just-bash is able to run it.
esafak•Feb 26, 2026
I have no connection to coral or just-bash. Why don't you do it yourself and let us know, since you are familiar with it?
gaigalas•Feb 26, 2026
I've been working with the shell long enough that I know just by looking at it.
Anyway, it was rethorical. I was making a point about portability. Scripts we write today run even on ancient versions, and it has been an effort kept by lots of different interpreters (not only bash).
I'm trying to give sane advice here. Re-implementing bash is a herculean task, and some "small incompatibilities" sometimes reveal themselves as deep architectural dead-ends.
esafak•Feb 26, 2026
The project does not list portability as a concern. It's for agent use; they are not trying to re-use existing bash code.
gaigalas•Feb 26, 2026
Before, you said:
> they use it because there's a lot of training material.
Now, you say:
> they are not trying to re-use existing bash code.
Can't you see how this is a contradiction?
---
I'm sorry, I can't continue like this. I want to have meaningful conversations.
esafak•Feb 26, 2026
Is English your second language? "They" refers to very different things here.
simonw•Feb 26, 2026
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.
gaigalas•Feb 26, 2026
I don't think the current incompatibilities can be worked around.
Also, huge waste of tokens. And the waste is not even worth it, the sandbox seems insufficient.
Again, good luck to the developers. I just don't think it's ready.
cramforce•Feb 26, 2026
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]
jpitz•Feb 26, 2026
Just curious: why wouldn't you attack this with a jail?
wild_egg•Feb 26, 2026
Jails are alien magic and typescript is safe and familiar
otterley•Feb 26, 2026
What, exactly, is "safe" about TypeScript other than type safety?
TypeScript is just a language anyway. It's the runtime that needs to be contained. In that sense it's no different from any other interpreter or runtime, whether it be Go, Python, Java, or any shell.
In my view this really is best managed by the OS kernel, as the ultimate responsibility for process isolation belongs to it. Relying on userspace solutions to enforce restrictions only gets you so far.
wild_egg•Feb 26, 2026
Ah I forgot to add an /s
I agree on all counts and that this project is silly on the face of it.
My comment was more that there is a massive cohort of devs who have never done sysadmin and know nothing of prior art in the space. Typescript "feels" safe and familiar and the right way to accomplish their goals, regardless of if it actually is.
lombasihir•Feb 26, 2026
agree, or just busybox or alpine linux that will have more flexibility?
but i think its still useful if we are bound to js/ts ecosystem sandboxed enviroment like in vercel.
IceWreck•Feb 26, 2026
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.
wild_egg•Feb 26, 2026
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
bigbadfeline•Feb 26, 2026
> Agents really do not care at all how "nice" a language is.
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.
simonw•Feb 26, 2026
Being unchanged for decades means that the training data should provide great results even for the smaller models.
fragmede•Feb 26, 2026
It means there's also plenty of bad examples in the training data to learn the wrong lessons from though.
sheept•Feb 26, 2026
I feel like Deno would be perfect for this because it already has a permissions model enforced by the runtime
inetknght•Feb 26, 2026
Bash is ubiquitous and is not going away any time soon. Nothing is stopping you from doing the same thing with your favorite language.
kkukshtel•Feb 26, 2026
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.
At least for me codex seems to write way more python than bash for general purpose stuff
jauntywundrkind•Feb 26, 2026
Agreed! Very notable codex behavior to prefer python for scripting purposes.
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?
JohnMakin•Feb 26, 2026
They use bash in ways a human never would, and it seems very intuitive for them.
Spivak•Feb 26, 2026
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.
0x457•Feb 26, 2026
There are a lot of shellscripts holding this world together out there.
andrewingram•Feb 26, 2026
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.
Bolwin•Feb 26, 2026
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
> 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.
Leynos•Feb 26, 2026
Codex has a JS REPL built in now. And pydantic have a minimal version of Python called Monty.
westurner•Feb 26, 2026
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.
> 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?
> How do these userspace policies compare to MAC and DAC implementations like SELinux AVC, AppArmor, Systemd SyscallFilter, and seccomp with containers for example?
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.
fragmede•Feb 26, 2026
I want them to be better at it, but given how hard it is for me as a human to get it right (which is to say, I get it wrong a lot, especially handling new lines in filenames, or filenames that start with --) I find it hard to fault them too much.
huntaub•Feb 26, 2026
We just released a driver that allows users of just-bash to attach a full Archil file system, synced to S3. This would let you run just-bash in an enrivonment where you don't have a full VM and get high-performance access to data that's in your S3 bucket already to do like greps or edits.
I have been playing around with something like this.
I'm not going for compatibility, but something that is a bit hackable. Deliberately not having /lib /share and /etc to avoid confusion that it might be posix
This ends up reading files into node.js and then running a command like grep but implemented in JS. I love the concept but isn’t this incredibly slow compared to native cli tools? Building everything in JS on top of just readFile and writeFile interfaces seems pretty limited in what you can do for performance.
simonw•Feb 26, 2026
Performance of the tools doesn't really matter when you have a full LLM inference loop in between each tool call.
tcdent•Feb 26, 2026
I still find it revolting they're writing this stuff in typescript.
cramforce•Feb 26, 2026
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]
_pdp_•Feb 26, 2026
Interesting concept but I think the issue is to make the tools compatible with the official tools otherwise you will get odd behaviour. I think it is useful for very specific scenarios where you want to control the environment with a subset of tools only while benefiting from some form of scripts.
dostick•Feb 26, 2026
Why couldn’t they name it `agent-bash` then? What’s with all the “just-this”, “super-that” naming?
Like developer lost the last remaining brain cells developing it, and when it’s came to name it, used the first meaningless word that came up.
After all you’re limiting discovery with name like that.
jeffchuber•Feb 26, 2026
last weekend I vibe-coded a project called `openfs` that plugs into just-bash
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.
jeffchuber•Feb 26, 2026
yeah (optional) caching is interesting to think about - incl write_through and write_back
JustFinishedBSG•Feb 26, 2026
What problem were you trying to solve ? ( not that you need to solve one. I’m just curious )
throwaway13337•Feb 26, 2026
The 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 must try because they see the writing on the wall.
No one needs expensive cloud platforms anymore.
justaboutanyone•Feb 26, 2026
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
cyanydeez•Feb 26, 2026
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.
CuriouslyC•Feb 26, 2026
Trying to secure the sandbox the harness is running in seems like the hard way to do things. It's not a bad idea, but I think it'd be easier to focus on isolating the sandbox and securing resources the harness sandbox accesses, since true security requires that anyhow.
It’s cool to see this project and others pop up. Virtualizing os primitives like bash and even file systems
You can interface around the nodejs files system interface and have access to some nice tools, like git isomorphic for instance. Then obviously everything couples nicely with agents.
14 Comments
That's a lot of incompatibilities.
LLMs like to use the shell because it's stable and virtually unchanged for decades.
It doesn't need to worry much about versions or whether something is supported or not, it can just assume it is.
Re-implementing bash is a herculean effort. I wish good luck.
pro-tip: vercel's https://agent-browser.dev/ is a great CLI for agent-based browser automation.
https://github.com/alganet/coral
busybox, bash, zsh, dash, you name it. If smells bourne, it runs. Here's the list: https://github.com/alganet/coral/blob/main/test/matrix#L50 (more than 20 years of compatibility, runs even on bash 3)
It's a great litmus test, that many have passed. Let me know when just-bash is able to run it.
Anyway, it was rethorical. I was making a point about portability. Scripts we write today run even on ancient versions, and it has been an effort kept by lots of different interpreters (not only bash).
I'm trying to give sane advice here. Re-implementing bash is a herculean task, and some "small incompatibilities" sometimes reveal themselves as deep architectural dead-ends.
> they use it because there's a lot of training material.
Now, you say:
> they are not trying to re-use existing bash code.
Can't you see how this is a contradiction?
---
I'm sorry, I can't continue like this. I want to have meaningful conversations.
Also, huge waste of tokens. And the waste is not even worth it, the sandbox seems insufficient.
Again, good luck to the developers. I just don't think it's ready.
In practice it works great. I haven't seen a failed command in a while
[Disclaimer: I made the thing]
TypeScript is just a language anyway. It's the runtime that needs to be contained. In that sense it's no different from any other interpreter or runtime, whether it be Go, Python, Java, or any shell.
In my view this really is best managed by the OS kernel, as the ultimate responsibility for process isolation belongs to it. Relying on userspace solutions to enforce restrictions only gets you so far.
I agree on all counts and that this project is silly on the face of it.
My comment was more that there is a massive cohort of devs who have never done sysadmin and know nothing of prior art in the space. Typescript "feels" safe and familiar and the right way to accomplish their goals, regardless of if it actually is.
but i think its still useful if we are bound to js/ts ecosystem sandboxed enviroment like in vercel.
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.
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.
https://luau.org/
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?
Gotta work with what's in the training data I suppose.
Ideally something like nushell but they don't know that well
> 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.
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
Check it out here: https://www.npmjs.com/package/@archildata/just-bash
I'm not going for compatibility, but something that is a bit hackable. Deliberately not having /lib /share and /etc to avoid confusion that it might be posix
On neocoties for proof of static hosting
https://lerc.neocities.org
[Disclaimer: I made the thing]
https://github.com/jeffchuber/just-bash-openfs
it puts a bash interface in front of s3, filesystem (real and in-memory), postgres, and chroma.
still very much alpha - but curious what people think about it.
see an example app here: https://github.com/jeffchuber/openfs-incident-app
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 must try because they see the writing on the wall.
No one needs expensive cloud platforms anymore.
I can trivially combine a tool written in rust with one written in js/java/C/whatever without writing bindings
So, mostly re-enforcement along multiple vectors.
You can interface around the nodejs files system interface and have access to some nice tools, like git isomorphic for instance. Then obviously everything couples nicely with agents.
Something I did in my markdown editor project: https://github.com/rbbydotdev/opal
Have half a mind to release a browser kit which unifies the file tree explorer and virtual file apis and libs in the browser
I've been using it to make my own sandbox that is much more configurable than the default claude code sandbox: https://github.com/gartnera/lite-sandbox