Title: Mobile app: no response for ~7h overnight despite daemon staying alive

Preflight Checklist

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

What's Wrong?

Summary:
Sent messages from the Claude Code mobile app to a laptop session overnight and got no responses for roughly 7 hours (~11:00 PM–7:15 AM Pacific). The local background daemon on the laptop was confirmed alive and responsive the entire time, so the break appears to be somewhere between the phone app and delivery to the daemon (relay layer), not a local crash or the machine sleeping.
Environment:
• Claude Code version: 2.1.205
• OS: Ubuntu (Linux 6.8.0-124-generic), Lenovo IdeaPad S340
What I ruled out locally:
• Laptop did not suspend/sleep overnight (checked journalctl suspend/resume events — none between ~11 PM and 7:15 AM).
• Wifi was up the whole window (continuous DHCP lease renewals every 15 min); one isolated ~60s wifi drop/reconnect at 4:53 AM self-healed and doesn’t explain a 7-hour gap.
• No OOM kill, no kernel-level kill signal to any Claude process.
• The daemon process itself was alive and running continuously: a “shutting down (cause=upgrade, uptime=31080s…)” log line at 8:11 AM shows uptime of 31,080s (~8.63h), meaning that daemon instance (started ~11:33 PM) ran uninterrupted straight through the entire outage window.
• The daemon performed a scheduled proactive auth token refresh mid-gap, at 1:21 AM, and logged success — this requires a live process actively doing work, further confirming the daemon wasn’t wedged or crashed.
What actually looks broken:
• Despite the daemon being alive and doing scheduled work at 1:21 AM, it logged zero inbound activity (no claimed-spare, no job/session activity, no errors of any kind) between 1:21 AM and 8:11 AM — the exact window I was sending messages from the phone app and getting no response.
• The daemon log contains no relay/websocket/connection-layer events at all, so I have no local visibility into whether the daemon’s outbound connection to the relay dropped and silently failed to reconnect.
• The moment I interacted with Claude Code locally again at 8:11 AM, the daemon immediately claimed a new spare and resumed normal activity — instant recovery on local trigger, consistent with a stale/dead outbound connection that only got re-established by fresh local activity rather than on its own.
Hypothesis (unconfirmed, since I can’t see the relay side):
The daemon’s connection to the mobile relay may go stale/silently drop during long idle periods overnight, with no automatic reconnect and no local logging of the failure, so the phone app has nothing to talk to even though the daemon process itself is healthy.
Ask:
Could the relay/delivery path be checked for silent disconnects during extended idle periods, and/or could the daemon log connection-layer state changes (connect/disconnect/reconnect to the relay) so this is diagnosable from daemon.log next time?
Note on an earlier red herring:
Right before the gap (around 11:00–11:33 PM), the daemon self-restarted 4 times in 32 minutes due to detecting the binary’s mtime changing (“self-restarting for upgrade”). This looked suspicious at first but the subsequent 8.63-hour continuous uptime through the outage window rules it out as the cause.

What Should Happen?

The mobile app should be able to reach the laptop and get responses at any time the laptop is awake and online, even after several hours of no activity overnight.”

Error Messages/Logs

Steps to Reproduce

“1. Start a Claude Code session/background job on a laptop via the mobile app. 2. Leave the laptop awake, plugged in, and connected to wifi overnight with no local interaction. 3. Try sending a message from the mobile app during the overnight period (in this case ~11 PM–7:15 AM Pacific). 4. Message gets no response, even though the laptop’s local daemon log shows it stayed alive and did a scheduled task (auth refresh) mid-window. 5. Sending a message/interacting locally again in the morning immediately restores responsiveness.”

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.205

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

_No response_