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

[BluCreator]

Preflight Checklist

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

What's Wrong?

Problem
Remote Control (/remote-control) silently drops the connection to the Claude iOS app (Code tab) during long sessions. Once dropped, the mobile client becomes completely unresponsive -- messages don't go through and there's no indication on either side that the connection is dead.

The core issue is that the built-in reconnection doesn't work. The connection drops and never recovers on its own. The only fix is to physically walk to the terminal and manually:

Run /remote-control
Select "Disconnect this session" from the interactive TUI menu
Run /remote-control [session-name] again
Notably, this manual disconnect/reconnect cycle always works -- the connection comes back healthy every time after cycling it. This suggests the reconnection logic itself isn't broken at the protocol level; something in the automatic recovery path is failing to trigger what a manual disconnect/reconnect does successfully. The fix may be as straightforward as having the auto-reconnect perform the same teardown/re-establish cycle that the manual flow does.

This defeats the entire purpose of remote control. If you're away from your desk -- which is the whole point of the feature -- you're locked out until you can physically get back to the machine.

The real fix
Remote Control's automatic reconnection needs to actually work. When the connection drops, Claude Code should detect the failure and re-establish the connection automatically, with no manual intervention required. This is the expected behavior for any persistent remote connection (SSH keep-alive, WebSocket reconnect, etc.).

The connection should be resilient to:

Network interruptions (WiFi switching, cellular handoffs)
iOS app backgrounding and foregrounding
Idle timeouts
Transient server-side disconnects
Why CLI flags alone wouldn't solve this
Adding flags like --restart or --reconnect would be nice for scripting, but they don't actually address the problem: you can't type commands when you're not at the computer. That's the whole reason you're using remote control in the first place. The fix has to be automatic.

Workarounds considered (none viable)
Custom slash commands / skills: Can't trigger built-in CLI commands like /remote-control from within a conversation or custom command.
tmux + scripted keystrokes: Theoretically possible (run Claude Code inside tmux, have a cron send keystrokes to disconnect/reconnect), but extremely brittle -- depends on exact TUI menu state, cursor position, timing. Not a real solution.
Cron-based reconnect: Would require non-interactive CLI flags that don't exist (/remote-control --disconnect, /remote-control --reconnect). Even if they did, it's a band-aid for what should be built-in behavior.
Nice-to-haves (secondary to the main fix)
If automatic reconnection is hard to ship immediately, these would at least unblock workarounds:

Non-interactive CLI flags: /remote-control --restart to cycle the connection from a script, enabling cron-based keep-alive
Connection health signal: A heartbeat or status indicator so external tools can detect a dead connection and attempt recovery
Mobile-side indication: Show the user on the iOS app that the connection dropped, instead of silently failing
Use case
I run long Claude Code sessions (hours to a full day) and manage them remotely from my iPhone via the Code tab. This is an incredibly powerful workflow when it works -- I can manage development, run automations, check on projects, all from my phone. But the silent connection drops make it unreliable for anything beyond a few minutes, which undermines the feature entirely.

Environment
Claude Code (CLI)
macOS (Apple Silicon)
Remote client: Claude iOS app, Code tab
Connection typically drops after 15-60 minutes of use

What Should Happen?

Remote Control's automatic reconnection needs to actually work. When the connection drops, Claude Code should detect the failure and re-establish the connection automatically, with no manual intervention required. This is the expected behavior for any persistent remote connection (SSH keep-alive, WebSocket reconnect, etc.).

The connection should be resilient to:

Network interruptions (WiFi switching, cellular handoffs)
iOS app backgrounding and foregrounding
Idle timeouts
Transient server-side disconnects

Error Messages/Logs

Steps to Reproduce

Leave a /remote-control session running and watch it fail to reconnect after a few hours.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.76

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

No response

[biguscj7]

+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.

[cmeinerd]

+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

[Wingie]

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.

[SerkanGezici]

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.

2. "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.

3. 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

[henrikalthofknudsen]

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.

[smartwatermelon]

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].