[lucideer]

This is very doable - it's a shell you're creating within the cli so you have a lot of control over the environment. If you look at tools like sandbox-exec & apparmor, they specifically target binaries, not string input. E.g. if I write a bash script & put it in my path, OpenCode's allowlists aren't looking at the commands my bash script is exec-ing, nor monitoring subshells it creates. A proper sandbox has full context of the execution chain. Not only that, it's potentially much more powerful & expressive in that you can allowlist indirect filesystem access from commands run.

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.

[qarl2]

Yes, I am aware that sandboxing technology exists. I use them. I don't expect them to be built into my LLM harness because I value modular software composition - and sandboxing should be provided by a product that specializes in that area.

OpenCode's allowlists are not there for security. They exist for LLM behavior guidance.

[lucideer]

> allowlists are not there for security

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.

[qarl2]

Well - pretty much everyone knows it's lousy security, because you know, it's pretty obvious.

But maybe some people think it's not obvious, and point it out because they think they're clever?

I suppose that's possible.

[ethbr1]

I think you're vastly overestimating the technical competence and background of most people using agentic coding harnesses today.

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?"

[qarl2]

Well - maybe. But as I understand it - you can't buy Mac minis right now because agentic coders are buying all of them, so they can properly sandbox their agents. Which means a LOT of people know they need to sandbox their agents.

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.

[ethbr1]

Mac Minis are out of stock because they're the cheapest entry point to reasonably capable local agents (read: 64+GB of GPU accessible RAM), which TikTok is all about.

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.

[qarl2]

> 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.

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.