Desktop app stuck on "Connecting…" after brief network drop — remote session never auto-reconnects

Summary

When using the Claude Code desktop app against a remote workspace, a brief local network blip permanently wedges the session: the top-bar status sticks on "• Connecting…" indefinitely and never recovers, even after the network path is fully restored. The only fix is to restart the session / relaunch the app.

Environment

• Claude Code desktop app, macOS (Darwin 25.6.0), model Opus 4.8
• Remote workspace: a git worktree on a remote Mac mini, reached over Tailscale → SSH
• Laptop has occasional brief WiFi blips

Steps to reproduce

1. Open a remote-workspace session in the desktop app (connection healthy).
2. Briefly drop the laptop's network (a few seconds), then let it recover.
3. Observe the top-bar status.

Expected

The app detects the restored path and reconnects automatically (or offers a manual reconnect control).

Actual

Status stays on "• Connecting…" forever. It does not self-heal. Only restarting the session / relaunching the app restores it.

Evidence the network path is healthy while the app is stuck (captured during a wedge)

• ssh <mini-host> → returns immediately: SSH_OK, hostname resolves.
• tailscale status → mini shows active with healthy traffic (rx in the hundreds of MB).
• OpenAI Codex CLI, same machine/network, reconnects fine in the identical scenario — so this is specific to Claude Code's connection handling, not the network.
• Reproduced multiple times across a session; the path was proven healthy each occurrence.

Impact

Every brief network blip requires a manual restart. Competing tools (Codex) recover transparently because their session state is server-side.

Requests

1. Auto-reconnect the remote session when the network path is restored.
2. Failing that, expose a manual reconnect control (the app currently has no way to re-establish a wedged connection short of a full restart).