What happened?

When installing Qwen Code standalone on Windows via ECS Workbench (SSM connection), qwen works in the current session but is not found in any new terminal session.

Reproduction steps:

1. Connect to a Windows ECS instance via Workbench (SSM, runs as SYSTEM user)
2. Run irm https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.ps1 | iex
3. Installation completes successfully, qwen --version works → 0.17.1
4. Open a new Workbench terminal session
5. Run qwen --version → CommandNotFoundException

Root cause: The .bat installer persists PATH via [Environment]::SetEnvironmentVariable('Path', ..., 'User') (default --path-scope user). For the SYSTEM account, this writes to HKCU\S-1-5-18\Environment\Path. However, new SSM sessions are spawned by the SSM agent service process, which loaded its environment at service start time and does not re-read registry changes — so the updated User PATH is never inherited by new sessions.

The .ps1 wrapper's Update-CurrentSessionPath only modifies the in-memory $env:Path for the current process, and the Install-CurrentCmdPathShim fallback cannot find writable PATH directories (no %APPDATA%\npm or %USERPROFILE%\.bun\bin exists for SYSTEM).

What did you expect to happen?

After installation, qwen should be available in all new terminal sessions without manual PATH configuration — especially in remote management scenarios (SSM, WinRM, scheduled tasks) where sessions run as SYSTEM.

Client information

Anything else we need to know?

Workaround: Manually copy the shim to a directory already on Machine PATH:

Copy-Item "$env:LOCALAPPDATA\qwen-code\bin\qwen.cmd" "C:\Windows\qwen.cmd" -Force

Suggested fix: When the installer detects it is running as the SYSTEM account (or elevated with no interactive user session), it should default PATH_SCOPE to machine instead of user, or additionally copy the qwen.cmd shim into a Machine PATH directory. This ensures the change is visible to all new processes regardless of how they are spawned.