claude-code - 💡(How to fix) Fix [BUG] Desktop SSH session hangs 3-10 min on "Starting session…" after network-interface change (utun flap) [2 comments, 3 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When starting a new SSH session from the Claude Code desktop app (macOS), the session hangs on "Démarrage de la session…" / "Starting session…" for 3 to 10 minutes, with no error shown. Sometimes the first attempt returns "connection closed", then subsequent attempts stay frozen. The session eventually connects on its own without any user action.

Investigation of ~/Library/Logs/Claude/ssh.log shows the root cause is internal to the desktop app:

1. The app logs [remote] network-interface change detected; probing SSH controllers very frequently (82 times in a single day in my case).
2. Each event triggers a "probing" operation that serializes and blocks new process spawns for several minutes.
3. While that probe is in flight, any new session start silently queues — main.log shows Starting local session ... and [SSH] Using remote spawn function ..., but NOTHING is ever written to ssh.log (no Setting up remote server, no SSH2Connection).
4. When the probe finally resolves, the spawn runs instantly (0s), reusing the already-healthy remote daemon.

Root trigger on my machine: utun6 / utun7 (Apple CoreDevice tunnels used by Xcode + iOS Simulator, MTU 16000, ULA fd6c:: / fd71::) flap constantly as Xcode/CoreDeviceService resets TCP connections. Each flap → nw_path_change → "network-interface change detected" in ssh.log → probing lock → spawn blocked.

Workaround confirmed working: quitting Xcode + Simulator + CoreDeviceService removes utun6/utun7, event frequency drops ~20×, sessions start in 3-5s.

Two bugs in one:

• Bug A: the app probes SSH controllers on any interface change, even non-default, non-routed interfaces unrelated to the VPS connection (utun6/utun7 are CoreDevice-only, they have no route to the VPS at all).
• Bug B: the "probing" operation holds a lock that blocks new spawns for minutes, with no timeout/backoff visible to the user and no log line indicating the wait.

Also visible in logs: Reattach failed: auth error on almost every reconnect — the app cannot reattach to the existing remote daemon and always starts a fresh one, abandoning in-flight processes. Likely a third related bug.

What Should Happen?

1. The app should only probe/reset SSH controllers when the default route or the specific interface used for the active SSH connection changes — not on arbitrary utun flaps from unrelated macOS subsystems (Xcode, CoreDevice, iOS Simulator, iCloud Private Relay, etc.).
2. Probing should not block new spawns indefinitely. If a probe is in progress when a session start is requested, the user should see a status message ("Checking connection…") and the operation should timeout in a few seconds, not several minutes.
3. Reattach to an existing healthy remote daemon should succeed instead of always falling back to No reusable server; starting fresh.

Error Messages/Logs

Excerpt from ~/Library/Logs/Claude/ssh.log showing the pattern:

2026-04-24 08:27:48 [info] [remote] network-interface change detected; probing SSH controllers
2026-04-24 08:27:49 [info] [RemoteRPCClient] Stream closed
2026-04-24 08:27:49 [warn] [RemoteServerController] RPC stream closed
2026-04-24 08:27:49 [warn] [RemoteServerController] Ping failed, marking connection dead: Connection closed
2026-04-24 08:27:50 [info] [BinaryDeployment] Reattach failed: auth error
2026-04-24 08:27:50 [info] [BinaryDeployment] No reusable server; starting fresh
2026-04-24 08:27:55 [warn] [RemoteServerController] Server restarted; abandoning 2 tracked process(es)
2026-04-24 08:27:55 [warn] [RemoteProcess:...] Abandoning (transport lost, no reattach)

Correlated system event on utun7 (CoreDeviceService + Xcode) at the same second:

2026-04-24 08:28:15.511 CoreDeviceService[78180] [C122 IPv6#...54036 failed socket-flow (interface: utun7, ...)] event: flow:disconnect, error Connection reset by peer
2026-04-24 08:28:15.522 kernel tcp_connection_summary ... interface: utun7 ... process: CoreDeviceService

Then the hanging case — main.log shows the session start, ssh.log shows NOTHING for 3min40s:

main.log:
2026-04-24 08:40:52 [info] LocalSessions.testSSHConnection: host=[email protected]
2026-04-24 08:40:59 [info] Starting local session local_dc8b9a1a-...
2026-04-24 08:40:59 [info] [SSH] Using remote spawn function for session ... on [email protected] (cli: /home/julien/.claude/remote/ccd-cli/2.1.111)
(no further SSH-related entries)

ssh.log during the same window:
2026-04-24 08:40:03 [info] [remote] network-interface change detected; probing SSH controllers
(nothing for 247 seconds)
2026-04-24 08:44:10 [info] [RemoteProcess:cb258694-...] Spawn confirmed

Daily count of network-interface change events with Xcode running: 82
After quitting Xcode + Simulator + CoreDeviceService: ~4 per 6 minutes, and no more spawn blocks.

Steps to Reproduce

1. On macOS, have Xcode + iOS Simulator running (they create utun6 / utun7 CoreDevice tunnels that flap frequently).
2. In Claude Code desktop app, connect to a remote VPS via SSH.
3. Start a new session in that remote workspace.
4. Observe: "Démarrage de la session…" stays frozen for 3–10 minutes with no feedback.
5. In ~/Library/Logs/Claude/ssh.log you'll see repeated [remote] network-interface change detected; probing SSH controllers, then a long silence, then a sudden Spawn confirmed with no user action.
6. Mitigation: quit Xcode, Simulator and sudo killall CoreDeviceService. Event frequency collapses and sessions start in seconds.

Note: reproducing does not strictly require Xcode — any macOS tool that causes frequent utun flaps (VPN reconnects, Tailscale DERP changes, iCloud Private Relay, Docker/OrbStack, etc.) likely triggers the same symptom. Xcode just happens to generate a lot of flaps.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

1.3883 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment:

• macOS 26.3.1 arm64
• Wi-Fi via Starlink
• Active network extensions: Tailscale (utun4), iCloud Private Relay (utun0/1/2/3/5), OpenVPN agent installed, Little Snitch (permissive, no denies in logs for Claude).
• Two VPSes tested (both OVH Debian, identical config). Issue affects both — confirmed NOT a server-side issue.

Non-issues ruled out during investigation (to save your triage time):

• ✅ API connectivity to api.anthropic.com is fine (163ms, 404 expected on bare GET)
• ✅ Little Snitch is NOT blocking (verified via unified log, no denies)
• ✅ VPS claude-ssh daemon is running and healthy
• ✅ Direct ssh vps && claude from Terminal.app works instantly — so the remote binary itself is fine
• ✅ Tailscale (utun4) is stable during the incident, not the trigger
• ✅ ~/.claude/remote/ on the VPS is intact and up-to-date

Related: looks like a duplicate / variant of #39123 (marked as duplicate of #37967), but neither issue captures the "probing SSH controllers lock blocks spawns for minutes" aspect I'm seeing, which is the actual user-visible symptom.

Happy to provide full ssh.log / main.log / unified log excerpts if useful.