[BUG] VS Code extension: remoteControlAtStartup silently ignored — auto-enable is implemented but disabled behind ide_rc_auto_enable_gate

Status Fixed / completed

Reported on v2.1.220

Maintainer reply None cached

Activity 3 comments · opened Jul 30, 2026 · closed Aug 5, 2026

What's Wrong?

"remoteControlAtStartup": true in ~/.claude/settings.json is honored by the terminal CLI but silently ignored by the VS Code extension — sessions started from the extension never auto-start Remote Control.

Inspecting the shipped bundle (anthropic.claude-code-2.1.220-win32-x64/extension.js), the auto-enable logic is already implemented, but it is disabled behind a server-side rollout gate:

remoteControlAutoEnableOn(e){return e.ide_rc_auto_enable_gate===!0}

and at the session-launch call site:

if (this.remoteControlAutoEnableOn(g) && g.remote_control_auto_enable
    && this.channels.get(e)?.remoteControlState.status === "disconnected"
    && /* not a teleported session */)
  this.toggleRemoteControl(e, !0)

g is the CLI's initializationResult(), whose remote_control_auto_enable field appears to reflect the user's remoteControlAtStartup setting. So the local setting does flow through this path — but nothing happens unless the ide_rc_auto_enable_gate feature flag is enabled server-side. Given that Remote Control connects fine when toggled manually (/remote-control) and the setting is set, the gate being off is the most likely cause of the silent no-op. From the user's perspective the setting just doesn't work in the IDE, with no indication why.

What Should Happen?

Sessions launched from the VS Code extension should start with Remote Control connected when remoteControlAtStartup: true is set — the same behavior as the terminal CLI. If the feature must stay gated during rollout, then either:

let the explicit local opt-in (remoteControlAtStartup: true) bypass the gate — the user has already opted in; or
document that the setting does not yet apply to IDE extension sessions, so the failure isn't silent.

Steps to Reproduce

Set "remoteControlAtStartup": true in ~/.claude/settings.json
Open a terminal session (claude) → Remote Control auto-connects (as documented; also confirmed by reporters in #41036)
Start a session from the VS Code extension (native UI) → Remote Control stays disconnected; /remote-control works when run manually

Environment

Extension: anthropic.claude-code v2.1.220 (win32-x64), native UI mode
OS: Windows 11 Pro
Auth: claude.ai subscription login (not API key)

Prior reports (all closed without reaching this diagnosis)

#41036 — same symptom; auto-closed as duplicate of #29929, which is a different bug (CLI toggle resetting), as a commenter noted before the thread was locked
#53647 — same symptom; auto-closed as duplicate of #41036
#50444 / #50059 — Desktop-app variant of the same behavior; closed as duplicate / not planned

Since all of the above are closed and locked, filing this fresh report with the bundle-level diagnosis.

View original on GitHub ↗

3 Comments

WhippyRjumi · 2 months ago

Independently reproduced on a different platform and a different VS Code fork — this is not Windows- or VS Code-specific.

Environment: VSCodium (Remote-SSH into a Linux VM), extension anthropic.claude-code v2.1.220-linux-x64, CLI 2.1.220, claude.ai Max subscription (OAuth, not API key), default api.anthropic.com, no telemetry-disabling env vars, workspace trusted.

Same gate, verbatim from the shipped linux-x64 bundle:

remoteControlAutoEnableOn(e){return e.ide_rc_auto_enable_gate===!0}

Two things I did not see covered above:

1. The extension's own settings toggle advertises this behavior and doesn't deliver it.

The webview registers a remote-control-at-startup action under Settings with these strings:

var dN = "Enable Remote Control for all sessions"
vbe = "Connect new sessions to claude.ai/code automatically so you can view and control them from the web."

Flipping it calls setRemoteControlAtStartup → applySettings({remoteControlAtStartup: e}). The extension then reads the key back only to render the toggle state:

let K = e.remoteControlAtStartup.value ?? e.config.value?.remoteControlAutoEnableDefault ?? !1;

So with remoteControlAtStartup: true the toggle displays ON, in a menu that explicitly promises new sessions will connect to claude.ai/code automatically — while the only launch path that would honor it is unreachable behind the gate. This makes the failure worse than silent: the UI actively confirms a setting it never applies. Worth considering hiding or disabling the toggle when ide_rc_auto_enable_gate is false, if the gate has to stay.

2. Workspace trust is a plausible-looking red herring, worth ruling out explicitly.

While debugging I found the workspace had hasTrustDialogAccepted: false in ~/.claude.json — notable because the VSCodium extension never prompted for trust; it launched sessions in the untrusted folder without complaint. Only running claude in the integrated terminal surfaced the trust dialog. Accepting it there set the flag to true, and IDE sessions still did not auto-connect. So trust is not the cause here, but the missing IDE prompt sends you down the wrong path, since the docs list workspace trust as a Remote Control prerequisite.

Verification note for anyone else testing this: ~/.claude/sessions/<pid>.json contains a bridgeSessionId field, but it is only reliable for CLI sessions. For extension sessions the file is written once at launch and never updated — a session bridged manually via /remote-control still showed no bridgeSessionId, because the bridge is owned by the extension host rather than the CLI child. The panel banner / claude.ai/code is the only trustworthy indicator for IDE sessions.

Manual /remote-control works fine every time, so this is purely the auto-enable path.

antrewmorrison · 2 months ago

For anyone tracking this: the fix referenced above shipped in Claude Code 2.1.224 (CLI and VS Code extension, published today). An explicit remoteControlAtStartup: true — or the extension's "Enable Remote Control for all sessions" toggle — now auto-starts Remote Control in VS Code / Cursor / VSCodium regardless of the staged rollout flag that was previously swallowing it. Update the extension to 2.1.224 and start a new session; if it still doesn't auto-connect, comment with your extension version and OS and we'll reopen.

github-actions[bot] · 19 days ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.