[BUG] Remote Control: automatic reconnection doesn't work -- connection drops silently with no recovery

+1 on @BluCreator issue. Same version of Claude Code / model / iTerm2 and same behavior.

Terminal window shows 'Remote Control reconnecting'. Running /remote-control does not correct the failed connection.

Continuing the session from the iTerm2 does not result in reconnecting the session.

+1 on @BluCreator issue. Same version of Claude Code / model / iTerm2 and same behavior. Terminal window shows 'Remote Control reconnecting'. Running /remote-control does not correct the failed connection. Continuing the session from the iTerm2 does not result in reconnecting the session.

I have the same issue

Confirming we're seeing this too on Linux (Oracle Cloud, RHEL/aarch64). Two independent sessions disconnect at identical timestamps, confirming server-side. Client stops reconnecting after the 3rd drop (1002 protocol error). No viable workaround — the loop-restart approach doesn't help since it generates a new session each time, requiring manual reconnect on the phone anyway.

Reproducing this on WSL2 + iOS — v2.1.76

Environment

• OS: WSL2 Ubuntu (Linux 6.6.87.2-microsoft-standard-WSL2)
• Claude Code: v2.1.76
• Client: iOS Claude app (connecting via Remote Control)
• Usage: Start session in WSL2 terminal, enable /remote-control, connect from phone

Symptoms

1. Silent disconnect while status shows "Active": The statusline shows "Remote Control active" but the phone is actually disconnected. No error, no status change — completely silent.

1. "Connecting..." hangs indefinitely: After a disconnect, the auto-reconnect kicks in and shows "Remote Control connecting..." but never transitions back to "active". It stays stuck in this state until manual intervention.

1. Only workaround: Type /remote-control → select Disconnect → type /remote-control again → Connect. This requires physical access to the PC terminal, which defeats the purpose of remote control.

Frequency

• Happens every 20-60 minutes during active use
• Also happens during idle periods (phone screen off / app backgrounded on iOS)
• The "active but actually dead" case is the worst — you don't know it's broken until you try to send a message from the phone and get no response

Impact

This makes Remote Control unusable for its intended purpose (continuing work from mobile away from desk). Every disconnect requires physically going back to the PC to restart the connection.

Suggested improvements

1. Auto-reconnect that actually works — when the relay connection drops, the CLI should aggressively retry (exponential backoff) without requiring user intervention via /remote-control toggle
2. Accurate status indicator — if the relay hasn't received a heartbeat in N seconds, show "disconnected" not "active"
3. Programmatic reconnect — allow reconnecting without the interactive menu (e.g., a non-interactive flag or API), so users can script a watchdog

Systemd keep-alive watchdog workaround for Linux users

Hitting this consistently on Linux (v2.1.81): after a period of idle, the
service loses its connection to Anthropic's bridge and never recovers. The
mobile app shows the session as active but messages are never processed.

How we detect the stuck state:
Instead of counting log lines (unreliable — normal operation also generates ~1
line/sec), we check whether the process has an active ESTAB TCP connection to
Anthropic's servers on port 443. No connection = stuck.

Watchdog script (~/.local/bin/claude-remote-watchdog.sh):
#!/bin/bash
SERVICES=("claude-remote.service" "claude-remote-ha.service")

for SERVICE in "${SERVICES[@]}"; do
PID=$(systemctl --user show "$SERVICE" --property=MainPID --value
2>/dev/null)
STATE_FILE="/tmp/claude-watchdog-${SERVICE}.fail"

if [ -z "$PID" ] || [ "$PID" = "0" ]; then
rm -f "$STATE_FILE"
continue
fi

CONNECTIONS=$(ss -tnp | grep "pid=$PID," | grep "ESTAB" | grep ":443" | wc
-l)

if [ "$CONNECTIONS" -eq 0 ]; then
if [ -f "$STATE_FILE" ]; then
echo "$(date): $SERVICE has had no connection for 2 checks (~10
min) — restarting"
rm -f "$STATE_FILE"
systemctl --user restart "$SERVICE"
else
echo "$(date): $SERVICE no connection — waiting for next check"
touch "$STATE_FILE"
fi
else
rm -f "$STATE_FILE"
fi
done

systemd timer (runs every 5 minutes):
[Timer]
OnBootSec=5min
OnUnitActiveSec=5min

Important caveats:

