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
Check it out here: https://www.npmjs.com/package/@archildata/just-bash
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.
Gotta work with what's in the training data I suppose.
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.
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.
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?
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
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 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.
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
but i think its still useful if we are bound to js/ts ecosystem sandboxed enviroment like in vercel.
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.
[Disclaimer: I made the thing]
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
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.
In practice it works great. I haven't seen a failed command in a while
[Disclaimer: I made the thing]
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.
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.