SSH-bridged session revive hangs indefinitely when the remote claude is unauthenticated (locked login keychain)

Summary

When resuming/reviving a Code session that is bridged over SSH to a remote Mac, the app spins indefinitely with no error if the remote claude cannot authenticate. The underlying cause is that a key-based SSH session starts with the macOS login keychain locked (SSH key-auth doesn't unlock it), so the remote claude — which stores its Claude Code-credentials in that keychain — comes up "Not logged in." The bridge then waits forever instead of surfacing the auth failure.

Environment

• Claude desktop app (macOS) with a Code session bridged over SSH to another Mac.
• Remote Mac is logged into the GUI; login keychain is set no-timeout and is unlocked in the GUI session, but a fresh SSH (key-auth) session sees it as locked.

Repro

1. Start a Code session bridged over SSH to a remote Mac; use it for a while.
2. Later, from the app, unarchive that session and type a message.
3. The app spins indefinitely — no response, no error.

What's actually happening

• In a manual SSH shell on the same remote Mac, claude --resume shows "Not logged in · Run /login", confirming the remote claude cannot read its credentials over SSH.
• Running security unlock-keychain login.keychain-db in that SSH session, then claude --resume, works — confirming it's the locked login keychain.

Expected

• The app should surface a clear error (e.g. "remote session not authenticated" / "backend unavailable") and ideally offer to re-authenticate, instead of spinning with no feedback.
• Consider falling back to ~/.claude/.credentials.json when the keychain is inaccessible, and/or documenting the SSH keychain-unlock requirement for remote/bridged sessions.

Impact

Reviving remote/SSH-bridged sessions from the app is unreliable; the only working path is a manual security unlock-keychain + claude --resume in a terminal, which is non-obvious.