Remote Control: stale bridge environment after long uptime causes "Session creation failed" until re-registered from a different machine

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (related: #29219, but different trigger)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

iOS Claude app shows Session creation failed — see debug log for Remote Control sessions, while local claude-remote@* systemd services report healthy state. Cannot create new Remote Control sessions against the affected environments until a fresh Remote Control session is registered from a different machine, which then restores functionality across all environments.

Environment

• Claude Code version: 2.1.138
• OS: Ubuntu 24.04 (miniPC, systemd user services); also Windows 11 (registration source)
• Plan: Max
• Auth: claude.ai OAuth (no ANTHROPIC_API_KEY set)

Local state at time of failure

• claude-remote@agentic-orchestrator.service and claude-remote@coding-ui-spike.service: both active (running)
• Worker process uptime: 4d 19h and 3d 19h at time of failure
• Process state: Ssl, ep_poll, low CPU — normal idle
• TCP: ESTABLISHED to 160.79.104.10:443 for both
• Last journal entry: Connected, Capacity 0/4
• 24h scan for error|fail|disconnect|restart|exit in journalctl: zero hits
• Session debug log: only one non-fatal Lock acquisition failed ... expected in multi-process scenarios

In other words: every local signal says the bridge is healthy, but the server rejects session creation.

Possible correlation

status.claude.com shows four incidents on May 8, 2026 (Sonnet 4.6, Opus 4.7, file operations, cross-model errors). I suspect long-lived bridge environments survived these incidents with stale server-side registration while local TCP/process state remained intact.

Reproduction

1. Start claude-remote@<project> as a long-running systemd user service
2. Leave running for several days, ideally spanning a backend incident window
3. Attempt to create a new Remote Control session from iOS app → Session creation failed — see debug log
4. Local logs show no errors

What unstuck it

Starting a Remote Control session on a separate machine (Windows PC, same account). Immediately after that registration succeeded, the previously-failing iOS session creation against the miniPC environments started working again. No restart of the miniPC services was needed.

Hypothesis

Bridge environment registrations can become server-side zombies — local socket and process look fine, but the server's session-creation path rejects against that environment. Something about a fresh registration from a different machine (LRU eviction? account-level re-handshake?) restores consistency across all the account's registered environments.

Difference from #29219: no rate limit involved here, and the fix wasn't a local restart — it was a registration from a different machine, which suggests the issue is account-level bridge environment lifecycle rather than per-process state.

Suggested mitigation for users

Cycle long-running claude-remote@* services daily via systemd RuntimeMaxSec=86400.