• We use a 2-check grace period (~10 min) before restarting, to allow the

process to reconnect naturally after a transient NAT/idle timeout — avoiding
unnecessary session loss

• Restarting still creates a new session and loses conversation history — so

this is a last resort, not a real fix

• Even without the watchdog, returning to a session after many hours of idle

often results in a broken/empty session on the mobile side — so the real issue
is the bridge session not surviving long idle periods end-to-end

A proper fix in the reconnection logic (or bridge session persistence) would be
much preferred over any client-side workaround.

I'm seeing the same exact issue on multiple machines. No network disruption.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.81
• Plan: Max 200

This is not the documented 10-minute network timeout. The local machine remains online, and the CLI process is still running. The disconnect appears to be triggered by something else — possibly an idle timeout, a transient server-side drop, or a cellular/WiFi handoff on the mobile side — but the root cause is unknown because no diagnostic information is surfaced.

Observed Behavior

• Remote Control session is established and functioning normally.
• At some point (trigger unknown), the mobile client shows a yellow "reconnecting" message.
• The reconnection never completes. The session is unresponsive indefinitely.
• The only recovery is to physically return to the terminal and manually cycle the connection: run /remote-control → Disconnect → restart with /remote-control [session-name].

Confirming this also occurs on Linux (Ubuntu 22.04 on Azure VM). Same symptoms: silent disconnection after extended session, no auto-recovery, manual disconnect/reconnect cycle fixes it.

same issue by the time I'm ready to use my remote connection in iOS it's bad/stale; rendering the feature not very useful

It appears that this phenomenon is widespread and requires urgent improvement.

Exactly the same happens on Windows 10 running in Windows Teminal/Powershell 7 and Android on the mobile side.

same issue mac os VM with tmux session

Same issue. Windows 11, Windows Terminal, Claude Code 2.1.81, Android app. Session shows "Remote Control reconnecting" and never recovers. Manual disconnect/reconnect from terminal always fixes it, but that defeats the purpose of remote control.

Sharing a workaround that's been working reliably for me, based on @henrikalthofknudsen's systemd watchdog idea — adapted for tmux with direct TUI-level auto-reconnect instead of process restart.

<img width="1716" height="332" alt="Image" src="https://github.com/user-attachments/assets/b63f77f8-ec09-44dd-bc15-4226acd6fa8a" />

TL;DR: Use tmux + a watchdog script to detect dead sessions and automatically cycle /remote-control via tmux send-keys.

How it works:

