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.
One-off throwaway scripts can be written in literally anything. It does not matter.
We want that to be true, but it's starting to look like it might not be.
Ideally something like nushell but they don't know that well
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?
> 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
Demo: https://wizard-nine-blush.vercel.app/
Project: https://ink-web.dev
I love the approach of just bash as well. Super cool!
Edit: warning - don't use it mobile.
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.
There's also the maintenance of the server to be considered. Vercel or other PaaS/Lambda/GCP functions/etc serverless means there's just less crap for me to manage, because they're dealing with it, and yeah, they charge money for that service. Being able to tell Claude code, I setup ssh keys and sudo no password for you, go fix my shit; like, that works, but then the hard drive is full so I have to up size the VPS, and if you're stupid/brave, you can give Claude Code MCP access to Chrome so it can click the buttons in Hetzner to upsize for you, but that's time and tokens spent not working on the product so at the end of the day I think Vercel is gonna be fine. AI generating code means there are many many more people trying out making some sort of Internet company, but they'll only discover cheaper options only after paying for Vercel becomes painful.
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.
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
[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]
Good luck with the project! I'm sure it will get there.
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.
I can't have a meaningful conversation with someone that doesn't fully grasp those, no matter in which language.