[Bug]: One-click provider update fails with spawn NotFound when the app inherits a stale Windows PATH #7406

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

packages/contracts or packages/shared

Steps to reproduce

1. On Windows, install Node machine-wide so it lands in C:\Program Files\nodejs and registers in the Machine registry PATH. The default Node.js installer and winget install OpenJS.NodeJS both do this.
2. Without signing out, launch the desktop app from an Explorer session that started before the install.
3. Open settings for an npm-managed provider that has an update available and click the update action.

The failure also reproduces at the code level without the app. With process PATH limited to C:\Windows\System32, resolveWindowsEnvironment in packages/shared/src/shell.ts returns a PATH that still lacks the Node directory, resolveSpawnCommand("npm", [...]) falls back to the bare string npm with shell: false, and the spawn fails.

Expected behavior

The update runs npm, or fails with a message that says npm was not found.

Actual behavior

The update fails before npm runs. The toast reads Provider update failed, and the detail line reports that npm could not be spawned. The full text is in the logs below.

Impact

Minor bug or occasional failure

Version or commit

main @ a4cc136

Environment

Windows 11 Pro build 26200, Node 24.18.1, npm 12.0.2, Windows PowerShell 5.1 and pwsh 7 both present

Logs or stack traces

Provider update failed
Failed to run update command npm: NotFound: ChildProcess.spawn (npm install -g --allow-scripts=@openai/codex @openai/codex@latest)

Workaround

Sign out and back in, or relaunch the app from a shell opened after the Node install, so the app inherits the updated PATH.

Analysis

The root cause is in the Windows PATH repair. buildWindowsEnvironmentCaptureCommand probes PowerShell with an unscoped [Environment]::GetEnvironmentVariable('PATH'). The unscoped read returns the PATH the probe process inherited, and the probe inherits it from the app itself, so the repair can never recover a directory the user registered after the app's parent process started. On Windows the durable PATH lives in the registry, in the Machine and User scopes, and the probe reads neither. The profile-loading retry has the same limit. A PowerShell profile rarely sets PATH, and the registry entries are what is missing.

With npm invisible, resolveSpawnCommand cannot find npm.cmd, falls back to bare npm with shell: false, and the spawn fails with NotFound. Resolution has to succeed for this to work. The .cmd branch of resolveSpawnCommand routes through the shell correctly, but it is never reached when the executable cannot be found.

Suggested fix

Read the Machine and User registry scopes in the PATH capture and join them behind the process value. The process value staying first preserves the existing resolution order, and mergePathValues already drops the duplicates. A pull request with that change and a pinned test is ready to open if wanted.