That's a pretty oddly narrow & specific definition of what LLM harnesses are for & it certainly doesn't match my experience. In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact. Sure many devs might ask it to for convenience of not having to spend 3 seconds typing & running the command themselves but I can't see it ever being explicitly necessary.
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)
> In fact I'm genuinely struggling to think of any scenario where an agent CLI would need to execute a build artifact.
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.
You're definitely referring to fully autonomous harnesses as I suspected - these are generally quite well suited to VM deployment (quite possibly in the cloud) if you're concerned with sandboxing as they don't typically run into the same challenges as an interactive LLM UI.
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.
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)