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

Proposed Solution

---
title: "VS Code extension ignores remoteControlAtStartup"
issue: https://github.com/anthropics/claude-code/issues/62149
repo: anthropics/claude-code
issue-num: 62149
type: bug-fix
area: ide, remote
platform: vscode, windows
competition: zero (0 comments, filed twice before as #41036/#53647)
quote: $2,000-$3,000
---

claude-code #62149 — VS Code Extension Ignores remoteControlAtStartup

📋 Issue Summary

| Field | Value |
|-------|-------|
| Repository | anthropics/claude-code |
| Issue | #62149 |
| Title | [BUG] VS Code extension ignores remoteControlAtStartup |
| Type | Bug (area:ide, platform:vscode, platform:windows) |
| Has Repro | Yes |
| Competition | Zero (0 comments; previously auto-misrouted as dupes #41036, #53647) |
| Estimated Quote | $2,000–$3,000 |

---

🔍 Root Cause Analysis

The Feature: remoteControlAtStartup

The remoteControlAtStartup setting in ~/.claude/settings.json is designed to automatically enable Remote Control when a Claude Code session starts. This lets users control their local Claude Code session from claude.ai/code (web UI) or the Claude mobile app without manually running /remote-control each time.

// ~/.claude/settings.json
{
  "remoteControlAtStartup": true
}

Expected behavior: Every new Claude Code session (CLI or IDE) should auto-enable Remote Control on launch.

Actual behavior:

• ✅ CLI sessions — Remote Control auto-enables correctly
• ❌ VS Code extension sessions — Setting is silently ignored; Remote Control never starts

Architecture: How Remote Control Gets Enabled

The Remote Control enablement path differs between CLI and VS Code:

┌─────────────────────────────────────────────────────────────────┐
│                    CLI Session (interactive REPL)               │
│                                                                 │
│  claude (interactive)                                          │
│    → REPL loop starts                                          │
│    → replBridgeEnabled gate evaluated                         │
│    → remoteControlAtStartup=true → toggleRemoteControl(true)  │
│    ✅ Remote Control active                                    │
└─────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────┐
│              VS Code Extension Session (SDK/print mode)         │
│                                                                 │
│  VS Code extension launches claude with:                       │
│    --input-format stream-json                                  │
│    --output-format stream-json                                 │
│    --print                                                     │
│                                                                 │
│    → No REPL loop (print/SDK mode)                            │
│    → replBridgeEnabled gate NEVER reached                     │
│    → remoteControlAtStartup setting never read                 │
│    → toggleRemoteControl() never called                        │
│    ❌ Remote Control inactive                                  │
│                                                                 │
│  VS Code extension has its own IPC handler:                    │
│    toggleRemoteControl(channelId, enable)                      │
│    but nothing in claudeLaunched(V) reads the setting          │
│    and auto-calls it                                           │
└─────────────────────────────────────────────────────────────────┘

Confirmed Root Cause (Binary Analysis — @Ashkaan, #53647)

Binary analysis of the compiled claude.exe by @Ashkaan confirmed:

1. replBridgeEnabled gate is REPL-only: The gate that reads remoteControlAtStartup and calls toggleRemoteControl() lives inside the interactive REPL loop. It is never reached when claude runs in print/SDK mode (--input-format stream-json --output-format stream-json --print).

1. VS Code extension uses print/SDK mode: The VS Code extension launches claude with --print and JSON streaming flags, which bypasses the REPL entirely. The process communicates via stdin/stdout JSON-RPC rather than an interactive terminal loop.

1. Missing IPC bridge: The VS Code extension has its own toggleRemoteControl(channelId, enable) IPC handler, but the claudeLaunched(V) lifecycle hook does not:

• Read remoteControlAtStartup from ~/.claude/settings.json
• Call toggleRemoteControl(channelId, true) when the setting is true

1. No auto-enable path for non-REPL sessions: There is no code path that reads remoteControlAtStartup and enables Remote Control outside the REPL loop. This affects VS Code, any other IDE extension, and potentially headless/SDK integrations.

Why This Was Filed Three Times

The issue was filed as #41036, #53647, and now #62149. The first two were auto-misrouted by the dup-bot because:

• The dup-bot likely matched them to each other (creating a circular false positive)
• Neither had a clear solution comment, so the bot never resolved the chain
• The root cause (binary-level REPL gate) was not publicly known until @Ashkaan's analysis

---

🛠️ Proposed Fix

Fix Option A: VS Code Extension Reads Setting on Launch (Recommended)

Location: VS Code extension's claudeLaunched(V) lifecycle handler

Approach: When the VS Code extension launches a Claude Code session, read remoteControlAtStartup from the user's settings and auto-call toggleRemoteControl() if enabled.

// src/vscode-extension/extension.ts (VS Code extension)

import * as fs from 'fs';
import * as path from 'path';

interface ClaudeSettings {
  remoteControlAtStartup?: boolean;
  // ... other settings
}

function loadClaudeSettings(): ClaudeSettings {
  const settingsPath = path.join(
    process.env.HOME || process.env.USERPROFILE || '',
    '.claude',
    'settings.json'
  );
  try {
    const raw = fs.readFileSync(settingsPath, 'utf-8');
    return JSON.parse(raw);
  } catch {
    return {};
  }
}

async function claudeLaunched(channelId: string, session: ClaudeSession) {
  // ... existing launch logic ...

  // NEW: Read remoteControlAtStartup and auto-enable if set
  const settings = loadClaudeSettings();
  if (settings.remoteControlAtStartup === true) {
    await toggleRemoteControl(channelId, true);
  }
}

Why this is the right fix:

• Minimal code change (localized to extension lifecycle)
• Respects the user's explicit setting in settings.json
• No changes needed to the claude binary itself
• Works with the existing toggleRemoteControl(channelId, enable) IPC handler

Fix Option B: Bridge Auto-Start Gate in SDK/Print Mode (Alternative/Complementary)

Location: claude binary — session initialization code

Approach: Move the remoteControlAtStartup read-and-enable logic out of the REPL-specific path and into the session initialization code that runs regardless of mode (REPL, print, SDK).

// Inferred location in claude binary: src/session/init.ts

function initializeSession(config: SessionConfig) {
  // ... existing initialization ...

  // Move REPL-gated logic to session init (runs for ALL modes)
  const settings = loadSettings();
  if (settings.remoteControlAtStartup === true) {
    // This path currently only runs in REPL mode;
    // extend it to run for print/SDK mode too
    enableRemoteControlBridge(config.channelId);
  }

  // ... rest of init ...
}

Trade-offs:

• More invasive (requires binary changes)
• Benefits all non-REPL consumers (not just VS Code)
• Risk of enabling Remote Control for headless/CI use cases where it shouldn't be enabled
• Would need a guard to prevent auto-enabling in non-interactive CI environments

Recommended: Fix A + Guard in Fix B

Implement Fix A as the primary solution (VS Code extension reads setting). As a complementary fix, add a session-init-level remoteControlAtStartup handler in the binary (Fix B) with a guard that only auto-enables when an IDE channel is detected:

// Guard: only auto-enable in IDE/interactive contexts, not CI/headless
function shouldAutoEnableRemoteControl(sessionConfig: SessionConfig): boolean {
  const settings = loadSettings();
  if (!settings.remoteControlAtStartup) return false;

  // Don't auto-enable in pure CI/headless mode
  if (sessionConfig.mode === 'print' || sessionConfig.mode === 'sdk') {
    // Only enable if launched from a known IDE extension
    return !!sessionConfig.ideChannelId;
  }
  return true; // REPL mode: always honor the setting
}

---

📁 Files to Modify

| File | Component | Change |
|------|-----------|--------|
| vscode-extension/src/extension.ts | VS Code extension | In claudeLaunched(V), read remoteControlAtStartup from ~/.claude/settings.json and call toggleRemoteControl(channelId, true) |
| src/session/init.ts (inferred) | Claude binary | Move remoteControlAtStartup check from REPL loop to session init, with IDE-channel guard |
| src/remote-control/bridge.ts (inferred) | Claude binary | Ensure replBridgeEnabled gate also applies to SDK/print mode when IDE channel is present |

---

✅ Testing Plan

Test 1: VS Code Extension with remoteControlAtStartup: true

1. Set "remoteControlAtStartup": true in ~/.claude/settings.json
2. Open a workspace in VS Code
3. Launch Claude Code via the VS Code extension
4. Verify: Remote Control is automatically enabled (check claude.ai/code for active session)
5. Verify: No manual /remote-control command needed

Test 2: VS Code Extension with remoteControlAtStartup: false

1. Set "remoteControlAtStartup": false (or omit) in ~/.claude/settings.json
2. Launch Claude Code via VS Code extension
3. Verify: Remote Control is NOT auto-enabled
4. Verify: User can manually enable via /remote-control if desired

Test 3: CLI Session Unchanged

1. Set "remoteControlAtStartup": true
2. Launch claude in terminal (interactive REPL)
3. Verify: Remote Control auto-enables (existing behavior preserved)

Test 4: Headless/CI Mode Not Affected

1. Set "remoteControlAtStartup": true
2. Run claude --print "hello" or claude --input-format stream-json --output-format stream-json
3. Verify: Remote Control is NOT auto-enabled (no IDE channel detected)
4. Verify: Session completes normally without attempting to bind to Remote Control

Test 5: Windows Platform

1. Repeat Tests 1–4 on Windows (the issue has platform:windows label)
2. Verify: Path resolution for ~/.claude/settings.json works on Windows (%USERPROFILE%\.claude\settings.json)

Test 6: Settings Hot-Reload

1. Launch VS Code session with remoteControlAtStartup: false
2. Change setting to true while session is running
3. Verify: New sessions honor the updated setting

---

📊 Impact Assessment

User Impact

• Affected users: All VS Code extension users who rely on remoteControlAtStartup: true
• Severity: Medium-high — feature silently fails, users must manually enable Remote Control every session
• Scope: Cross-platform (Windows confirmed, likely affects macOS/Linux too)

Risk Assessment

• Low risk: Fix A is a localized change in the VS Code extension lifecycle
• No breaking changes: Only adds behavior when setting is explicitly true
• Backward compatible: Users without the setting are unaffected
• CI/headless safety: Guard in Fix B prevents unintended Remote Control activation in non-IDE contexts

Competitive Positioning

• Zero competition: 0 solution comments on the issue
• Filed 3 times: #41036, #53647, #62149 — indicates persistent, unresolved pain
• Has repro: Issue includes reproduction steps
• Binary analysis available: @Ashkaan's analysis in #53647 provides confirmed root cause

---

💰 Pricing Rationale

| Factor | Assessment |
|--------|-----------|
| Has repro | Yes — step-by-step reproduction included |
| Root cause known | Yes — confirmed by binary analysis (@Ashkaan, #53647) |
| Fix complexity | Low-Medium — localized extension change + optional binary gate |
| Competition | Zero (0 comments) |
| User impact | Medium — affects all VS Code users with the setting |
| Risk | Low — additive change, backward compatible |

Quote: $2,000–$3,000

This is well-documented with confirmed root cause, making it a straightforward fix. The price reflects the value of a complete, tested solution for a persistent bug that has been filed three times.

---

📝 Notes

• The VS Code extension is distributed separately via the VS Code marketplace; changes may require a separate extension version bump
• The binary (Fix B) requires changes to the compiled claude binary; coordinate with the core team for integration
• Consider adding telemetry to track remoteControlAtStartup usage and auto-enable success rate
• Related issues to monitor: #61890 (Remote Control "not yet enabled" persists), #61832 (Remote Control 404 on session events)

Confirming on macOS — same root cause, same fix seam, verified end-to-end.

Reproduced on macOS 26.5 / Apple Silicon, VS Code extension anthropic.claude-code-2.1.160-darwin-arm64, Max subscription. remoteControlAtStartup: true in ~/.claude/settings.json is honored by the terminal CLI but ignored by the VS Code panel launcher — every panel session still needs a manual /remote-control.

@Ashkaan's root cause (from #53647) is still present in 2.1.160:

• In extension.js, remoteControlAtStartup appears only in the settings schema (...boolean().optional().describe(...)) and is never read anywhere else.
• toggleRemoteControl(channelId, true) exists but is only invoked by the webview UI toggle (the toggle_remote_control IPC handler) — never from the claudeLaunched(channelId) lifecycle.

I verified the proposed Fix A end-to-end by patching the real claudeLaunched(z) impl to read remoteControlAtStartup from ~/.claude/settings.json and, when true, call this.toggleRemoteControl(z, true) (deferred ~4s so the session is initialized). Result: every VS Code panel session now auto-connects to claude.ai / the mobile app with the native webview UI fully intact — no manual /remote-control.

So Fix A is correct and low-risk: it's just the missing claudeLaunched -> toggleRemoteControl call. Happy to share the exact patch diff or test a real fix against the macOS build.

Confirming this on Claude Code 2.1.107, Windows 11, VS Code native extension.

• ~/.claude/settings.json (global user scope) contains "remoteControlAtStartup": true.
• No managed-settings.json, no project/local override of the key, disableRemoteControl not set.
• Reloaded the VS Code window (and fully restarted the extension) — Remote Control still does not auto-start; nothing appears on the mobile app.
• Running /remote-control manually in the same session works correctly every time, so auth (claude.ai OAuth) and mobile pairing are fine — only the auto-start-on-launch path is affected.

Matches the root cause described above: the extension launches in print/SDK mode and never hits the REPL gate that reads remoteControlAtStartup. +1 for Fix Option A (read the setting in the extension's launch lifecycle and call toggleRemoteControl() when enabled).

Still reproduces on v2.1.187 (Windows 11, VS Code extension)

Confirming this is still present on the latest build — not fixed as of 2.1.187.

Environment

• Claude Code CLI: 2.1.187
• VS Code extension: anthropic.claude-code-2.1.187-win32-x64
• OS: Windows 11 Pro (26200)

Config (~/.claude/settings.json):

{
  "remoteControlAtStartup": true
}

Repro

1. Set remoteControlAtStartup: true in ~/.claude/settings.json.
2. Start a session in the terminal CLI → Remote Control auto-connects. ✅
3. Start a session in the VS Code extension (same settings file) → Remote Control does not auto-connect; must run /remote-control (/rc) manually each session. ❌

Expected: the extension honors remoteControlAtStartup the same way the CLI does.

Also reproduces on macOS with Claude Code v2.1.181 (VS Code native extension).

• ~/.claude/settings.json has { "remoteControlAtStartup": true } (also confirmed via /config → "Enable Remote Control for all sessions = true").
• No managed-settings.json, no project/local override — nothing overriding the value.
• New sessions in the VS Code extension do not auto-connect Remote Control; /remote-control must be run manually every session.
• The same setting is honored by the terminal CLI, so this looks specific to the VS Code extension.

Auth is a Claude Max subscription (no ANTHROPIC_API_KEY set). Note: /bug is also unavailable in the VS Code extension environment.

Confirming this still repros on v2.1.204 (macOS) — the report is v2.1.143, so it's persisted across ~60 builds — and adding two data points beyond the original repro:

1. Also broken via the org Managed settings path, not just local settings.json. Setting remoteControlAtStartup: true in the Team/Enterprise Managed settings (settings.json) editor at claude.ai/admin-settings/claude-code propagates to ~/.claude/remote-settings.json on member machines, and the VS Code extension still ignores it. So enterprise admins can't enable this org-wide for IDE users either — there's no admin toggle for it, and the managed setting is silently dropped by the extension launch path.
2. The Claude Desktop app auto-connects correctly on the same machine / account / settings — only the VS Code extension ignores it. Consistent with the root cause above: Desktop/CLI honor the startup gate, but the extension's claudeLaunched(...) never calls toggleRemoteControl(..., true).

(Aside: ~/.claude/policy-limits.json shows defaults.remote_control_at_startup: false, but that does not block the Desktop app on the same machine, so it isn't the cause — reinforcing that this is purely the VS Code extension launch-path gap, not a policy/precedence issue.)

Same ask: human triage, and have the VS Code extension honor remoteControlAtStartup in its launch path. Happy to test a fix on macOS.

Confirming this on v2.1.207 (Windows, VS Code extension), still broken.

Additional data point beyond settings.json: running /config remoteControl=true inside the VS Code extension returns "Set Enable Remote Control for all sessions to true", but a new session started afterward still does NOT auto-connect — it never appears in the mobile app. So even the in-app toggle path is ignored, not just the hand-edited remoteControlAtStartup key. Manual /remote-control per session works, and the CLI (claude in a terminal) auto-connects fine with the same setting — consistent with the print/SDK-mode root cause described above (the REPL-only gate is never reached when the extension launches claude with --print/stream-json).

Workaround for others landing here: run claude in the VS Code integrated terminal instead of the extension panel to get auto Remote Control.

Still reproduces on v2.1.210 (Windows 11 / WSL2, VS Code native extension, Claude Max). Thread's newest confirmation is 2.1.207, so adding a current data point plus one new finding.

Ruling out stale config. Rather than just checking the setting, I cycled it: toggled off via the /config UI, restarted VS Code, toggled on, restarted again. Verified afterward that both ~/.claude/settings.json and ~/.claude.json hold remoteControlAtStartup: true. Then opened a panel session and did not type /remote-control. No session on mobile, no RC UI. The same settings auto-connect fine running claude in a WSL terminal on the same machine.

Also confirms @linzoie's point that the in-app toggle path is affected, not just the hand-edited key: the toggle's own definition reads and writes remoteControlAtStartup, so it's a new front-end over the same ignored setting.

New finding: the init-response plumbing exists in 2.1.210. The binary now builds an init response carrying:

d = eQb()   // resolves remoteControlAtStartup across settings scopes
p = !y$() && (d ?? PJr())
u.remote_control_auto_enable = p                                  // true here
u.remote_control_auto_on_by_default = p && d === void 0
u.ide_rc_auto_enable_gate = Ze("tengu_ide_rc_auto_enable", !1)    // false here

The CLI's own description of that last field: "IDE-side rollout kill-switch for RC auto-enable (tengu_ide_rc_auto_enable), independent of remote_control_auto_enable. Carried on the init response (not experimentGates) because the host reads it at init time... Absent (older CLI) → treat as false."

So the CLI does resolve the setting and does tell the host to auto-enable. Locally, cachedGrowthBookFeatures.tengu_ide_rc_auto_enable is false.

Speculating, but it reads like the host-side fix landed behind a rollout flag that hasn't reached general availability. If so this may be a rollout question rather than an unfixed bug, which would be useful to know either way. Happy to test against a build with the gate on.

Confirming this also reproduces on macOS (not Windows-specific):

• Claude Code v2.1.214, VS Code extension, macOS (Darwin 25.5.0)
• ~/.claude/settings.json contains "remoteControlAtStartup": true (verified on disk)
• Logged in with Claude Pro account (claude.ai login, not API key); same account on the mobile app
• Manual /remote-control in an extension session connects successfully every time
• New sessions never auto-connect — tested after "Developer: Reload Window" and after a full VS Code quit (Cmd+Q) + relaunch

So the setting is saved correctly and Remote Control itself works, but the extension never auto-enables it, consistent with the print/SDK-mode analysis above.

Reproduced on macOS 26.5 (arm64), VS Code 1.130.0, extension 2.1.219-darwin-arm64, CLI 2.1.211.

~/.claude/settings.json contains "remoteControlAtStartup": true (written both by hand and via /config remoteControl=true). New terminal sessions are fine; new sessions in the VS Code extension panel never auto-start the bridge.

The cause looks like it's on the extension side, not in settings resolution. In extension.js:

remoteControlAutoEnableOn(e){ return e.ide_rc_auto_enable_gate === true }

and the auto-start site:

if (this.remoteControlAutoEnableOn(g) && g.remote_control_auto_enable && ... ) this.toggleRemoteControl(e, true)

remote_control_auto_enable is the field the CLI computes from the setting — its own schema describes it as "Whether the CLI resolver says Remote Control should auto-enable at session start (explicit setting → policy default → GB rollout), so IDE hosts can mirror TUI behavior." That part resolves correctly here. But the extension ANDs it with ide_rc_auto_enable_gate, which comes from the server-side flag tengu_ide_rc_auto_enable, defaulting to false:

u.ide_rc_auto_enable_gate = et("tengu_ide_rc_auto_enable", !1)

So while that flag is off for an account, no local configuration can make the IDE honor remoteControlAtStartup — not user settings, not policy settings, not /config. The setting is silently inert in the panel while working in the TUI, which is exactly why this keeps getting dup-closed onto the terminal-side persistence issues (#29929, #30432): different code path, opposite symptom. The feature-override hooks that would let a user force it are also no-ops in the shipped build — setGrowthBookConfigOverride is function sIg(e,t){return}, and the CLAUDE_INTERNAL_FC_OVERRIDES reader early-returns before ever reading process.env.

Two things that would each fix the user-visible bug:

1. Have remoteControlAutoEnableOn() respect an explicitly-set remoteControlAtStartup regardless of the rollout gate — the gate is presumably there to stage the default-on behavior, which remote_control_auto_on_by_default already distinguishes (p && d === void 0). An explicit user opt-in isn't the rollout case.
2. Failing that, surface the gate state in the UI so the setting doesn't appear accepted while being ignored — /config currently reports "Enable Remote Control for all sessions: true" in a panel session where it can never take effect.

Workaround for anyone landing here: run /remote-control manually in each panel session, or use claude in a terminal where the setting is honored.

Still reproducing on VS Code extension 2.1.220 (bundled native binary 2.1.220), macOS 26 / Apple Silicon, claude.ai OAuth subscription.

Adding a current data point, plus one correction to the standing root-cause analysis — the extension's remote-control code has changed materially since @jasonnickel's 2.1.160 read, and the bug survives the change.

Environment / ruled out

• ~/.claude/settings.json → "remoteControlAtStartup": true (user scope, confirmed present)
• disableRemoteControl — not set in any settings scope
• No managed-settings.json at any standard macOS path
• No persisted per-session OFF state: remoteControlState, remoteControlAtStartupSource, remoteControlAtStartupWriteSeq are all absent from ~/.claude.json (only hasRemoteEnvironment: true and remoteControlSurfacesSeen: ["mobile"])
• Window reload and full VS Code restart — no change
• Stale PATH CLI ruled out: my PATH claude is 2.1.37, but the extension resolves its own bundled binary via asAbsolutePath(join("resources","native-binary", t)) — verified resources/native-binary/claude --version → 2.1.220. So the launched binary is well past the 2.1.203 support line; this is not a version-skew artifact.
• Typing /remote-control manually in the same panel session works every time — auth and mobile pairing are fine, only auto-start is affected.

Correction: the plumbing is no longer absent in 2.1.220

The thread's standing root cause is that remoteControlAtStartup "appears only in the settings schema and is never read anywhere else" (observed on 2.1.160). That is no longer accurate. Token counts in extension.js (2.1.220):

17  remoteControlAtStartup
 9  remoteControlAtStartupSource
 3  remoteControlAtStartupWriteSeq
 7  remoteControlAutoEnableDefault
 2  remoteControlAutoEnableOn
23  remoteControlState
 4  remoteControlStateByChannel

Reproduce with:
grep -rhoE "remoteControl[A-Za-z]*" <ext-dir>/extension.js | sort | uniq -c

So substantial RC startup machinery now exists in the extension — and the bug still reproduces on that same build.

Where I'd look next (hypothesis, not verified)

remoteControlAutoEnableDefault does not appear to be read from local settings; in 2.1.220 it is assigned from the CLI's initialization payload:

f.initializationResult().then(async (g) => {
  ...
  this.remoteControlAutoEnableDefault = g.remote_control_auto_enable;
  ...
})

If remote_control_auto_enable carries an account/server-side default rather than a projection of the local remoteControlAtStartup, the extension's auto-enable decision would never consult the user's settings.json at all — which matches the observed behaviour exactly: setting present and correct, plumbing present, auto-enable never fires.

That would also be consistent with the original replBridgeEnabled analysis: the local-settings read (zi()) gates the REPL path, while the extension launches in print/SDK mode and instead depends on remote_control_auto_enable arriving from initialization.

Worth confirming whether remote_control_auto_enable is intended to carry the local setting through, and if not, whether the fix seam is simply to have the extension OR-in its own read of remoteControlAtStartup after claudeLaunched(channelId).

Happy to run any diagnostic against 2.1.220 on macOS.