Desktop SSH remote: session stuck in permanent 'Unauthorized request: method=server.ping' reconnect loop; existing sessions unrecoverable even after full ~/.claude/remote wipe

Summary

After the desktop app auto-updated to 1.17377.2 (macOS), an existing remote SSH session can never reconnect. The app enters a permanent retry loop (~every 5s): each attempt spawns a fresh server --serve on the remote host with a fresh token file, then the ping is rejected with Unauthorized request: method=server.ping, the app tears down and retries. Related to #54179 (token collision between concurrent sessions), but this report adds: once a session's token has been invalidated, it is permanently unrecoverable — no amount of state cleanup on the remote host fixes it, and the desktop app never re-mints a token for an existing session.

Environment

• Desktop app: 1.17377.2 (macOS, Darwin 25.5.0, Apple Silicon), bundled CLI 2.1.197
• Remote host: Ubuntu (kernel 6.17.0-35-generic), reached over Tailscale (<host>.ts.net)
• Remote server binary deployed by the app: ~/.claude/remote/srv/d20a77da22b7d4822f758654b226299ad7021c22/server

Symptom (user-visible)

Lost connection to shawn@<host>.ts.net — The SSH connection dropped and auto-reconnect didn't succeed. Your session is preserved on the remote host — resend your message to reconnect and pick up where you left off.

Resending the message never reconnects.

Diagnostics on the remote host

~/.claude/remote/run/<id>/remote-server.log during a reconnect attempt:

Claude remote server listening on /home/<user>/.claude/remote/run/e0e2fc49/rpc.sock
21:23:06 [Server] New connection from: @
21:23:14 [Server] New connection from: @
21:23:14 [Server] Unauthorized request: method=server.ping, id=0
21:23:14 [Server] Connection closed: @
21:23:14 [Server] New connection from: @
Claude remote server listening on ... rpc.sock   <-- server respawned, new token file
21:23:15 [Server] New connection from: @
... loops forever, ~5s period

Each retry launches server --serve --token-file .../token.<new-random> — so a fresh token file is written every attempt, yet the subsequent server.ping is still Unauthorized. The client appears to replay a token cached in its persisted session state on the Mac rather than the one it just provisioned.

Aggravating factor: same machine registered as two hosts

~/Library/Application Support/Claude/ssh_configs.json contained two entries pointing at the same physical machine (one .local mDNS name, one Tailscale .ts.net name). Sessions under both entries auto-reconnect in the background and fight over the single ~/.claude/remote/run/<id>/rpc.sock, mutually invalidating tokens exactly as described in #54179. sshd logs show the connection storms alternating between the two source routes.

Side effect worth noting: the retry storm (several SSH connections per attempt × 2 host entries × ~5s retries) trips sshd's default MaxStartups 10:30:100 — sshd logged beginning MaxStartups throttling ... 38 connections dropped. So on stock sshd configs the bug also DoSes the SSH port, which masks the real cause and makes reconnect failures look network-related.

What was tried (none recovered the existing session)

1. Rebooting the remote host — no effect.
2. Raising MaxStartups 100:30:200 — fixed the sshd throttling (auth now always succeeds) but handshake still Unauthorized.
3. pkill -f .claude/remote/srv && rm -rf ~/.claude/remote/run — fresh run dir + token recreated, still Unauthorized.
4. Full wipe including binaries: rm -rf ~/.claude/remote/srv ~/.claude/remote/run — app redeployed the same binary hash d20a77da..., still Unauthorized.
5. Full app quit (⌘Q) + relaunch — no effect.
6. Removed the duplicate host entry from ssh_configs.json, single host + single session — new sessions connect fine, but the pre-existing conversation still loops forever.

Expected

• On reconnect, if the server rejects the stored token, the client should re-run the provisioning handshake (it already writes a fresh token file and owns the server process — it should use it), instead of retrying a dead credential indefinitely.
• Concurrent sessions to one host should share the server/token rather than invalidating each other (#54179).
• The UI claims "Your session is preserved on the remote host — resend your message to reconnect", which is misleading when the token can never revalidate.

Impact

Existing remote-session conversations become permanently inaccessible from the desktop app after any token collision (multiple sessions, or duplicate host entries pointing at one machine). Context is only recoverable by manually resuming the transcript jsonl from ~/.claude/projects/<project>/ via the CLI on the remote host.