useInstallation.fromPath silently skips tests when VS Code is on a different Windows drive

Environment

• Windows 11
• Node.js v26.5.0
• @vscode/test-cli 0.0.10
• @vscode/test-electron 2.5.2
• VS Code 1.138.0 installed on E:\VS Code; the project lives on C:

Config

// .vscode-test.mjs
export default defineConfig({
  files: 'test/**/*.test.js',
  useInstallation: { fromPath: 'E:\\VS Code\\Code.exe' }
})

Steps to reproduce

1. Point useInstallation.fromPath at a VS Code executable that is on a different drive than the project (here E:, project on C:).
2. Run npx vscode-test.

Actual behavior

The command exits with code 0 but no tests are executed and no Mocha output is printed. In .vscode-test/user-data/logs/<session>/window1/exthost/exthost.log the extension under test is activated (activationEvent: 'api') and then the host terminates immediately:

Extension host with pid 12345 started
Extension host terminating: received terminate message from renderer
Extension host with pid 12345 exiting with code 0

Because runTests resolves with exit code 0, the failure is completely silent (CI would go green without running anything).

Expected behavior

Tests run, or at least a non-zero exit code / error is surfaced.

Workarounds that do work

• Passing the same installation through a junction on the project drive:
  C:\...\vscode-local -> E:\VS Code, then fromPath: 'C:\\...\\vscode-local\\Code.exe'.
• Omitting useInstallation entirely (a VS Code copy is downloaded onto the project drive and used).

Notes

innerRunTests (out/runTest.js) spawns the CLI resolved by resolveCliPathFromVSCodeExecutablePath (E:\VS Code\bin\code.cmd) with shell: true, adding --user-data-dir / --extensions-dir from getProfileArguments (both on C:). Something about the cross-drive combination makes that spawned process return immediately instead of hosting the tests. Keeping the executable and the profile directories on the same drive avoids it.

runTests resolving successfully while nothing ran also makes this hard to detect from a test script; an explicit "no tests were executed" check would help.

Reproduce the cross-drive setup on Windows, then start in out/runTest.js at innerRunTests and trace resolveCliPathFromVSCodeExecutablePath, shell spawning, and getProfileArguments. Compare the failing setup with the same-drive and downloaded-installation workarounds. Done means tests execute normally or runTests reports a non-zero error when no tests run.