SSH remote: a client on a different version kills the running managed server on every reconnect (and downgrades the DB) #29416

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Desktop app — SSH remote environments (packages/ssh/src/tunnel.ts)

Steps to reproduce

1. Connect to one Linux host over SSH from two T3 desktop clients on different releases (e.g. 0.1.5 and 0.1.6), or from one client that changes version. Leave the remote on the default managed server (no t3 service install).
2. Start a long agent turn on the remote that runs a background shell job (test suite, build).
3. Reconnect from the other client, or let a laptop's connection drop and reconnect.

Expected behavior

Reconnecting reuses the healthy running server ("Reconnect owns the local tunnel, not the lifetime of an already running server"). A version difference between clients doesn't stop agent work, and never moves the server to an older release than the one that migrated the database.

Actual behavior

REMOTE_LAUNCH_SCRIPT rewrites ~/.t3/ssh-launch/<key>/run-t3.sh with the connecting client's T3_ARCHIVE_VERSION. The script changes, so RUNNER_CHANGED=1 and the script kills the running server and starts the client's version. With clients on two versions, every switch restarts the server:

• 32 server starts on one host in ~2.6 days. The log alternates between runtime/versions/0.1.6/t3 and runtime/versions/0.1.5/t3.
• Each restart terminalizes runs and cancels their background work. Threads get the "the T3 server restarted, and this background work was cancelled" note, and continueThreadsAfterServerUpdate resumes them. A test run or build in progress is lost, and after 3 quick restarts Not continuing a run restarted too many times in a row.
• After a 0.1.6 → 0.1.5 switch, the older server boots on a DB already migrated by 0.1.6: Database migration history diverges from this build; recorded migration ids are skipped (73–76 unknown to this build). The older server then runs Removed unused t3 runtimes { versions: ['0.1.6'] }, which deletes the newer runtime the other client needs and forces a re-download on its next connect.
• Separately, closing the tunnel also stops the managed server (stopRemoteServer in the tunnel scope finalizer), so quitting the app on the laptop kills agent work on the remote.

Workaround: t3 service install on the remote. The launcher then adopts the service as external and never kills it.

Impact

Long agent work on a remote host dies whenever any client reconnects with a different version, or closes. The data dir can also be served by an older release than its schema, and each client's runtime gets deleted by the other.

Version or commit

Clients 0.1.5 and 0.1.6; remote runtimes 0.1.5 and 0.1.6 (archive mode).

Environment

Remote: Ubuntu, x64, systemd, root user, linger off (default). Clients: T3 desktop over SSH.

Suggestions (for maintainers to judge)

• When a newer-or-equal server is already running and healthy, don't replace it with an older client's runtime. Refuse or warn (mirroring --allow-downgrade) instead of killing it.
• Ask before replacing a server that has active runs, or defer the replacement until it's idle.
• Suggest t3 service install when an SSH remote keeps getting reconnected from several clients.