I wonder how he imagines you can give shell access but securely prevent arbitrary command execution.
His complaint that "echo git | bash" still works is particularly nutty.
His complaint that "echo git | bash" still works is particularly nutty.
This works for the `bash` example too. Spawning a new shell and running arbitrary commands is not an escalation because the child shell inherits the parent's restrictions.
You can't give shell access and then revoke special parts of it. This is not controversial.
All your criticisms apply to all LLM harnesses - and everyone who genuinely cares about these things is using security on top of the harness, because OBVIOUSLY.
Your complaints are misguided.
This doesn't require cooperation from the shell. If writable paths are non-executable, and executable paths are non-writable, then executing `cp $(which git) my-new-favourite-binary` doesn't grant you permission to run it.
The part which does require cooperation (from outside of the shell, i.e. from the harness) is the ability to upgrade writable paths to executable, at the cost of writability and whatever other restrictions you place on the binaries generated by your agent.
This kind of W^X invariant is widely deployed in every desktop operating system, and the type of W-X upgrade hook I described is used by every JIT engine.
I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?
> You are confusing CPU-level security with filesystem-level security.
> I'm curious - how do you expect an LLM harness to build and test executables without being able to build and execute executables?
W^X applies to file systems as well as page tables, and this is called out in paragraph 4 of the Wikipedia article you didn't read. Respectfully, I'm leaving this conversation at this point because it doesn't seem productive.
My question stands - if you accept that LLM harnesses are designed to allow the building and testing of executables - how do you imagine you can prevent the building and running of executables?
Respectfully.
Separation of duties and ephemerality are well-known security mechanisms that many harnesses jump right over in the pursuit of easier UX.
Mingling permissions + trusting vibe-coded security boundaries in the harness itself (developed by folks whose appetite for risk would make even an 00s front-end developer blush) is rolling a handful of dice all at once.
But fundamentally, this is a disagreement between two risk appetites who will never agree: {it works most of the time} vs {it's guaranteed to never fail}
I'm not sure why you disbelieve agents can do "guaranteed to never fail". Proving correctness is one of their strengths. Proofs in general, in fact, much much better than the typical human coder.
Because I must warn you - it's extremely easy to ask a coding agent to prove code correctness before committing his work.
But that doesn't mean they don't have >0% failure modes, often in very non-human, unexpected, even dangerous ways.
Whether that's "sloppy"?
Eh, it's just the nature of the tool, like a perfect screwdriver that randomly strips 1% of screws.
> it's extremely easy to ask a coding agent to prove code correctness
That statement is categorically wrong.
If you're talking about a formal proof for non-trivial, real-world code, no.
If you're talking about a comprehensive set of tests... well, I'd challenge you to elucidate how you see creating a comprehensive set of tests as trivial.
And if the answer is more LLM... then I think we're at a fundamental disagreement about what satisfies "guarantee" or "provable".
I invite you to examine the test suite on the project I just published. Was it trivial? No, I'd say the whole project did take me a couple days.
https://github.com/qarl/arcade-js
You have a nice day.
Changing an executable's signature by inserting a single extra printf() is well within that spec.
I will note you used the term "harness" which - while terms around LLM tooling is still inconsistently defined - in my experience generally pertains to agentic automations: e.g. LLM CI integrations, etc. Rather than interactive local tooling like OpenCode. So maybe you're referring to that (though even then I still can't think of examples)
You should look into "testing". It's when you run the code you just wrote to make sure it works.
For example, in LLM harnesses, it's used to ensure the produced code has the desired properties. It is the key element needed to allow agents to continue to work until they have succeeded.
Anthropic's harness Claude Code:
https://code.claude.com/docs/en/best-practices — "Claude does the work, runs the check, reads the result, and iterates"
https://www-cdn.anthropic.com/58284b19e702b49db9302d5b6f135a... — "autonomous loops where Claude writes code, runs tests, and iterates continuously"
https://www.anthropic.com/research/long-running-Claude — "Run pytest tests/ -x -q before every commit"
https://platform.claude.com/docs/en/agents-and-tools/tool-us... — "Claude edits a file with one tool and requests the command that runs it"
https://platform.claude.com/docs/en/agents-and-tools/tool-us... — "writes Python with the file operations sub-tool and runs it with a Bash command"
OpenAI's harness Codex:
https://openai.com/index/introducing-codex/ — "can iteratively run tests until it receives a passing result"
https://openai.com/index/introducing-upgrades-to-codex/ — "iterating on its implementation, fixing test failures, and ultimately delivering a successful implementation"
Aider harness:
https://aider.chat/ — "Automatically lint and test your code every time aider makes changes"
https://aider.chat/docs/usage/lint-test.html — "run your test suite after each time the AI edits your code"
Devin harness:
https://cognition.com/blog/introducing-devin — "Devin writes and debugs code to run a computer vision model"
https://cognition.com/blog/introducing-devin-2-2 — "Devin runs through your app and sends back screen recordings"
https://cognition.com/blog — "Devin now builds, runs, and tests natively in Windows VMs"
SWE-bench harness:
https://www.vals.ai/benchmarks/swebench — "running unit tests against the generated patch"
Copilot:
https://github.blog/changelog/2025-05-19-github-copilot-codi... — "makes changes, and even validates its work with your tests and linter"
https://docs.github.com/copilot/concepts/agents/coding-agent... — "how to build, test and validate its changes"
https://docs.github.com/copilot/how-tos/agents/copilot-codin... — "If Copilot is able to build, test and validate its changes"
https://github.blog/ai-and-ml/github-copilot/github-copilot-... — "coding agent can independently write, run, and test code"
For ad hoc task/investigation-oriented fully interactive agent UIs the requirements are more complex & there's all a lot of advantages to running locally on host, but e.g. for builds & testing in that context there's less of a requirement for the LLM to have full control over every execution given user presence. Basically the use-case being discussed here is LLMs-as-assistance/pair programmers/active digital colleagues, rather than fully automated autonomous harnesses (legit but separate use-case).
All of the harnesses I cited above run locally and default to testing the code they generate, despite your inability to conceive of it.
It is very obviously the primary use case: automated development interleaved with investigation. Because you need to do both, at the same time, iteratively.
Please don't make me paste those URLs again: they demonstrate exactly what you say does not happen.
For example, I recently ran opencode via sandbox-exec & naively granted the sandbox access to the aws cli. First attempt to exec it failed because I hadn't granted the sandbox access to the credential file in ~/.aws. This took 2 seconds to resolve but effectively highlights how utterly useless the tree-sitter string-parsing they're doing is. It's so concerning because implementing tree-sitter for that is non-trivial to the point that any competent dev should surely realise quickly while implementing it that this avenue is utterly useless. Yet every high-profile agent cli has taken this approach.
OpenCode's allowlists are not there for security. They exist for LLM behavior guidance.
I don't honestly believe that the allowlist isn't (naively) intended to be there for security. It's certainly not a very useful ux for providing LLM guidance: prompts, memories & AGENTS.md already provide an avenue for this & having it in a formalised, structured format isn't conducive to LLM guidance. The implementation brings in a lot of dependencies (tree-sitter) & contains enough complex targeted string parsing that's definitely superfluous for something intended to be fed to an LLM as guidance. Perhaps most importantly - the LLM behaviour on encountering limits of the allowlist is neither intuitive nor consistent enough to be considered reliably guiding (& system prompt doesn't do anything to mitigate this).
> I don't expect them to be built into my LLM harness because I value modular software composition
I value software modularity, in particular where software architecture is concerned, but I wouldn't go as far as being prescriptive about the unix philosophy. Direct integration does have its pros, & most of the cons associated with it in practice are specific to bad architecture (or black box software). For example Claude cli does integrate sandbox-exec internally, but it does do in a closed-source inaccessible way that negates its value. I am confident it can be done well though, even if I'm somewhat less confident that it ever will be.
But maybe some people think it's not obvious, and point it out because they think they're clever?
I suppose that's possible.
The downside to democratizing code creation is... it puts it in the hands of non-developers.
F.ex. a team I work with asking OpenClaw "What is SRE?"
I'm beginning to think that the true issue here is that people who dislike AI are largely ignorant of the current state. Because willful ignorance.
I say that because I repeatedly see people making extremely silly statements that they really should know better about. But for some reason they don't.
Obviously I could be wrong. Time will tell.
They're being bought as a hardware solution, not a sandbox solution.
As proof, look at all the people wiring up their personal emails, etc. as soon as they turn them on.
What is it about THIS software, unlike any dev software to come before it, that pushes people to buy new small computers?
Why do you think?
And because it lets them create code without knowing how to code.
You know, I can't prove that the Mac mini problem is due to needing to sandbox agents. All I can offer is my anecdotal experience - and that of everyone I know.
I love that I'm now a 50 year old hipster. This is a wonderful conversation.
If you had any experience with using LLM harnesses, you would be aware that despite instructions (in prompts, AGENTS.md, etc.) the agents will sometimes ignore those instructions.
One solution to remind the agents is to explicitly disallow their instruction-violating attempts.
This is how allowlists are used to guide agent behavior.
You should try it sometime before you speak authoritatively about it further.