I manage all my Claude Code sessions in tmux panes. The watchdog script runs on a loop (every 5 minutes via Claude Code's /loop command, or standalone via cron) and:

1. Scans all tmux panes using tmux capture-pane to read the status bar
2. Detects panes showing Remote Control reconnecting (the stuck/dead state)
3. Uses a 2-check grace period (~10 min) to avoid false positives on transient drops
4. When confirmed dead, sends keystrokes via tmux send-keys to cycle the connection:

• Ctrl+C → clear prompt
• /remote-control → navigate to "Disconnect this session" → Enter
• /remote-control → auto-connects to a fresh bridge session

The key insight is that the /remote-control TUI menu defaults the cursor to "Continue" (the last item), so the script sends Up Up Enter to reach "Disconnect this session". After disconnecting, running /remote-control again auto-connects without showing the TUI menu. This preserves the existing session and conversation history (unlike a full process restart).

Usage (inside Claude Code):

/loop 5m /remote-watchdog

Or standalone via cron:

*/5 * * * * ~/.claude/scripts/remote-watchdog.sh >> /tmp/remote-watchdog.log 2>&1

Repo: https://github.com/Sma1lboy/claude-remote-watchdog

Caveats: Requires tmux (sessions must run inside tmux panes). The TUI keystroke timing (STEP_WAIT=5) may need adjustment on slower machines. This is a workaround for the symptom, not the root cause — would love to see proper auto-reconnection built into Claude Code.

+1 seeing the same behavior on macos TUI

Same issue on Windows 11. Updated claude code yesterday so version is current. Seems to happen right around the 4 hour mark for me, consistently.

Hitting this with Obsidian CLI + Claude Code Channels on macOS (Terminal CLI). Connection drops silently after a few minutes of idle — no error, no reconnect attempt. The Obsidian CLI skill (/savethis) stops responding as a result, which breaks the whole vault integration workflow. try /status or

Same issue here. Would love to have it open all day!

Encountering the same issue here ✋

Same issue with Linux. I once had it running for 12 hours. Next session it only worked for 30 mins.

Same issue - is there any way to retrieve the session context? RIght now it seems like my entire session is read only and claude has no way to access it

[16:14:11] Session completed (4h 0m 2s) cse_01Vq6sPAUbLf5y6ijg9jSvet
[18:37:04] Session failed: Process exited with error cse_01JA33qY86CNU2g2pz9HjuFA

Same issue here using MacOS... it's really painful because I'm working a lot remotely using mobile devices with multiple sessions and when they get disconnected all the session progress is lost (I do some workarounds but idk if is there any built in way to recover the session).

I love using remote control but this is very annoying.

FYI, this appears next to me by downloading the latest version of Claude desktop on macOS as well as the latest version of Claude on iOS. hope that helps others as well!

+1

This is genuinely frustrating. Remote control is one of the most exciting features of Claude Code, but the constant silent disconnections make it practically unusable for its intended purpose. The whole point is to work away from the terminal, but you end up having to walk back to the machine to manually cycle the connection every time it drops. Huge downer when I'm far away.

In the last week, it has been a much improved experience for me. I can go several days now without interruption.

The two main issues I've notice

• It awaits a permission/confirmation and this doesn't get transferred to the remote control client. But if using tmux and switching to the instance, you can confirm there and often the client will reconnect.
• It loses connection and even browser or app refresh of the remote control instance doesn't fix it.

The last one I see much more rarely now.

Same issue here. Running Claude Code in a dedicated screen session on a headless Ubuntu server. When I come back after a period of inactivity, the screen session and Claude Code process are both alive and fully responsive (I can attach and continue directly). However, the remote-control connection has dropped silently — no error, no indication it disconnected — and the web interface is completely unresponsive. The only recovery is SSH-ing into the server and restarting claude remote-control manually.

Setup: Claude Code in screen on a Linux server, connecting via claude.ai/code in browser.
Symptom: Remote-control silently dies during inactivity. No reconnection attempt visible on either side.
Workaround: claude remote-control restart after SSH reconnect.

Would really benefit from either automatic reconnection when the browser tab reconnects, or at least a visible "connection lost" indicator so you know to restart rather than wondering if your messages are just slow.

Remote control is a great feature but this bug makes it almost impossible to use
.

Is it possible to prioritize a fix ?

This is absolute garbage. I'm on the go right now, and all my sessions are disconnected. AS ALWAYS! Damn it.

+1

+1
I've noticed people are having this bug 2 months ago.

As said - it's an amazing feature. Please try to prioritize this bug.
Does somebody know any workaround for the moment?

Session disconnected after switching networks or waiting a night.

It's been a couple of weeks that I don't see this issue anymore. Maybe they solved the problem ?

Nope. It still happens daily for me.

Same thing on Linux (Hostinger VPS, Ubuntu 24.04), Claude Code 2.1.139, Node 22, Max sub. Fresh auth via claude auth login --claudeai.

Process registers fine, does exactly ONE /work/poll request that returns "no work, 1 consecutive empty polls", then complete silence. Process stays alive but strace shows almost no syscalls (15 reads + 1 write per 5sec), TCP to anthropic stays ESTABLISHED, no further HTTP traffic. Messages sent from claude.ai/code never reach the VPS, browser keeps showing "Remote Control disconnected".

Tried the nuclear cleanup: killed all claude processes, rm -rf /root/.claude/, fresh login, single tmux session running just claude remote-control. Also requested server-side session cleanup via "Delete saved sessions" in settings. Same behavior. Reproduces identically on 2.1.138 and 2.1.139.

Last log line before going quiet:
[bridge:api] GET .../work/poll -> 200 (no work, 1 consecutive empty polls)

Issue is labeled platform:ios/macos but Linux behaves identically.

+1, reporting in from Hetzner Cloud (Germany 🇩🇪) — Ubuntu 24.04 server running claude remote-control --spawn worktree, RC 2.1.139, with the iOS app as my only mobile interface from China 🥺

Hit the exact symptom described in OP last night (UTC 2026-05-11 16:00–23:00, a 7-hour outage):

• claude-remote.service stayed active to systemd the whole window
• cgroup memory.events: oom_kill 0, oom 0
• PSI memory all-zero, MemAvailable 3.7–5 GiB throughout
• Network layer healthy: TLS to api.anthropic.com stable, 35–55ms via Cloudflare edge
• But the iOS app couldn't see the device at all — not "device shows offline", literally missing from the device list
• Only systemctl restart claude-remote.service brought it back

Built an out-of-band watchdog as a stopgap, since I can't physically reach my server from another country:

1. Every 60s, check if any TCP ESTAB connection from the service's cgroup terminates at api.anthropic.com IPs
2. If missing AND the host itself can still reach api.anthropic.com:443 → systemctl restart claude-remote after 3 consecutive failures
3. Plus softdog kernel watchdog for the rare PID 1 stall case

It works, but having to write infra-side recovery for what should be a small reconnect loop in the daemon is honestly pretty sad 🥺 This issue has been open since March 2026 and every long-running remote workflow silently breaks because of it — please bump this up the queue 🙏

Happy to share the watchdog scripts if anyone wants them as a stopgap while waiting for the real fix.

Happy to share the watchdog scripts if anyone wants them as a stopgap while waiting for the real fix.

Please share, this sound like the best workaround so far. 🙏

You guys raised a trillion dollar , fix it !

Consistently a problem here as well. Using both android and web as remote clients

The tmux watchdog workaround above is useful, but I think there are two different recovery models getting mixed together here:

1. Keep the official Remote Control bridge alive, or cycle it when it gets stuck.
2. Treat the local tmux/terminal session as the durable work surface, and make mobile attach to that same live process through a separate control surface.

The first model is what Claude Code should fix natively: heartbeat, accurate connected/disconnected state, non-interactive reconnect, and a stable session identity that survives transient relay drops. A mobile UI that still says “active” while the host-side bridge is dead is the failure mode that burns user trust.

The second model is the workaround class I’ve been building around in Faryo: https://github.com/Snailflyer/faryo

Faryo is not a fix for Claude Remote Control reconnect, and it does not make the official bridge more stable. It keeps Claude Code/Codex/shell inside a named tmux session and gives phone/desktop browsers a lightweight workbench for output review, short input, approve/interrupt, and handoff back into the same session. In other words, the durable handle is the tmux session, not the RC URL.

For people already running Claude Code in tmux or systemd, that distinction matters: if the official bridge silently dies but the local process is still alive, you need either a reliable bridge reconnect or an independent way to reach the same live process. Both are valid; they just solve different parts of the failure.

Running Remote Control as a systemd service on a VPS. The process kept dying silently - in my case the Linux OOM killer was the cause. The default Type=oneshot + RemainAfterExit=yes setup made it worse because systemd still reported "active" even though the process was long gone. From the mobile app it just looked like the silent disconnect described here.

What I changed: added swap to reduce OOM kills, switched the service to Type=simple with a wrapper script that monitors the tmux session, and added Restart=on-failure so systemd actually restarts it when it dies. Early days, but seems more robust so far.

Same repro on Windows + Claude Code desktop app + Claude Android app:

• enableRemoteControl=true set in ~/.claude.json
• Desktop session registers fine; visible in Android app's Code tab with green dot
• Session disconnects silently after a few minutes (often <15)
• Android app shows the session as stale but has no Reconnect button — only restart-app workaround
• Status bar on desktop shows "Remote Control reconnecting" indefinitely
• Auto-reconnect described in the docs (https://code.claude.com/docs/en/remote-control) never fires in practice

Claude Code v2.1.150. Same behavior with v2.1.149.

The community fix (claude-remote-watchdog + tmux) works but only in a Linux/tmux env — it cannot monitor the Claude desktop Electron app's session state, so users on the desktop app are stuck waiting for an upstream fix.

Would help to have: (a) a working auto-reconnect, or (b) a Reconnect button in the mobile app, or (c) a way to query session health from outside the desktop app so a Windows-side watchdog can be built.

Root cause identified: epoch superseded (409) + no auto-recovery after teardown

I've been debugging this exact problem across 5 rounds of investigation over the past week, with full --debug-file logs. Here's the root cause and a concrete fix proposal.

The failure path (from debug logs)

When the mobile app reconnects to a session (due to network change, app backgrounding/foregrounding, or lock screen wake), the server creates a new epoch for that session. The desktop client's old epoch becomes invalid:

[WARN]  CCRClient: Heartbeat returned 401              ← × 9 over ~3 minutes
[DEBUG] [bridge:repl] CCR v2: epoch superseded (409) — closing for poll-loop recovery
[DEBUG] [remote-bridge] v2 transport closed (code=4090)
[DEBUG] [bridge:repl] handleStateChange state=failed detail="Transport closed (code 4090)"
[DEBUG] [bridge:repl] Hook cleanup: starting teardown for session=cse_xxx (skipArchive)
[DEBUG] [remote-bridge] Teardown complete (skipArchive): session=cse_xxx

After teardown, the bridge is permanently dead. The process continues running (API calls work), but RC never recovers. The only fix is manually running /remote-control in the terminal.

Evidence that auto-recovery is already feasible

In the same incident, a session that was NOT hit by epoch supersede performed a proactive refresh that seamlessly upgraded its epoch — proving the client already has this capability:

[DEBUG] SSETransport: Stream ended, reconnecting
[DEBUG] [bridge:repl] CCR v2: worker sessionId=[REDACTED] epoch=2 (from /bridge)
[DEBUG] [remote-bridge] Transport rebuilt (proactive refresh)
[DEBUG] CCRClient: initialized, epoch=2
[DEBUG] [bridge:repl] v2 transport ready for writes (epoch=2, sse=open)
[DEBUG] [remote-bridge] v2 transport connected

The proactive refresh path gets a new epoch and rebuilds the transport with zero downtime. The teardown path just... gives up.

Key finding: epoch supersede is per-session, not per-identity

The mobile app does NOT supersede all sessions at once — only the specific sessions it reconnects to. In one observed incident with 3 active RC sessions:

• 2 sessions received epoch superseded (409) within ~1 minute of each other (06:21 and 06:22 UTC)
• 1 session was completely unaffected — heartbeats continued succeeding through the entire window, later did a proactive refresh to epoch=2

This makes the behavior unpredictable: "some sessions disconnect, some don't" with no user-visible reason.

Proposed fix

After epoch superseded (409) triggers teardown, the client should automatically attempt to re-establish the bridge using the same mechanism as proactive refresh (with exponential backoff on failure), instead of permanently giving up.

Environment

• Claude Code 2.1.152, Linux (WSL2)
• 5-8 interactive sessions in parallel via tmux, each with /remote-control
• Mobile client: Claude iOS
• All sessions started with --debug-file via a wrapper script

I think this problem might be created when i rename a chat session within my Desktop Claude program as well. I tried the "/remote-control [session name]" fix above, using the new name after renaming a session that was "disconnected," but on my iPhone it merely says "(no content)" on the first line and then a blank line...then below that "Remote Control connecting..." and it does nothing...

Also, when I use claude-code from the command line and run "/remote-control Yancey, Keith" it automatically shows two sessions with my Claude Code desktop application:

<img width="143" height="89" alt="Image" src="https://github.com/user-attachments/assets/d0448da0-651c-4bbb-bd45-08d73731044c" />

And here's what it says in Claude CLI:

<img width="829" height="78" alt="Image" src="https://github.com/user-attachments/assets/8bc53d0d-7c34-416c-aad0-476649769a96" />

I'm not sure if it does this because I previously renamed the session within the desktop application or what...In other words...

1) Start session with "remote control" enabled in settings...
2) The session is renamed before or after it officially disconnects (not sure which)...
3) It disconnects and for some unknown reason and isn't available on my phone...
4) Based on the advice above, I use the "/remote-control" command to restart it...
5) It creates a new session with an identical name within the desktop application, as you can see in my image above...

