Remote control: toggle_remote_control completes silently — no local banner, no handshake confirmation, but phone-side registers connection (split-brain)

Summary

When /remote-control is toggled on in the VS Code extension, the webview sends a toggle_remote_control {\"enable\": true} message to the extension host as expected — but no corresponding success/handshake confirmation is ever logged or surfaced. The local UI does not show the \"remote session active\" banner above the textbox. Yet the phone-side app independently registers a connected session and receives streamed messages for some period before silently stopping.

The result is a split-brain state: the extension-host believes the remote bridge isn't fully established (hence no banner), the phone believes it is (and partially syncs), and downstream streaming events that need to fan out to both consumers end up in undefined behavior.

In my session this state correlates with 3 separate Unhandled case: [object Object] UI crashes (#59013), each followed by clean session resume. The correlation isn't proven causal here, but the timing suggests the half-broken bridge serializer is amplifying / triggering the unhandled-case bug in the webview stream consumer.

Reproduction (observed once on Windows + VS Code 2.1.141, Opus 4.7)

1. Long-running VS Code Claude Code session in progress
2. Toggle /remote-control on (or whichever UI gesture invokes the same)
3. Inline link appears in the chat as expected — phone scans / accepts → phone shows connected session
4. No banner appears above the textbox locally — visually identical to remote-control-off state
5. Continue working — agent fans out subagents, edits files, etc.
6. Phone shows messages syncing through some point in the conversation, then stops mid-session, with subsequent assistant turns and tool results never appearing on the phone
7. Local UI eventually crashes with Unhandled case: [object Object] red banner (#59013)

Log evidence (%APPDATA%\Code\logs\<session-stamp>\window1\exthost\Anthropic.claude-code\Claude VSCode.log)

The entire session log contains exactly two remote.control / remote_control matches:

Line 2626  | 2026-05-14 21:15:50  | Received message from webview:
                                    {\"type\":\"toggle_remote_control\",\"enable\":true}
Line 19608 | 2026-05-14 21:56:47  | (the user message reporting the bug)

There is no intermediate log entry for any of:

• remote_control_enabled / remote_control_started / remote_session_established
• pairing_complete / handshake / similar acknowledgment
• Any [ERROR] or [WARN] from the remote-control subsystem
• Any failure response that would explain why the banner didn't render

The toggle request landed and was silently absorbed.

Expected behavior

Either:

• Success: banner renders above textbox AND a remote_control_* confirmation event is logged AND phone-side connects — all three or none
• Failure: explicit error surface (toast, log entry, or rejection of the toggle) that tells the user the session didn't establish

The current behavior is the worst of both: phone thinks it's connected, local doesn't, no error explains the divergence.

Proposed root-cause direction (speculative)

The remote-control toggle handler likely uses a fire-and-acknowledge protocol where:

• Step A: webview sends toggle_remote_control { enable: true }
• Step B: extension host registers the local-side bridge and emits a banner-render event
• Step C: extension host establishes the remote-bridge connection and emits a remote_session_established event
• Step D: phone-side connects and acknowledges

In my repro, Steps B and C silently failed but Step D succeeded — the phone-side registration path appears to be partially decoupled from the local-side acknowledgment. Worth checking whether B/C swallow exceptions (consistent with the lack of any error log) versus genuinely no-op'ing on some condition the toggle handler doesn't handle.

Why this matters beyond cosmetics

• Discoverability: users who see the inline link (Step A succeeded) will assume the session is established — they have no signal that B/C didn't run.
• Streaming pipeline pollution: when downstream events try to fan out to the half-broken bridge, the bridge consumer hits unhandled-case errors that crash the local UI (#59013).
• State recovery is opaque: there's no documented way to detect / clear the half-state without restarting the extension.

Mitigation that worked

After observing the crashes, restarting the Claude Code extension (Command Palette → \"Developer: Reload Window\") cleared the half-state. The phone-side connection also dropped after reload.

Environment

• Claude Code VS Code extension: 2.1.141
• VS Code on Windows 11
• Model: Opus 4.7 (1M context)
• Operating system: Windows 11 Home 26200

Related

• #59013 — Unhandled case: [object Object] after stream stalls. The correlated UI-crash that fired 3× in this same session, possibly amplified by this half-state.
• Existing remote-control bugs (#33041, #54838, #57286, etc.) describe disconnects, init failures, or post-success disconnect banners — none cover this exact \"silent toggle absorption + phone-side success\" split-brain shape.