The language choice is somewhat orthogonal to the real problem - you still need a governance layer regardless of whether agents execute bash, Python, or TypeScript.
We built Execwall [1] to sit between the agent and the OS, enforcing argument-level policies. So you can allow git clone but deny git push, or allow chmod 644 but block chmod 777. Works with any shell or execution method.
The key insight is that "restricted subsets" of languages still need policy enforcement at runtime - an agent can construct dangerous commands dynamically even in a sandboxed language.
[1] https://github.com/sundarsub/execwall
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
The language choice is somewhat orthogonal to the real problem - you still need a governance layer regardless of whether agents execute bash, Python, or TypeScript.
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.
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/
Bash is ubiquitous and is not going away any time soon. Nothing is stopping you from doing the same thing with your favorite language.
I feel like Deno would be perfect for this because it already has a permissions model enforced by the runtime
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
Being unchanged for decades means that the training data should provide great results even for the smaller models.
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.
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.
Check it out here: https://www.npmjs.com/package/@archildata/just-bash
last weekend I vibe-coded a project called `openfs` that plugs into just-bash
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
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.
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.
Performance of the tools doesn't really matter when you have a full LLM inference loop in between each tool call.
I still find it revolting they're writing this stuff in typescript.
Just curious: why wouldn't you attack this with a jail?
Jails are alien magic and typescript is safe and familiar
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.
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
On neocoties for proof of static hosting
https://lerc.neocities.org
https://github.com/vercel-labs/just-bash/blob/main/src/spec-...
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.
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.
Why do you think there is a lot of training data? Could it be because it's stable and virtually unchanged for decades? Hmmm.
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.
This project runs on all shells, totally portable:
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.
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?
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.
> No, they use it because there's a lot of training material.
Trained on an interpreter that is stable is virtually unchanged for decades. That's precisely my point.
It was never trained on an incompatible, partial implementation.
> agent-based browser automation
Clearly out of scope. You a bot?