# \[Bug\]: SSH environment stays reconnecting after desktop update reuses an older remote server · Issue \#16984 · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/16984)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

State: completed

Priority: 0

## Description

[Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/16984)

---

### Before submitting

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

### Area

apps/desktop

### Steps to reproduce

This is the sequence observed on my setup; I haven't reproduced it from a clean installation.

1. Connect to an SSH environment using `0.0.46-nightly.20261004.2652`.
2. Leave the remote T3 server running.
3. Update the desktop to `0.0.46-nightly.20261007.2787`.
4. Open the existing SSH environment.

### Expected behavior

The existing environment reconnects. If the remote server needs an update, T3 handles that safely or explains what action is required.

### Actual behavior

The environment stayed on “<environment name> is reconnecting” (host name redacted). SSH and the forwarded HTTP server were reachable, but the desktop's pairing-token exchange returned HTTP 500.

The October 7 runtime was already installed remotely, while the process serving the SSH environment was still running the October 4 build. The UI didn't explain the authentication failure.

### Impact

Blocks work completely in the affected remote environment.

### Version or commit

Desktop: `0.0.46-nightly.20261007.2787`

Remote server still running: `0.0.46-nightly.20261004.2652`

### Environment

Linux desktop and Linux SSH server, SSH over Tailscale.

### Logs or stack traces

```text
DesktopSshEnvironmentRequestError:
[ssh_http:500] SSH remote API request failed during bootstrap-bearer-session.

Remote server:
reason: 'access_token_issuance_failed'
cause:
  ServerAuthBootstrapCredentialValidationError
  BootstrapCredentialConsumeAvailableError
```

### Workaround

After backing up the database and checking for active provider sessions, I restarted only the remote T3 server using `0.0.46-nightly.20261007.2787`, keeping the same base directory and port.

The desktop then reconnected successfully. Live RPC requests succeeded, the reconnecting message disappeared, and the existing chat history remained visible.

This points to reuse of the older server as the trigger, though I haven't isolated the underlying token-consumption failure.

### Related reports

- #2665 also concerns SSH bearer bootstrap, but reports a Windows response-decoding failure on version 0.0.23 rather than the remote token-consumption error observed here.
- #16477 concerns SSH server reuse and restart behavior, but reports reconnects killing a busy server. Any update handling should preserve active remote work.