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.

On the "why bash not python/lua" question -- the answer isn't that bash is a better language. It's that bash is the only language you can assume is there.

When we run autonomous agents across different environments (Vercel functions, local dev, CI containers, remote VMs), Python availability is a negotiation. Bash is given. The agent doesn't need to worry about whether venv is activated, which Python version is installed, or whether a package needs to be pip-installed first.

There's also a subtler benefit: bash commands have predictable, well-documented side effects. When an agent runs `git commit -m "..."` it knows exactly what happened. When it runs a Python script that does the same thing via subprocess, there's now an abstraction layer to reason about.

The performance concern is real for I/O-heavy tasks. But for orchestration -- "list files, check git status, curl an API, write a line to a log" -- bash overhead is negligible and the interoperability wins dominate.

The place where this breaks down is anything requiring complex data transformation or error handling with multiple failure modes. That's where we drop into Python. The architecture that works for us: bash for the orchestration layer (run this, check that, pipe here), Python for anything with real logic.

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.

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.

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

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

Just curious: why wouldn't you attack this with a jail?

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.

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

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.

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.

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.