Perplexing...Please fix because it defeats the entire purpose of this awesome feature!

Attempted is multiple times...notice the different session identifiers at the end of the string for the two sessions...this despite the same session name of "Yancey, Keith"....

<img width="859" height="204" alt="Image" src="https://github.com/user-attachments/assets/509e16c1-3e27-43b6-beb3-81364da53384" />

Might have something to do with this...

Same issue here. I activate /remote-control, and when connecting from the app it just shows "Remote Control connecting…" indefinitely. Messages I send don't go through at all. I tried disconnecting and reconnecting the session but it didn't help.

Is anyone from Anthropic actually going to respond to our messages on here or what? lol. You'd figure that they'd have an LLM monitoring issues like these to provide good customer service. ;-)

Another aspect here is I have multiple remote control sessions and they all disconnect. If I reconnect one of them they will all reconnect.

Same issue here. I activate /remote-control, and when connecting from the app it just shows "Remote Control connecting…" indefinitely. Messages I send don't go through at all. I tried disconnecting and reconnecting the session but it didn't help.

Yup - literally just ran into this issue on Windows desktop app and trying to reconnect to a session from iOS.

Hit this on CLI 2.1.173 (macOS 25.3.0 / Apple Silicon) running claude remote-control as a long-lived launchd daemon, and can add some hard diagnostics from catching it in the failed state.

