Remote Control (/remote-control) disconnects frequently

I can confirm this bug and provide evidence that the disconnection is definitively server-side.

Environment

| | Device A (RPi 500) | Device B (WSL2) |
|---|---|---|
| Hardware | Raspberry Pi 500 | Windows PC (WSL2) |
| OS | Debian GNU/Linux 12 (bookworm), aarch64 | Ubuntu 22.04.5 LTS, x86_64 |
| Kernel | 6.12.62+rpt-rpi-2712 | 6.6.87.2-microsoft-standard-WSL2 |
| tmux | 3.3a | 3.2a |
| Install | curl -fsSL https://claude.ai/install.sh \| bash | same |
| Network | Independent (different physical location) | Independent (different physical location) |

Key Evidence: Simultaneous Drop Across Two Independent Networks

Both devices dropped within ~45 seconds of each other, despite different session ages and completely separate networks in different physical locations.

WSL2 (session age ~20min):

[11:51:44] Error: Environment env_01QnEe55nzznkkdp6qvHCqPx not found.
[11:51:44] Shutting down 1 active session(s)…
2026-03-11 11:51:45 EXIT    claude rc (code 0, 1205s)

RPi 500 (session age ~10min):

[11:52:29] Error: Environment env_011B6Bv7sBt4NwKzZ35tWj2J not found.
[11:52:29] Shutting down 1 active session(s)…
2026-03-11 11:52:30 EXIT    claude rc (code 0, 605s)

A per-session timeout would drop them 10 minutes apart — not simultaneously. This points to a server-side event (restart, cleanup job, deployment) around 11:51–11:52 UTC+8.

Additional Observations

• The browser reflects the drop before the CLI does — https://claude.ai/code/session_{id} redirects to https://claude.ai/code/family while the CLI still shows "Connected", sometimes for 10+ minutes
• Active (non-idle) sessions are dropped mid-task — one drop occurred while Claude was waiting for tool approval
• Regular claude (local, no remote-control) on the same machine and network runs stably for 12+ hours — confirming the issue is specific to remote-control
• Typical observed lifetime: 10 min–3~4 hours

This confirms your finding that the issue is not network/ISP related. The server is terminating environments unexpectedly.

same here. remote-control drops

+1 — experiencing the same on macOS Darwin 25.3.0 (ARM64) with Claude iOS app.

Specifics from our case:

• Both Mac and iPhone active, same WiFi, screen on, stable network
• Drops happen randomly during long sessions (2+ hours)
• bypassPermissions mode — no prompts blocking
• Sometimes reconnects, sometimes gets stuck in "reconnecting" loop
• Only fix is disconnect + reconnect remote control manually

