remoteControlAtStartup not honored in VS Code / Cursor extension (works in desktop app + terminal CLI)

What happened

remoteControlAtStartup: true in ~/.claude/settings.json (the "Enable Remote Control for all sessions" toggle) auto-enables Remote Control when I start a new session in the desktop app and the terminal CLI, but it is not honored in the VS Code extension or Cursor (both use the Claude Code IDE extension).

In VS Code/Cursor, Remote Control is off at session start. Running /remote-control (/rc) manually turns it on and works fine — so the feature itself works on my account; only the auto-enable-at-startup path is skipped in the IDE extension.

Expected

With remoteControlAtStartup: true, every new interactive session — including the VS Code and Cursor extensions — should auto-register a Remote Control session, matching the desktop app and terminal behavior.

Actual

• Desktop app: auto-enables ✅
• Terminal CLI: auto-enables ✅
• VS Code extension: does not auto-enable ❌ (manual /rc required each session)
• Cursor extension: does not auto-enable ❌ (manual /rc required each session)

Ruled out

• Version: 2.1.221 (past the 2.1.203 minimum that exposes the toggle)
• Auth / org policy: works in terminal + desktop on the same account, so not an entitlement/policy gate
• Telemetry/GrowthBook env flags (DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, DISABLE_GROWTHBOOK): all unset
• Settings override: remoteControlAtStartup: true is present in ~/.claude/settings.json, and no project or local settings.json/settings.local.json overrides it

Appears to be an undocumented limitation / bug: the IDE extension embeds the CLI rather than launching it as a fresh process, so the startup path that applies remoteControlAtStartup never fires.

Environment

• Claude Code v2.1.221
• macOS (Darwin 25.5.0)
• Surfaces compared: Claude desktop app, terminal CLI, VS Code extension, Cursor extension

Workaround

Type /rc once at the start of each VS Code/Cursor session.