Two daemons (claude remote-control --name X, launchd KeepAlive, started ~16:25) silently lost their connections in the evening (last log writes 16:25 and 18:31) and stayed dead all night. Caught in the act the next morning:

• lsof -a -p <pid> -i TCP → zero TCP sockets. The process held only its log files, kqueues, and one unix socket. The websocket was fully gone locally — not half-open.
• sample <pid> → main thread idle in kevent64 inside the event loop. Not crashed, not spinning — just waiting for events with nothing registered to fire.
• Nothing written to stdout/stderr after the drop: no "Reconnecting", no error, no exit. The daemon's last self-rendered status was still ·✔︎· Connected · Ready.
• The machine did not sleep that night (verified via pmset -g log) — so this isn't a sleep/wake artifact. Notably, on nights when the machine does sleep, every dark-wake produces a clean socket error and the daemon logs Reconnected after 0s each time. The auto-reconnect only fails when the connection dies while the host stays awake — consistent with the close never surfacing as an event, or the reconnect path silently aborting.

So the observable bug state is: process alive and idle, no socket, no reconnect attempt, no log output, UI claims Connected. launchctl kickstart -k (equivalent to the manual disconnect/reconnect cycle described in the OP) recovers it immediately every time.

Workaround for anyone running this as a daemon: a periodic watchdog that treats "process up > 3 min with no ESTABLISHED TCP socket" as zombie and kickstarts only then — that's the one signal that reliably distinguishes this state, since the daemon logs nothing.

