update: /update fails on Windows when bash resolves to the WSL launcher #52815

Summary

/update (and the equivalent opencode upgrade) fails on Windows whenever the bash on PATH is the WSL launcher instead of Git Bash. OpenCode downloads its POSIX installer script and executes it with a bare bash command, passing a native Windows path as the script argument. The WSL launcher mangles that path and cannot read Windows files, so the update aborts with a confusing "No such file or directory" error that does not point at the real cause.

Environment

• opencode version: 2.0.21 (channel latest)
• OS: Windows_NT 10.0.26200 (win32 x64)
• Terminal: Unavailable: terminal environment variables are not set
• Shell: C:\WINDOWS\system32\cmd.exe
• Install/channel: curl installer, installed to C:\Users\<user>\.opencode\bin\opencode.exe, channel latest
• Active plugins: @mohak34/opencode-notifier@latest, opencode-conductor-plugin

Git for Windows is installed (D:\Program Files\Git), but a stock Git for Windows install only adds Git\cmd to PATH, which contains git.exe but not bash.exe. bash therefore resolves to C:\Windows\system32\bash.exe, the WSL interop launcher.

Reproduction

1. On Windows, install Git for Windows and opencode via the curl installer (curl -fsSL https://opencode.ai/v2/install | bash).
2. Note that Git\cmd (no bash.exe) is on PATH, and that C:\Windows\System32\bash.exe (the WSL launcher) is on PATH.
3. Run /update in the TUI, or opencode upgrade from the CLI.

Expected Behavior

The update completes and installs the new version.

Actual Behavior

The update fails. From ~/.local/share/opencode/log/opencode.log:

message="spawning process" command=curl args="[\"-fsSL\",\"-o\",\"C:\\Users\\<user>\\.cache\\opencode\\update-XXXXXX\\install\",\"https://opencode.ai/v2/install\"]" role=cli
message="spawning process" command=bash args="[\"C:\\Users\\<user>\\.cache\\opencode\\update-XXXXXX\\install\",\"--version\",\"<version>\",\"--no-modify-path\"]" role=cli

The download succeeds, then the bash invocation prints:

/bin/bash: C:Users<user>.cacheopencodeupdate-XXXXXXinstall: No such file or directory

Two distinct problems compound here:

1. Backslashes are eaten. The native Windows path C:\Users\<user>\.cache\opencode\update-XXXXXX\install arrives at the WSL launcher with its backslashes consumed as escape characters, producing the nonsense name C:Users<user>.cacheopencodeupdate-XXXXXXinstall.
2. Even a well-formed path fails. Passing forward slashes (C:/Users/<user>/...) still fails, because WSL resolves paths inside the Linux filesystem and that path does not exist there (it would need /mnt/c/...).

Running the identical script with Git Bash works and reports MINGW64_NT-10.0-26200, which https://opencode.ai/v2/install maps to os="windows" — the installer's supported Windows path (it installs opencode.exe, writes the opencode2.cmd shim, etc.). So the installer itself supports Windows; only the interpreter OpenCode picks is wrong.

Additional Context

Workaround (verified): put D:\Program Files\Git\bin on PATH ahead of C:\Windows\system32 so bash resolves to Git Bash. The update then completes successfully and installs the target version.

Note that the User PATH is appended after the Machine PATH by Windows, and C:\Windows\system32 lives in the Machine PATH. Adding Git\bin to the User PATH therefore does not fix this — it must precede C:\Windows\system32 in the Machine PATH, which requires elevation. This is not obvious and easy to get wrong.

Suggestions, in rough order of preference:

• Resolve the installer interpreter more carefully on Windows (e.g. probe for Git Bash / MSYS2 explicitly, or check that the chosen bash can actually execute the target path) instead of relying on bare bash name resolution.
• Consider shipping a PowerShell installer (e.g. https://opencode.ai/v2/install.ps1, which currently 404s) and use it for the native Windows path, so updating does not depend on any POSIX toolchain being present.
• Failing that, improve the error message: the current output names a garbled path and gives no hint that the wrong bash was selected. Something like "no usable bash found; WSL's bash.exe cannot run the Windows installer - install Git for Windows or use a POSIX shell" would have made this self-diagnosing.

Frequency: 100% reproducible on this machine, on every update attempt while bash resolves to the WSL launcher.

Unrelated observation: there is a stale [email protected] npm installation at %APPDATA%\npm\node_modules\opencode-ai with leftover opencode1.cmd/opencode1.ps1 shims in C:\Users\<user>\.opencode\bin. Because opencode-ai@latest on npm is still 1.18.34 (the v1 line), opencode upgrade --method npm would downgrade an existing v2 install, so it is not a usable fallback here.