Additional issue: We also hit API 400 errors after context compaction drops media_type from base64 images (#36554). When that happens, the remote control sees the API failure as a connection issue and enters the reconnect loop permanently — it can never recover because every API call returns 400.

Workaround: Running Claude Code in tmux and using claude --continue after drops.

Same here. /remote-control shows “connected” and it previously worked perfectly. Right now, not even the web URL shows any updates, nor does the Claude iOS App. When it does work, it often drops—especially as chats get larger. I have to close the connection (on my PC) and reconnect before I can see updates again, and even that workaround isn’t working anymore.

I'm seeing the same thing on Ubuntu 24.04 and 25.10

The server side of /remote-control seems quite unstable, making the feature useless. Maybe a persistent server-side service needs more careful supervision?

Every time I try to use it, it fails, and when I return to the local session, it's "Remote Control reconnecting..." forever.

2.1.81 (Claude Code) on macOS 26.3.1

It does connect in my case, however I dont get the latest state on other devices, Claude Code crafted an issue report for me:

Summary

Remote Control fails to sync the latest conversation state to connected clients (both mobile app and Claude Desktop). Both clients show a stale state from an earlier point in the conversation, despite the main CLI session being further ahead.

Environment

• Claude Code CLI: Running on Windows 11 Pro (EVO-X2 Workstation, 128GB RAM)
• Model: Claude Opus 4.6 (1M context)
• Claude Mobile App: Android (com.anthropic.claude)
• Claude Desktop: Same machine as CLI
• Session name: setup-coding-team-project
• Date: 2026-03-25, ~07:50 UTC+1

Steps to Reproduce

1. Start a long Claude Code CLI session with many agent tool calls (subagents)
2. Session runs for several hours, accumulating significant context (~500k+ tokens)
3. A large agent task completes (in this case: 42 tool calls, ~70k tokens, ~7 min duration)
4. Open Claude Mobile App, connect to the session via Remote Control
5. Open Claude Desktop on the same machine, view the session

Expected Behavior

• Both clients should display the current/latest conversation state
• Messages sent from the mobile app should arrive in the CLI session

Actual Behavior

Reading (partial failure)

• Both clients (mobile + Desktop) show a stale state — specifically the conversation state BEFORE the last large agent task completed
• The latest agent result and subsequent user/assistant messages are missing
• Both clients show the exact same stale state, suggesting the issue is server-side, not client-side caching
• Claude Desktop was NOT previously connected to this session, so it cannot be a locally cached older version

Writing (complete failure)

• Mobile app allows typing and sending messages
• App shows "Cooking..." as if processing
• The sent message NEVER arrives in the CLI session
• No error is shown to the user on mobile

Screenshots

Three screenshots from the Android mobile app are available:

1. Initial connection: "Verbindung laeuft..." (connecting), empty chat area
2. After loading: Shows conversation content, but from BEFORE the latest state
3. User sends message: "Gib mir zuerst noch einen Ueberblick ueber die weiteren Schritte" — shows "Cooking..." but message never arrives in CLI

Hypothesis

The sync failure appears to correlate with a large agent task completion:

• Last synced state: Just before Phase T1 MCP-Server build (agent with 42 tool calls, ~70k tokens, ~7 min runtime)
• Missing state: The agent result, subsequent conversation turns, and another agent task (Phase T1 completion)
• Possible causes:
• Server-side state serialization has a size or time limit
• Context compression creates a window where the latest state is not yet available to Remote Control
• Large agent results are buffered before being committed to the syncable state
• The conversation exceeded a sync threshold (total session: ~500k+ tokens, 30+ agent dispatches)

Impact

• Severity: High — Remote Control is unreliable for long sessions
• User impact: Cannot monitor or contribute to long-running sessions from mobile
• Silent failure: No error message shown, user believes messages are being processed

Workaround

None identified. The only option is to continue using the CLI directly.

!Image

!Image

!Image

Tonight, on version 2.1.112 (Claude Code), I'm seeing Remote Control disconnect after a minute or less. I can have a CCCLI session open in Terminal and in the iOS Claude app, type something in the Terminal, see the session become active in the iOS app, and then it disappears from the iOS app after just a few seconds.
I have done the usual troubleshooting: made sure everything is up to date, logged out and back in from both CCCLI and the iOS app. It does work briefly -- very briefly -- and then just disconnects.

~I often see the same result as @theonlyquics. One thing I noticed the last time it happened to me is that my session was in plan mode and had several subagents running. One of the subagents needed permission but the mobile UI did not show a permissions prompt, it just continued to show the "subagents working" state. I eventually stopped the task on my mobile device and asked if claude was stuck. There was no response from Claude but the mobile UI continued to show its "working on it" state. Once I returned to the CLI, I could see the permissions prompt and after giving permission, Claude then saw my "are you still working" message and responded the he was. At that point the mobile app began showing me the latest state again. At this point I'm back on my local network so I don't know if the issue was a network connection issue or a bug with the UI failing to show subagent permission requests.~

This just happened to me while I was on my home network so my issue is not a connection issue. It seems to be a "mobile app doesn't show permission prompt sometimes" issue.

The recent comments make this look like more than a simple websocket drop.

It may help to separate three states in the report:

1. transport connected/disconnected: whether the RC socket is still alive;
2. host session progress: whether the local CLI/TUI is still producing new state;
3. remote client freshness: whether mobile/web/Desktop has received the latest host-side state.

Those can fail independently. A session can still be running locally while the mobile client is stale, or the transport can reconnect while a terminal-local permission prompt remains invisible to the remote surface.

For repro evidence, I would try to capture the exact transition where mobile goes stale: last message visible on mobile, local CLI state at the same time, whether the host is waiting on a prompt/subagent/tool, and whether a fresh text input from mobile reaches the local terminal. That would distinguish "connection dropped" from "state stream alive but blocked prompt not represented remotely".

For people seeing this during Plan mode or subagents: does the mobile UI ever show the concrete pending prompt/tool identity, or only a generic working/disconnected state?

Some time ago I switched to using the discord plugin, which has been infinitely more reliable. However, I can tell you that, for me, I would start a session at home, have some back and forth, then leave home and have a few more messages back and forth, and then I'd send a message and get no response at all. When I would return home, I would see that the cli client never received my last message, and there would be a status message "remote control reconnecting...".

The discord plugin doesn't have that problem, so now, neither do I.

In my case, it was not an issue of provoking permissions prompts or anything like that.

Thanks, that is a useful distinction. Your case narrows it to remote-to-host ingress failing: the local CLI never received the last mobile message, while the host-side UI was stuck at "remote control reconnecting...".

That is different from the invisible permission-prompt case. It suggests the report should track whether a mobile input is merely accepted by the remote surface or actually delivered to the host CLI/session.

I am having similar issues.

• Version: 2.1.166
• OS: Windows 10 Pro 10.0.19045, PowerShell
• Steps to reproduce: invoke /remote-control, terminal shows "Remote Control connecting…" indefinitely
• What the web interface sees: session appears to start, shows "Remote Control connecting…", then becomes unresponsive
• Duration: consistent for 3+ weeks across multiple restarts and a full PC reboot of the main machine running Claude with local project files that the remote-control is invoked from. Can't connect by browser, desktop app, or phone app, or rather, sees session with "Remote control connecting..." and it just hangs, and no requests are responded to.

Adding a feature-level framing that goes a step beyond "the drops are a bug": a remote-control session should be persistent by design — alive until the user explicitly ends it — and, when a drop is unavoidable, recoverable entirely from the controlling device, without ever needing physical access to the controlled machine.

The reason the distinction matters is that the impact scales sharply with distance from the controlled machine:

• Same building (hotel room ↔ poolside): a drop is a minor annoyance — a short walk back to re-establish it.
• Day trip: a mid-day drop stalls the rest of the day's work, because there's no way to reconnect until you're physically back at the machine.
• Multi-week travel, or the controlled machine in another city / country / continent: the feature becomes completely unusable — you cannot gain physical access to reconnect at all, so a single silent drop ends the session for the entire trip.

Requested behavior:

1. Stay connected until explicitly turned off — no rolling few-hour auto-timeout. An opt-in "keep alive until I disconnect" mode is perfectly fine for those who want long-lived sessions.
2. Remote re-establish / re-authorize from the controlling device (phone, claude.ai/code) after any drop, so recovery never depends on touching the controlled machine. (This is the constructive flip side of #34255 — not just "auto-reconnect should work," but "the human should be able to reconnect remotely when auto-reconnect can't.")
3. Surface the drop reason on both ends instead of failing silently, so the user knows whether to wait, retry, or give up.

Use case in one line: leaving a long-running session under remote control and travelling for weeks — checking in from a phone — is exactly the workflow this feature promises, and the periodic silent drop plus physical-access-only recovery is what currently defeats it.