[BUG] VS Code extension ignores `remoteControlAtStartup` — re-filing after #41036 and #53647 were auto-misrouted by dup-bot

Preflight Checklist

• [x] I have searched existing issues to make sure this isn't a duplicate
• [x] This is a single bug report (not bundling multiple bugs)
• [x] I am using the latest version of Claude Code

Note to maintainers (please read before any auto-dup routing)

This bug has been filed twice already. Both times the duplicate-detection bot has auto-routed it to #29929 (a CLI /config persistence bug — unrelated to the VS Code extension's launch path):

• #41036 (filed 2026-03-30) — auto-closed 2026-04-03 as dup of #29929, auto-locked 2026-04-13. Filer pointed out the misrouting in a comment; thread was locked before triage.
• #53647 (filed 2026-04-26, includes code-level reverse-engineering of the exact missing call site) — auto-closed 2026-04-30 as dup of #41036, auto-locked 2026-05-07.

Both were closed by github-actions[bot]. Zero human-team engagement on any thread.

The enhancement request #37589 (15 👍, currently stale) covers a separate proposed setting name. This issue is about the existing, documented remoteControlAtStartup field already being silently ignored by the VS Code extension launch path.

Requesting human triage. Happy to test a fix against the Windows 11 build.

What's wrong?

remoteControlAtStartup: true in ~/.claude/settings.json auto-starts the Remote Control bridge for terminal CLI sessions, but is silently ignored by the VS Code extension. Every VS Code panel session requires manually typing /remote-control to enable mobile/web remote access.

Root cause (credit to @Ashkaan in #53647, binary v2.1.120 — still present in v2.1.143)

The bridge auto-start gate in the claude binary feeds into replBridgeEnabled:

replBridgeEnabled: (tY || RD)
// tY = !resume && !continue && !inRemoteSession && (cliFlag || zi() || daemonFlag)
// zi() reads remoteControlAtStartup from settings.json or ~/.claude.json

The field is replBridgeEnabled — it only takes effect for interactive REPL sessions. The VS Code extension launches claude in print/SDK mode (--input-format stream-json --output-format stream-json --print), which has no REPL, so the gate is never reached.

Separately, the VS Code extension has its own per-channel remote-control state (remoteControlState in extension.js) and an IPC handler toggleRemoteControl(channelId, enable). The handler is invoked only by the webview's UI toggle. Nothing in claudeLaunched(V) reads remoteControlAtStartup and auto-calls toggleRemoteControl(V, true).

What should happen

When remoteControlAtStartup: true, the VS Code extension should call toggleRemoteControl(channelId, true) after claudeLaunched(channelId), matching the CLI's behavior.

Steps to reproduce

1. Set "remoteControlAtStartup": true in ~/.claude/settings.json
2. Run claude in PowerShell — bridge auto-starts, session appears at claude.ai/code ✅
3. Open a new conversation in the VS Code extension panel (native UI, not claudeCode.useTerminal) — bridge does NOT auto-start ❌
4. Manually clicking the Remote Control toggle in the webview, or typing /remote-control, works — confirming the feature itself is supported per-session

Use case

I run a Claude Code-based EA inside the EA project directory and want it always available via the Claude mobile app, so I can voice-talk to it on a walk. The CLI path works perfectly. The VS Code extension path requires walking back to the keyboard every time the panel restarts to type /remote-control, which defeats the "always on" framing.

Workaround (now treating as the design until fixed)

Run claude remote-control --name "EA" in VS Code's integrated terminal as a persistent server. The graphical panel continues to work alongside it; the terminal-resident server is the actual mobile-accessible Remote Control endpoint. Verified working on Windows 11 / v2.1.143.

Claude Code Version

CLI binary 2.1.143, VS Code extension 2.1.143

Platform

Anthropic API (Claude Pro)

OS / Shell

Windows 11 Home 10.0.26200 / VS Code with integrated PowerShell

Related

• #37589 — enhancement request for a remoteControlEnabled setting (currently stale, 15 👍)
• #41036 — same bug, auto-closed as wrong dup, locked
• #53647 — same bug refiled with code-level evidence, auto-closed as wrong dup, locked
• #29929 — actually about CLI /config persistence (different bug, repeatedly mis-routed here)
• #28951 — about /rc not available in VS Code at all (the manual path is now fixed; auto-start is not)