desktop: SSH mismatch reports V1 for a V2 server; upgrade action is hard to discover

Description

OpenCode Desktop 2.2.1 reported that an SSH-managed remote server was running V1 and needed upgrading to V2, although the installed binary and running service were both 2.2.0.

The remote /api/info response confirmed "version":"2.2.0", with a PID matching the running opencode serve --service process. Restarting the desktop app did not resolve the error.

Response from /api/info (formatted; hostname and PID anonymized):

{
  "version": "2.2.0",
  "pid": 12345,
  "hostname": "remote-host",
  "urls": [
    "http://127.0.0.1:49374"
  ],
  "paths": {
    "tmp": "/tmp/opencode"
  },
  "capabilities": {
    "persistentPty": true
  }
}

The running process also used the desktop-managed 2.2.0 binary (PID and home-directory username anonymized; the PID corresponds to the API response above):

$ ps -ww -u "$(id -un)" -o pid=,args= | grep '[o]pencode'
12345 /home/remote-user/.opencode/desktop-ssh/2.2.0/opencode serve --service

The connection worked after opening Settings → Servers → ⋯ → Connect and selecting Update and reconnect.

Expected behavior

• Show the actual remote version and explain the required desktop/server version match.
• If the version cannot be determined, show unknown, not V1.
• Offer Update and reconnect directly from the home-page server list or connection error, rather than requiring users to discover the same server under Settings.

Implementation observations

Inspection of the installed 2.2.1 desktop bundle found:

• SSH bootstrap checks exact version equality.
• The session error panel uses health?.version ?? '1', which can present missing health information as a V1 diagnosis.

This appears relevant to the misleading message, but the complete trigger has not been established.

Plugins

Not independently verified; no plugin-related trigger identified.

OpenCode version

• Desktop: 2.2.1
• SSH-managed remote service: 2.2.0 before the successful update.

Steps to reproduce

1. Have an SSH-managed remote service running 2.2.0.
2. Use Desktop 2.2.1 and open the remote server/session from the home page.
3. Observe an incompatibility error indicating V1 / requiring V2, despite the remote API reporting 2.2.0.
4. Restart Desktop; the error persists.
5. Open Settings → Servers → ⋯ → Connect → Update and reconnect.
6. The update completes and the connection succeeds.

Operating System

• Client: macOS (Apple silicon).
• Remote: Linux; distribution/version not collected.

Terminal

Not applicable: desktop SSH connection.