Remote Control shows "disconnected" while session is actively processing long turns; --remote-control flag and enableRemoteControlByDefault silently no-op under --dangerously-skip-permissions

Environment

• Claude Code v2.1.212 (latest at time of writing), installed at ~/.local/bin/claude
• Ubuntu Linux, kernel 6.17.0-40-generic x86_64 (headless VPS), zsh, tmux 3.5a
• Auth: Claude Max account via OAuth (no ANTHROPIC_API_KEY)
• Model: claude-opus-4-8, NODE_OPTIONS=--max-old-space-size=32768
• Sessions are full interactive TUI sessions running inside tmux panes (NOT claude -p), launched with: claude -n "<name>" --settings '{"enableRemoteControlByDefault":true}' --model claude-opus-4-8 --dangerously-skip-permissions
• Context: an orchestration daemon runs several such sessions as worker agents; Remote Control is the intended way for a human to watch them from the mobile app.

Issue A (main): RC session shows "disconnected" exactly while the session is busy

Steps to reproduce

1. Start an interactive session in tmux as above (Max OAuth).
2. Inside the session run /remote-control → it prints /remote-control is active · Continue here, on your phone, or at https://claude.ai/code/session_… and the /rc badge appears in the status line.
3. Give the session a long, heavy task (e.g. /effort max + a large repo-audit prompt — a single turn that streams/works for 15–20 minutes with many tool calls).
4. Watch the session in claude.ai/code (or the mobile app) while the turn is running.

Expected: the session shows as connected/online while it is working — that is precisely when observing it remotely is most valuable.

Actual: the app lists the session but shows it as disconnected for the whole duration of the long turn. The TUI keeps showing the /rc badge and the work completes normally.

Server-side evidence: while the session was mid-turn we sampled the claude process's TCP connections every 20 s (ss -tnp filtered by PID) for a full 15-minute window. The process held exactly one ESTABLISHED connection to Anthropic (the model streaming call) the entire time — no separate live Remote Control channel; the state never changed once:

03:19:43 ESTAB=1 busy=1   # unchanged for the whole 15-minute sampling window

It looks like the RC channel's connection/heartbeat does not survive (or is starved during) long streaming turns and is not re-established until the turn ends, so remote observers see "disconnected" precisely during the interesting part.

Issue B (secondary, docs/UX): both non-interactive ways to enable RC are silently ignored under --dangerously-skip-permissions

Measured on 2.1.212, same environment:

• claude --remote-control "<name>" … → session starts fine, RC not enabled, no message.
• claude --settings '{"enableRemoteControlByDefault":true}' … → RC enabled ✅ unless --dangerously-skip-permissions is also present, in which case it is silently ignored.
• The only way that works under --dangerously-skip-permissions is typing /remote-control inside the running session.

If ignoring these under bypass-permissions is intentional (understandable security posture), please (1) document it on the Remote Control page, and (2) print a one-line notice at startup ("Remote Control not auto-enabled under --dangerously-skip-permissions; run /remote-control in-session"). The silent no-op cost us several hours of debugging across a fleet of agents.

Impact

Remote Control is the natural way to supervise long-running agent fleets on headless servers from a phone. With Issue A, sessions are only visible when idle and go dark while working — inverting the feature's value. Happy to provide more diagnostics (we can reproduce on demand).