VS Code extension: toggle_remote_control sent from webview, no confirmation event logged, banner-above-textbox never appears (yet phone registers session)

Summary

In the VS Code extension (not the standalone claude remote-control CLI — that's #58113), enabling remote-control via the in-chat slash command sends a toggle_remote_control {"enable":true} message from the webview to the extension host, but no confirmation event is logged afterwards. Locally:

• The link to open the phone app appears inline in the chat as expected.
• The "remote session active" banner that normally appears above the textbox is never shown.

But on the phone:

• The Claude app shows the device as connected.
• Messages from the conversation render on the phone up through the point at which the local VS Code UI starts hitting issues — i.e. the bridge is partly functional.

This split-brain ("local thinks not connected, phone thinks connected") appears to be the upstream cause of subsequent Unhandled case: [object Object] banners (#59013 / #59047 / #59067 / etc.) in the same session — see Cross-references below.

Reproduction

1. Open VS Code with the Claude Code extension on a long-running session (~200+ messages of dense tool use).
2. In the chat, invoke the slash command for remote-control (typed as /remote control or similar — exact form depends on installed slash-command set).
3. Inline link to open the phone app appears.
4. Observe: no "remote session active" banner above the textbox.
5. Open the Claude phone app, scan / select the device — phone shows it as connected.
6. Continue working in VS Code; eventually streaming events stall and Unhandled case: [object Object] red banners start appearing on each subsequent turn.
7. Phone-side message history stops at roughly the moment the half-state was established; no events after that point reach the phone.

Log evidence

%APPDATA%\Code\logs\<session>\window1\exthost\Anthropic.claude-code\Claude VSCode.log:

• Line 2626 (21:15:50): Received message from webview: {"type":"request","channelId":"...","requestId":"...","request":{"type":"toggle_remote_control","enable":true}}
• No remote_control_enabled / remote_session_established / pairing_complete / equivalent confirmation event anywhere afterward in the entire 19k-line session log.

The only other remote-control-related line in the log is the user describing the bug back to the assistant later in the same session.

Hypothesis

The extension host receives the webview's toggle_remote_control request but the success-path that would (a) log a confirmation, and (b) emit the "remote session active" banner state to the renderer, is silently failing — probably swallowing an error or short-circuiting before the renderer is updated. The phone-side bridge appears to register independently (presumably via the link the user opens), so the two sides diverge.

Impact

• User has no local indication that remote-control is in a degraded state — the missing banner is the only signal, and "missing UI" is a hard bug to notice.
• Subsequent streaming-event fanout has to deliver to a half-broken bridge consumer. When the consumer's serializer hits a payload it can't handle (e.g. the malformed code: "[object Object]" field in PostToolUse:Edit IDE diagnostics — separate issue I'm filing), the SDK terminates with sdk_stream_ended_no_result {"had_error":true} and the UI surfaces Unhandled case: [object Object].
• Recovery requires a Developer: Reload Window — the half-state is in extension-host memory.

Suggested fix direction

1. The webview-side toggle_remote_control handler should emit either a success or failure event back to the renderer so the banner state is always definite.
2. If the toggle handler swallows an error today, surface it in Claude VSCode.log as [ERROR] so users have something to act on.
3. A "remote-control state recovery" mechanism — when the SDK detects sdk_stream_ended_no_result with a remote-control bridge active, attempt to re-handshake or cleanly tear down the bridge before retrying.

Environment

• VS Code on Windows 11 (build 26200)
• Claude Code extension (latest stable as of 2026-05-14)
• Model: Opus 4.7 (1M context)
• Long session: 453+ messages of dense tool use including a 5-way parallel agent fanout

Cross-references

• #59013, #59047, #59067 — Unhandled case: [object Object] banner / stream-stall bugs that might be downstream symptoms of this half-state when remote-control is in use
• #58113 — similar phone-disconnection symptom but on the CLI claude remote-control daemon path, which is a different code path