[BUG] Remote Control silently drops after automatic context compaction (no way to auto-recover)

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?

Subject: Remote Control silently drops after automatic context compaction (no way to auto-recover)

PLAN / TIER: Claude Max. Claude Code on Windows 11, Opus 4.8 (1M context). Feature: Remote Control.

SUMMARY
When a long-running Claude Code session hits an AUTOMATIC context compaction, the Remote Control
link dies. The session is no longer reachable from my other devices (phone app / claude.ai/code),
even though the terminal session on the base machine is still perfectly alive. There is no
supported way to re-establish Remote Control automatically — it requires a human to physically
return to the base machine and type /remote-control (/rc). That defeats the entire purpose of
Remote Control for anyone away from their base machine.

WHAT HAPPENED

• Base machine: a Windows laptop running a Claude Code session in the terminal.
• I enabled Remote Control (/rc, and also /config "Enable Remote Control for all sessions").
• I connected successfully from my Android phone (Claude app -> Code tab). It worked well.
• After a long working session, an automatic context compaction occurred.
• Immediately after, the session disappeared from my phone — the Remote Control link was dead.
• The terminal session on the base laptop was still running normally the whole time.

I RULED OUT THE OBVIOUS CAUSES (from Windows event logs)

• NOT sleep: the only power event that day was the morning wake; no sleep/standby afterwards.
• NOT a reboot: machine uptime was 7 days — it never restarted.
• NOT a network drop: WLAN logs showed no disconnect around the failure time (only a brief

3-second reconnect in the middle of the night, hours earlier).
The ONLY event that correlated with the drop was the automatic context compaction.

WHAT I CONFIRMED FROM THE DOCS (there is no workaround today)

• Remote Control is documented to auto-reconnect after NETWORK drops and after SLEEP. Compaction

is not mentioned either way — but in practice it drops the link and does NOT auto-recover.

• Hooks (PreCompact / PostCompact) exist, but hooks explicitly CANNOT invoke slash commands or

change Remote Control state. So a PostCompact hook cannot re-arm RC.

• There is no CLI flag or API that re-exposes an EXISTING running session — claude remote-control

only ever starts a NEW session, losing the live conversation.

• There is no keepalive / reconnect-after-compaction / persistence setting anywhere.

Net: once compaction drops Remote Control, the only way back is to manually type /rc at the base
machine — which is impossible when you are remote, which is exactly when you are using the feature.

WHY THIS MATTERS
Remote Control's whole value proposition is "drive your base-machine session from your phone or
another computer while away from your desk." Long sessions are precisely the ones you leave running
and reach back into during the day — and long sessions are the ones that auto-compact. So the
feature reliably breaks in the exact scenario it is designed for, silently, with no remote recovery.
A remote-access feature that can silently become unreachable and cannot be revived remotely is not
dependable enough to build a workday around.

WHAT I'D LIKE (in priority order)
1) BEST: Make Remote Control auto-recover after a context compaction, the same way it already
auto-reconnects after a network drop or sleep. Treat compaction as just another interruption the
link survives.
2) GOOD: Provide a non-interactive way to re-arm Remote Control on the CURRENT running session — e.g.
a CLI/IPC command, or allow a PostCompact hook to re-enable RC. Then users could self-heal it
automatically without a human at the keyboard.
3) MINIMUM: If it must drop, make it LOUD, not silent — push a clear notice to the connected phone/
browser clients ("Remote Control disconnected due to context compaction — re-run /rc on the base
machine to restore"), so the user at least knows immediately instead of discovering it by finding
the session gone.

REPRODUCTION STEPS

1. On a base machine, start a Claude Code session and enable Remote Control (/rc).
2. Connect from a second device (phone app or claude.ai/code) on the same account — confirm it works.
3. Keep the session running/working until an AUTOMATIC context compaction fires.
4. Observe: the session vanishes from the remote device; the terminal session stays alive; the

machine did not sleep, reboot, or lose network.

1. Observe: the only way to restore remote access is to physically type /rc on the base machine.

Thanks — really like Remote Control otherwise; this one gap is the thing stopping me from relying
on it.

What Should Happen?

Remote control conenction should survive compaction.

Error Messages/Logs

Steps to Reproduce

1. On a base machine, start a Claude Code session and enable Remote Control (/rc).
2. Connect from a second device (phone app or claude.ai/code) on the same account — confirm it works.
3. Keep the session running/working until an AUTOMATIC context compaction fires.
4. Observe: the session vanishes from the remote device; the terminal session stays alive; the

machine did not sleep, reboot, or lose network.

1. Observe: the only way to restore remote access is to physically type /rc on the base machine.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.218

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_