[JeremyNT]

Background: I use OpenCode to do this.

Just tell it to use ssh from the shell. From there you can give it extra context to describe the target (if you know/care about it), or just let it loose and if the environment doesn't have what it expects it will "figure something out" - just the same as with your local env.

If there's some least common denominator you know about e.g. python it can streamline things if you tell it to just use that for everything.

[cyanydeez]

I don't think you understand. I'm well aware it can run whatever command on bash. You're taking a significant risk asking it to do what it's doing via ssh, because it could easily forget that it's suppose to be doing ssh and do whatever locally.

The point is: opencode should have a specific deterministic tool like https://www.npmjs.com/package/node-ssh where commands can only be run; the environment can only be the remote; etc.

The last thing I would want is for it to suddenly forget it's suppose to be running commands as ssh and does something local.

[JeremyNT]

In practice I just don't think this is a real problem, or at least not one I've seen.

I do something like this a lot with local VMs managed through Incus (so not literally invoking ssh but the exact same pattern) and they don't "mess up" in that particular way. If they ever did they figured it out immediately and I didn't even make note of it happening.

I guess to sum up my feelings on it: if you don't think the tool is reliable enough to correctly use ssh to execute remote commands, you probably shouldn't be trusting it to run remote commands in the first place.

[cyanydeez]

You're still ignoring the crux of the difference in _risk_. Say the risk of `rm -rf /` for any given model is 1%. That is, the probabilty, that it'll just absolutely saveagly destroy the system you're working on. We know it's lower than that, because millions of tokens per day are generated and we only get a few of these "production database was wiped" news items.

There difference is still: If that risk-reward is to be recieved, you can't tell me you'd rather have it run locally than on some system you're managing. Because POV, you're the one responsible and if a coding tool _takes out your system_, you no longer have any means to fix the problem.

So, maybe the risk-reward is _technically_ equal, but only if the operator of the coding tool continues to operate regardless of what commands it's issuing. That's not the case if you're just saying "hey guy, use ssh for all your commands"