[Feature Request] Expose Remote Control connection status via state file or CLI flag for external tooling

Feature Request

Problem

Remote Control state (active, reconnecting, failed) is only visible in the terminal
status bar. It appears to live entirely in the in-memory React/UI state and is not exposed
via any supported machine-readable interface, so external tooling cannot reliably detect
disconnect/reconnect/failure states.

This makes it impractical to:

• Programmatically detect when a Remote Control session drops
• Automatically recover from "reconnecting" states that never resolve
• Build watchdog scripts that restart Remote Control on failure
• Integrate Remote Control lifecycle into existing automation

Use Case: Headless Server with Mobile Access

I run multiple Claude Code sessions in tmux on a headless Debian 12 server (no desktop,
no browser) and access them via Remote Control from a Samsung Galaxy S23+ on claude.ai/code.

The connection is unstable — it frequently drops to "Remote Control reconnecting" (yellow)
and never recovers, requiring manual intervention. Since the server has no display, I cannot
see the status bar and have no way to detect the failure.

Workaround I'd like to build (but can't without state exposure):

1. Detect "Remote Control reconnecting" or "failed" status via a state file or CLI query
2. Kill the stale Remote Control connection and restart it (/remote-control)
3. Send the new QR code / connect URL to the user via a chatbot (WhatsApp/Telegram)

This would make Remote Control self-healing on headless servers.

Investigation

Analyzing the Claude Code v2.1.69 binary (Rust + embedded JS bundle) on Linux x86_64, the
Remote Control status appears to be managed by an in-memory store with fields like:

replBridgeEnabled         — RC feature enabled
replBridgeConnected       — Bridge WebSocket connected
replBridgeSessionActive   — User connected via claude.ai
replBridgeReconnecting    — Connection lost, attempting reconnect
replBridgeError           — Fatal error occurred
replBridgeConnectUrl      — URL / QR code target
replBridgeSessionUrl      — Active session URL

The status label logic appears to be:

if (error)                      → "Remote Control failed"    (red)
if (reconnecting)               → "Remote Control reconnecting" (yellow)
if (connected || sessionActive) → "Remote Control active"    (green)

None of this appears to be written to disk or exposed via any IPC mechanism.

I also attempted to infer RC status by inspecting TCP connections (ss -tnp) — active RC
sessions show an additional connection to an upstream bridge endpoint beyond the normal
Anthropic API connections. However, network-level heuristics are not reliable enough to
infer Remote Control state (connections are transient and not always present even when RC
shows "active").

*Note: The above observations are based on binary analysis and may not be fully accurate.
The Anthropic team would know the actual implementation details.*

Proposed Solution (MVP)

A CLI query would be the most scriptable and least intrusive approach:

claude remote-control status --json

Expected output:

{
  "status": "active",
  "sessionActive": true,
  "reconnecting": false,
  "updatedAt": "2026-03-07T12:00:00Z"
}

With documented exit codes:

• 0 — active (connected or session active)
• 1 — failed (fatal error)
• 2 — reconnecting (connection lost, attempting reconnect)
• 3 — inactive (RC not enabled)

This would enable watchdog scripts like:

claude remote-control status --json || handle_rc_failure

Future extensions (not required for MVP)

• State file (~/.claude/remote-control-state.json) for polling-based monitoring
• Event hooks in settings.json for push-based notifications on state changes

Environment

• Claude Code: 2.1.69
• OS: Debian 12.13 (linux x86_64, kernel 6.1.0-40-amd64)
• Access: Headless server, tmux sessions, mobile via claude.ai/code
• Plan: Claude Max