Remote SSH sessions: 'Reattach failed: auth error' after CLI version bump abandons in-flight session; stale helper servers accumulate

Open 💬 0 comments Opened Jul 1, 2026 by HappyEureka

Summary

Remote SSH sessions (desktop app -> Linux host) drop frequently with "Lost connection... auto-reconnect didn't succeed". The app repeatedly fails to reattach to its still-running remote helper server with Reattach failed: auth error, then starts a fresh server and abandons the in-flight session. Orphaned helper servers also accumulate on the host and are never reaped. Started immediately after a Claude update; plain terminal SSH to the same host is completely stable.

Environment

  • Claude desktop app version: 1.17377.1
  • Remote helper CLI on host: 2.1.197
  • Host: Linux (x86_64), shared multi-user box, reached over Tailscale
  • Network verified healthy: direct Tailscale path (not DERP), 0% packet loss, low latency; SSH login succeeds every time (USERAUTH_SUCCESS in logs)
  • Plain ssh <host> from a terminal: rock solid, never drops

Symptom

Remote sessions blip and cannot recover; UI shows "Lost connection... auto-reconnect didn't succeed. Your session is preserved on the remote host - resend your message to reconnect." Reconnect often fails repeatedly.

Log evidence

From ~/Library/Logs/Claude/ssh.log:

[SSH2Connection] Connected to <user>@<host>:22
[BinaryDeployment] Server binary up to date (...), skipping upload
[BinaryDeployment] Reattach failed: auth error
[BinaryDeployment] No reusable server; starting fresh
[RemoteServerController] Server restarted; abandoning 1 tracked process(es)
[RemoteProcess:...] Abandoning (transport lost, no reattach)

From ~/Library/Logs/Claude/main.log:

Session local_... query error after SSH transport drop (Nms ago) - treating as dormant, not crash

ps on the host showed, under the single user account:

  • one orphaned .../server --serve ... --token-file .../run/<idA>/token.<X> process ~4h25m old
  • several stacked .../server --bridge --socket .../run/<idB>/rpc.sock processes (57m, 22m, 5m, seconds old)
  • mismatched token files across multiple run/<id>/ dirs

So on reconnect the app cannot match a token to any reusable server, logs auth error, and starts fresh -- discarding the live session.

Likely cause

The remote helper CLI was bumped by the update. Reattach to a still-running helper appears to break across the version bump (token/handshake mismatch), and stale helpers from before the update linger and poison reconnect selection.

Expected behavior

  1. Reattach should succeed against a live helper across CLI version bumps, or fail over without killing the in-flight session.
  2. Orphaned/stale helper servers should be reaped (or ignored) rather than accumulating and causing auth error on reattach.

Workaround that fixes it

  1. Fully quit the desktop app (so it stops respawning helpers).
  2. On the host: pkill -9 -f "<user>/.claude/remote/srv/" then rm -rf ~/.claude/remote/run/*.
  3. Relaunch the app and reopen the remote session -> one clean helper with matching tokens; drops stop.

View original on GitHub ↗