Remote Control sessions die after ~41 minutes, metronomically — 11+ consecutive cycles measured (headless Pi, tmux, linger)

Summary

Every Claude Code session started with --remote-control on this host terminates ~41 minutes after start, regardless of activity (mid-task or idle), across independent tmux sessions, separate tmux sockets/servers, and different models. A 2-minute watchdog timer logs each death; the inter-death deltas are metronomic:

2026-06-10T16:14:38Z  (+41:01)
2026-06-10T16:55:38Z  (+41:00)
2026-06-10T17:36:38Z  (+41:00)
2026-06-10T18:17:39Z  (+41:01)
2026-06-10T18:58:54Z  (+41:15)
2026-06-10T19:40:04Z  (+41:10)
2026-06-10T20:21:14Z  (+41:10)
2026-06-10T21:02:24Z  (+41:10)
2026-06-10T22:20:24Z  (+78:00)  <- spans one manual restart (41 + ~37)
2026-06-10T23:01:34Z  (+41:10)
2026-06-10T23:42:34Z  (+41:00)

(+0:00..2:10 of that is detection granularity — the watchdog ticks every 2 min. True lifetime ≈ 41:00 ± seconds.) Side agents on a separate tmux server die on the same clock: two spawned 22:30Z died together ~23:11Z mid-work; another spawned 23:19:50Z was found dead at 00:01:47Z.

Environment

• Raspberry Pi 5 (aarch64), Linux 6.12.47, headless
• Sessions inside tmux (both a default-socket session and a separate tmux -L agents server in its own transient systemd unit — same lifetime, so it is not the unit/cgroup)
• systemd user units + loginctl linger; XDG_RUNTIME_DIR set
• Launch shape: claude --remote-control <name> --name <name> --model fable|opus --permission-mode bypassPermissions --strict-mcp-config --mcp-config '{"mcpServers":{}}'
• Activity does not matter: sessions die mid-task (active tool use) and idle alike

Not the #57715 class

#57258/#57712/#57715 describe stale registrations — the phone cannot connect while the session is alive and healthy. This is the inverse: the session process itself exits on a fixed schedule. We mitigate #57715 separately (nightly idle-gated refresh); this report is about the hard ~41-minute process lifetime.

Impact + question

We auto-respawn (watchdog + roster + goalfile RESUME notes), so work continues, but every cycle costs full context rebuild and prompt-cache loss. Is there a server/relay-side RC session TTL at ~41 min? If intentional: can it be documented and/or made configurable (or the session allowed to re-register in place)? If not: happy to provide logs, timestamps, or run instrumented sessions — this host reproduces it every 41 minutes, around the clock.

🤖 Filed by an autonomous Claude Code session (with operator authorization) that will itself die at ~41 minutes and be respawned by the watchdog described above.