Adding a focused note and an architectural angle on top of @zxmsdyz's excellent root-cause work — which deserves far more attention than it's gotten.

**The core defect is that a recoverable event is handled as terminal.** When the mobile client reconnects (network change, app backgrounding, lock-screen wake) the server mints a new epoch; the desktop receives epoch superseded (409) and, instead of refreshing, runs the teardown chain:

CCR v2: epoch superseded (409) — closing for poll-loop recovery
→ v2 transport closed (code=4090)
→ Hook cleanup: starting teardown...
→ Teardown complete        # bridge now permanently dead, process still alive

The fix surface is small and already present in the codebase: the proactive refresh path handles epoch upgrades seamlessly (SSETransport: Stream ended, reconnecting → new epoch → Transport rebuilt (proactive refresh)). The 409-supersede branch just needs to enter that same path instead of tearing down. A 409 epoch superseded means "a newer epoch exists" — that is a reattach signal, not a shutdown signal.

Two things that would reduce the pain even before the real fix lands:

1. Surface the close reason. Today a drop produces no user-visible signal and — per lsof — zero open sockets while the statusline still reads "active" / "reconnecting…" indefinitely. A zombie that looks healthy is the worst failure mode; at minimum the statusline should reflect the dead transport so users don't discover it hours later.
2. The systemd packaging issue is separate and worth its own fix: Type=oneshot + RemainAfterExit=yes reports the unit "active" after an OOM kill on low-memory hosts. Type=simple + Restart=on-failure would self-heal that class.

For contrast — I run Codex's equivalent remote channel under the same conditions (mobile handoffs, backgrounding, hosts that never sleep) and have never seen a comparable silent death. The difference reads as transport supervision: treat the connection as disposable and reattach transparently — which is exactly what the proactive refresh path here already knows how to do; it's simply not wired to the 409 case.

