desktop: keep remote SSH connections working across patch updates #60665

Summary

Client updates repeatedly interrupt access to SSH-managed remote instances until each instance is manually upgraded. In my usage, this has become an almost daily interruption.

With multiple remote servers, updating OpenCode means visiting Settings → Servers and upgrading connections individually before resuming work. Remote access should not require this recurring maintenance after routine client updates.

Current behavior

1. Configure multiple working SSH-managed remote instances.
2. Update the local OpenCode client while the remote instances remain on the previous version.
3. Attempt to open those connections from the homepage.
4. Connections stop working until the remote instances are upgraded.
5. Navigate to Settings → Servers and update/reconnect each instance individually.

Manually upgrading restores access, but the process repeats with subsequent releases.

Requested improvements

1. Preserve compatibility across patch releases

A client on 2.2.3 should ordinarily be able to connect to a remote instance on 2.2.2. This is an example of the expected compatibility policy, not a separately verified failing version pair.

Please define and document a client/server compatibility window rather than requiring exact version equality for routine patch updates. Capability negotiation could allow newer functionality to be unavailable without blocking the entire connection.

If a particular update genuinely requires a newer remote version, explain the specific incompatibility and minimum supported version.

2. Automate required remote upgrades

When an upgrade really is necessary, OpenCode should handle upgrading and reconnecting SSH-managed instances as part of the connection workflow, with user consent or an opt-in automatic-update policy.

For users managing multiple instances, an Update all incompatible servers action would avoid repeating the same operation server by server.

The workflow should show progress and actionable failures, and avoid silently interrupting active remote work.

3. Allow recovery directly from the homepage

The homepage server entry and connection error should offer Update and reconnect directly, alongside the local and remote versions and the reason an upgrade is required.

Users should not need to navigate to Settings → Servers to repair the connection they just tried to open.

Why this matters

Frequent releases are welcome, but routine updates should not turn every configured remote connection into a maintenance task. The interruption grows with the number of remote instances and makes an otherwise useful workflow feel unreliable.

The preferred outcome is: compatible versions keep working; genuinely necessary upgrades are handled with minimal intervention; and any recovery action is available where the failure appears.

Related issue

• desktop: SSH mismatch reports V1 for a V2 server; upgrade action is hard to discover #60283 — Documents a Desktop 2.2.1 / remote 2.2.0 failure, misleading version messaging, and the buried upgrade action. This request focuses on the broader compatibility policy and upgrade experience.