Remote control WebSocket disconnects every ~25 minutes due to server-side connection lifetime limit

Problem

The remote control WebSocket connection to wss://api.anthropic.com/v1/session_ingress/ws/ is terminated server-side every ~25 minutes regardless of activity. The client reconnects successfully each time, but the frequent churn contributes to state desynchronization (see #28571) and makes the feature feel unreliable.

Evidence from debug logs

Analyzed ~/.claude/debug/734892b2-*.txt from a 6+ hour remote-control session on 2026-03-05.

Disconnect pattern: consistent ~25 minute intervals

All disconnects are server-initiated 1006 (abnormal closure — no close frame sent):

| Disconnect time | Interval from previous |
|----------------|----------------------|
| 10:38:56 | — |
| 11:04:04 | 25 min |
| 11:13:33 | 9 min |
| 11:38:41 | 25 min |
| 12:03:49 | 25 min |
| 12:28:57 | 25 min |
| 12:54:05 | 25 min |
| 13:34:16 | 25 min* |
| 13:59:24 | 25 min |
| 14:24:32 | 25 min |
| 14:49:39 | 25 min |
| 15:14:47 | 25 min |
| 15:39:55 | 25 min |
| 16:05:03 | 25 min |
| 16:30:11 | 25 min |

*The 13:34 gap is longer because two "No pong received" events triggered earlier reconnects at 13:02 and 13:09, resetting the 25-minute timer.

15 disconnects in ~6 hours, all code 1006, all recovered on reconnect attempt 1.

Client keep-alives are working but don't prevent the disconnect

• Keep-alive frames sent every 5 minutes (verified from log timestamps)
• Disconnects consistently occur ~6 seconds after a keep-alive frame
• This suggests a max connection lifetime on the server/proxy, not an idle timeout

Two disconnect mechanisms observed

1. Server-side close (code 1006): The ~25 minute pattern. Server terminates without a close frame.
2. Pong timeout: Client sends a WebSocket ping, no pong received — connection silently dead (likely network change or sleep/wake). Observed at 13:02 and 13:09.

Reconnection works, but state doesn't resync

• Reconnection succeeds on attempt 1 every time (~1 second with backoff)
• However, work poll responses show latest_heartbeat_at: null after reconnect
• This likely contributes to the state desync described in #28571

Expected behavior

• Server-side gateway should either not enforce a 25-minute max lifetime, or the lifetime should be long enough that reconnection churn is rare
• If the server must cycle connections, the client/server should seamlessly resync session state after reconnect

Environment

• Claude Code: 2.1.76
• macOS: Darwin 25.3.0 (Apple Silicon)
• Connection: local WiFi, stable network

Related issues

• #28571 — Remote control session fails to resync after connection drop
• #32642 — Remote control permanently disconnects after rate limit with concurrent sessions