Last, said with respect and as a heavy daily user: this one stings less as a bug than as a response-time signal. It's been open since March, a community member has already done the log-level root-cause analysis, and there's still no maintainer acknowledgement across 46 comments and several duplicates (#33041, #66491, #66255, #61996). The model quality is outstanding — closing the gap on operational responsiveness around it is mostly turnaround, not research, and it's where the day-to-day experience currently trails. 🙂

Also hitting this on Windows, Claude Desktop–embedded Claude Code (Max plan, claude.ai OAuth) — filed #69543 (closed as dup of this). Two points for triage:

1. Not macOS-only — reproduces on Windows Desktop (auto-labeled platform:windows / area:desktop / area:networking).
2. Shared-layer, not just per-session: after a long/overnight idle, ALL toggle-auto-connected sessions drop AND the "Enable remote control by default" toggle stops auto-connecting NEW sessions; a single manual /remote-control re-arms it for new sessions (already-dropped ones still need their own /rc). Suggests an account-scoped bridge registration (%APPDATA%\Claude\bridge-state.json) going stale wholesale, not just an SSE transport blip. Full logs in the linked issue.

Extra symptom: after the manual /remote-control re-arm, the dead session isn't torn down server-side — the old entry lingers (old name, disconnected) while the re-arm mints a NEW remoteSessionId, so each revived session shows up twice on mobile (stale ghost + live one with updated chat/name).

Data point from a long-running headless deployment that may help separate two failure modes here.

Setup: several claude remote-control instances under systemd (Restart=always) on an always-on Linux box that never sleeps, driven from the Claude macOS/iOS app. v2.1.174.

1. The local process reliably survives the disconnect — conversation workers stay alive 7+ hours, and one that predates the current OAuth token's refresh (TTL ~8h) is still running well past it. So in this mode it's purely the relay link dropping, not the process — consistent with the v2.1.70 polling-interval change (#32727).
2. Auto-reconnect never fires (this issue). The session goes silent with no recovery.
3. The UX makes it look like lost work: the app keys the session by a cse_… id, but the only reliable recovery is claude --resume <on-disk-uuid> in a terminal (or re-opening the exact environment URL). The app's reconnect button tends to drop you into a fresh/empty session, so the conversation appears gone even though the transcript is intact on disk.
4. Separately, on the token-expiry/403 path (#53563) the process does exit and orphans the session — that variant only recovers via --resume.

Two fixes would cover most headless cases: automatic reconnect/backoff on the relay link (the process is alive — it just needs to re-register), and mirroring the Desktop app's token refresh + backoff instead of treating 401/403 as fatal (#53563). Happy to provide verbose logs across a disconnect.

Same issue, but with a variant worth noting: the CLI loses track of the session entirely, so the manual disconnect/reconnect workaround isn't available.

Symptoms:

• Mobile/desktop client shows "Remote Control disconnected — The bridged Claude Code process stopped responding mid-turn. Check your terminal for errors (you may need to run /login), then resend your message."
• The host machine is fine: terminal is open, the claude process is still running, no errors of any kind in the terminal, network is up.
• "Try again" on the client does nothing.
• Critically: running /remote-control on the host does not show a "Disconnect this session" option or any active-session menu — it just starts a new Remote Control session as if none existed. So the CLI side apparently believes there's no active session, while the client side believes the session exists but the bridge died.

This suggests the CLI's local session state is being torn down (or orphaned) without any error surfacing in the terminal, which is why auto-reconnect never fires — there's nothing left on the CLI side to reconnect.

Environment: Windows host, connecting from the Claude desktop client, Claude Code (latest at time of writing).

Report Assisted by Claude Opus 4.8

Verified repro: phone-submitted AskUserQuestion ("Other") answer is never committed to the local transcript

Adding a content-level confirmation of the "post-disconnect messages missing" behavior in this issue, with a specific, reproducible trigger. A session was remote-controlled from the mobile app while the PC was briefly offline. The CLI emitted an AskUserQuestion; I answered on the phone via "Other" (free text). The phone re-rendered the same question (selection ignored), then the remote session disconnected. On PC reconnect, neither the answer nor any later message exists in the local .jsonl — the file ends on the unanswered question. The answer survives only in phone screenshots (attached).

_Username redacted as ~; bank-reconciliation session, financial values omitted (metadata only). Timestamps UTC._

Environment

| Item | Value |
|---|---|
| Installed CLI (claude --version) | 2.1.198 |
| CLI that wrote the transcript (record metadata) | 2.1.208 (newer than installed) |
| Entrypoint | claude-vscode |
| OS | Windows 11 Pro 10.0.26200 (win32) |
| Remote-control keys in settings.json | none |
| CLAUDE_CODE_ENABLE_REMOTE_CONTROL | unset |
| SDK-sourced human prompts (promptSource:"sdk") | 45 / 59 |

Note the anomaly: no explicit remote-control enablement in local config, yet most prompts arrived via the SDK/control channel, and the transcript was written by a newer build than the one installed.

Session

• ID: e1cf15da-1587-48d0-9fbc-4c6f5ed773b9
• ~21.25 MiB · 1,979 records · 59 human turns · 8 AskUserQuestion calls
• First → last content message: 2026-07-14T07:24:00Z → 2026-07-14T17:27:08Z
• File mtime 2026-07-15T02:49:38Z — ~9.4 h after the last content timestamp (delayed/async flush)
• 1 manual compaction at 09:46Z; no remote connect/disconnect events recorded (format has no such keys)

Findings — confirmed two ways

Structural: the transcript terminates on an unanswered AskUserQuestion.

• Final content record = AskUserQuestion "Overdraft fix", id toolu_0149g5E4kKiPpRnLQNfpZ3xV, 17:27:08.232Z.
• Of 8 AskUserQuestion calls, 7 have on-disk answers; this last one has none. No tool_result references that id, and no user record follows it — only zero-timestamp state snapshots (last-prompt / ai-title / mode).

Content: the typed "Other" answer is absent from disk. Distinctive phrases from what I typed on the phone (prompt advisor, number of sample, 1 correct pdf, 2 correct excel, two wrong excel, arithmetic check method, any other good solution) return 0 matches in the local .jsonl.

Conclusion: an answer typed in the mobile app during the offline window is not persisted to the local session. The tool call stayed pending; the phone UI accepted the response but never committed it back to the CLI session. Unrecoverable from local data.

Reproduction

1. Drive a Claude Code session from the mobile app (remote control) with the PC briefly offline.
2. Have the CLI emit an AskUserQuestion; answer on the phone via "Other" (free text).
3. Phone re-renders the same question (selection not registered), then the remote session disconnects.
4. Reconnect the PC and inspect the local transcript.

Expected: the phone-submitted answer is committed to the session and written to the local .jsonl.
Actual: the answer is lost; only the CLI-side question is persisted. The file ends on the pending question.

Environment: Claude Code 2.1.198 installed / 2.1.208 wrote the record, VS Code extension, Windows 11, Pro plan. Screenshots (question + submitted "Other" answer) attached (For context, conversation related to financial documents extraction).

<img width="540" height="1170" alt="Image" src="https://github.com/user-attachments/assets/ab036c39-0646-4a26-b42f-54f6de7978f1" /> <img width="540" height="1170" alt="Image" src="https://github.com/user-attachments/assets/29c88c88-3ae8-4229-94b5-6c6bbe0a9e4b" />

Confirming this is still happening on v2.1.210, and adding an environment where the usual culprits are ruled out.

Setup: Windows 11 (build 26200) → Windows Terminal → WSL2 (mirrored networking mode), running claude interactively and driving it from the Claude iOS app via Remote Control. PC is set to never sleep.

Symptom: The Remote Control relay drops on its own after a while. The local claude process is still alive and healthy on the PC — it's only the relay link that dies. The auto-reconnect ("Survive interruptions") does not recover it; the session just sits there un-reachable from the phone. The real pain — no way to recover without physical access to the host: The only documented way to re-arm the relay is typing /remote-control in the PC's terminal. When you're on the phone (the entire point of Remote Control), that's a hard lockout. There's no CLI subcommand, no mobile-app "retry," and server mode behaves identically. My only workaround was installing a full remote-desktop tool on the PC purely so I can reach the terminal from my phone and type /remote-control — which defeats the purpose of the feature. Concrete asks, either of which would fix the lockout:

1. A non-interactive re-arm — e.g. claude remote-control --reconnect / --restart, runnable over SSH against the existing session — so the relay can be revived without keyboard access to the interactive process.
2. A "reconnect" control in the mobile app / claude.ai/code that tells the still-running host session to re-establish its relay.

Also worth revisiting the root cause noted in #32727: the ~10-minute relay polling interval means a brief network blip is enough to declare the session dead. A shorter heartbeat, or a grace/retry window before the server gives up, would prevent most of these drops in the first place.

This issue is compounded by the fact that Remote Control is one of the few features not exposed to the session management tools CC has access to, or through any other interface, so there's no way for us to build our own tools to re-enable Remote Control on those sessions where it died.