Does this issue occur when all extensions are disabled?: Yes

VS Code Version: 1.126

OS Version: Windows 11 Enterprise (26200)

Steps to Reproduce

1. On Windows, install VS Code (Stable), then install a fork such as Cursor or VSCodium that ships its own code / code.cmd shim on PATH.
2. The fork's code.cmd ends up earlier on PATH (Cursor's installer prepends its bin dir).
3. From any terminal, run:

   code --install-extension ms-python.python
   

4. The extension installs into the fork's extension directory (%USERPROFILE%\.cursor\extensions\), not VS Code's (%USERPROFILE%\.vscode\extensions\). Same command was intended to target VS Code.

The problem

code on Windows is a code.cmd shim that unconditionally invokes Code.exe --ms-enable-electron-run-as-node <cli.js> from the directory it lives in. When multiple VS Code-family editors are installed, the CLI has no way to say "install into VS Code Stable's extension host specifically" other than fully qualifying the path to the correct code.cmd.

This bites in three real workflows:

1. Automation scripts (dotfiles, install-extensions.ps1, CI runners) that assume code --install-extension targets VS Code — they silently install to whichever fork's shim won the PATH race.
2. Corp-managed machines where VS Code was installed by SCCM/Intune and a user later installed Cursor — the fork wins because it prepends PATH in user scope.
3. Fresh laptop bootstrap — code --list-extensions > extensions.txt on the old machine, Get-Content extensions.txt | ForEach-Object { code --install-extension $_ } on the new one, and the extensions land in the wrong editor.

There is no diagnostic — the fork's CLI happily accepts VS Code extension IDs. The user only notices when the extensions don't appear in VS Code.

Proposal

Add one or more of:

(a) --target flag on the CLI (code --install-extension <id> --target stable | insiders | <absolute path>) that resolves to the correct extension host regardless of which shim was invoked. Default = the shim's own host (today's behaviour).

(b) Print a one-line banner when the invoked code.cmd belongs to a non-Microsoft fork, e.g. note: 'code' resolved to Cursor at C:\Users\...\AppData\Local\Programs\cursor\bin\code.cmd. Users could then re-run with a fully qualified path. Low-risk, no config surface added.

(c) Environment variable VSCODE_CLI_TARGET=stable|insiders|/abs/path that a wrapper script or user profile can set to disambiguate. Same effect as (a) without a new flag.

Even just (b) — printing the resolved shim path when a fork owns code — would save hours of "why isn't my extension loading" debugging.

Related but not duplicate

• Feature Request: Enable/disable extensions from config file #40239 asks for a way to enable/disable extensions from a config file, not CLI targeting across forks.
• Allow to scope settings by platform #5595 asks for platform-scoped settings, not CLI target selection.

Searched issue tracker for code CLI install-extension fork, code shim PATH conflict, code --install-extension wrong binary — no existing report. Happy to close if I missed one.