Remote Control session goes permanently unresponsive (process alive, no crash) after a Bash tool call times out; mobile app shows it as unrecoverable 'Disconnected'

Summary

A claude remote-control session (macOS host, connected via the iOS Code app) stopped producing any output mid-task and never recovered. The backing CLI process stayed alive on the host (confirmed via ps, no crash, no entry in DiagnosticReports) but stopped processing turns entirely. The mobile app shows the session as "Disconnected" and reconnecting does nothing — sending a new message produces no response, because there is no dead process to reconnect to; the live process itself has simply stopped advancing.

Environment

• Host: macOS 15 (Darwin 24.6.0), Mac mini (Apple M4), claude-code 2.1.234
• Bridge: claude remote-control --name <device> (daemon uptime ~5h at time of investigation, no restart)
• Client: iOS Code (Claude mobile) app, connecting over the internet to the host bridge

Timeline (from local session transcript + ~/Library/Logs/claude-remote-control.log, times UTC)

• 23:38:44 — Assistant enters Plan Mode via EnterPlanMode, immediately follows with a Bash tool call to inventory local tooling (Homebrew, Docker, CouchDB, Tailscale, plus ls on ~/Documents/Obsidian and ~/Library/Mobile Documents/com~apple~CloudDocs, and a sudo -n lsof -iTCP -sTCP:LISTEN).
• 23:40:57 — That Bash call returns Exit code 143 / Command timed out after 2m 0s, with output truncated right after the ls on com~apple~CloudDocs (iCloud Drive) — i.e. that specific step appears to be what hung, possibly an iCloud file-provider stub materializing indefinitely, or the sudo -n step blocking despite -n.
• After 23:40:57 — No further transcript entries at all. The assistant never issued another turn (no text, no tool call) after receiving the timed-out tool result. The process (confirmed via ps, PID still present, STAT S) sat idle for 40+ minutes with zero CPU activity and zero log output.
• The claude-remote-control.log never logged a "Session failed" event for this session (that message only appears for processes that actually exit) — this session's process never exited, it just stopped responding to input, which is a different and harder-to-detect failure mode.

A second, similar incident in the same window

A separate session on the same host (different session ID) stalled the same way earlier in the evening: it answered an AskUserQuestion tool call, received the tool result, and then never issued another turn — sitting alive-but-silent until it was manually found via ps/sample and killed with SIGKILL (SIGTERM alone did not terminate it). sample on that stuck process showed the main thread parked in what looked like a libuv/event-loop I/O wait, not spinning — consistent with a wedged async operation rather than a crash or infinite loop.

Both incidents share the same signature: a tool call completes and its result is delivered back into the transcript, but the harness's own next inference turn never happens, and the process is left permanently idle with no error, crash log, or "session failed" event — so nothing signals to the daemon, the mobile client, or the user that anything is wrong other than silence.

Impact

From the mobile app's perspective this is indistinguishable from a dead session — it shows "Disconnected," reconnect does nothing, and there is no way to recover the session short of SSHing/physically accessing the host, finding the PID via ps, and killing it (losing any unsaved plan/context) or otherwise reviving it manually. This happened 3 times to the same user in one evening across different sessions.

Secondary finding (possibly related, possibly not)

Bash tool calls inside remote-control-spawned sessions run with a minimal PATH (/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin) that excludes /opt/homebrew/bin. This causes Homebrew-installed tools (brew, gh, etc.) to report "not found" even when installed and present in the interactive user's normal shell PATH. This may or may not be related to the hang above, but seems worth fixing regardless since it silently changes tool availability/behavior between an interactive claude session and a remote-control one.

Request

• Please add a watchdog/timeout so a session whose inference turn stalls after a tool result is detected and either retried or surfaced as a clear error state (to both the daemon's session list and the mobile client) instead of going silently, permanently idle.
• If possible, surface a "session failed to advance" state distinct from "session process exited," since these need different recovery UX (the former might be resumable in-place; the latter requires starting a fresh process).