cli: Windows curl upgrade fails when bash on PATH is WSL (backslash script path is mangled) #56486

Summary

opencode upgrade (/--method curl) on Windows downloads the install script to a Windows-style path (%USERPROFILE%\.cache\opencode\update-*\install) and executes it as bash <that path>. When the bash resolved from PATH is the WSL stub (C:\Windows\system32\bash.exe), bash cannot open a backslash path — every \ in the argument is silently swallowed — so the upgrade always fails with "No such file or directory" after a successful script download. 100% of upgrade attempts failed this way (3/3 attempts in logs).

Environment

• opencode version: 2.0.22 (bug observed here; the failing upgrade command was provided by the 2.0.22 client; not verified on newer versions)
• OS: Windows 10 Pro 10.0.19045 (x64)
• Terminal: PowerShell 7 prompt (TERM=xterm-256color, TERM_PROGRAM unset)
• Shell: interactive shell PowerShell 7.6.6 (pwsh); bash resolves to C:\Windows\system32\bash.exe → WSL2 (Linux … 6.6.87.2-microsoft-standard-WSL2). Git for Windows is installed at C:\Program Files\Git\bin\bash.exe but Git's bin dir is not in PATH.
• Install/channel: curl-installer standalone binary in %USERPROFILE%\.opencode\bin, channel latest (from log: version=2.0.22 channel=latest local=false)
• Active plugins: none found (~/.config/opencode/ contains only service.json)

Reproduction

1. Windows machine where WSL is installed and Git Bash is installed but not on PATH, so bash resolves to the WSL C:\Windows\system32\bash.exe.
2. Run opencode upgrade.
3. It picks "method: curl", announces the version jump (2.0.22 → 2.0.32), downloads the script, and fails:

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

Minimal non-opencode repro of the same failure mode (the file exists; backslashes are eaten from the argument):

PS> (Get-Command bash).Source
C:\Windows\system32\bash.exe

PS> bash "C:\Users\<user>\AppData\Local\Temp\opencode\bash-repro\install"
/bin/bash: C:Users<user>AppDataLocalTempopencodebash-reproinstall: No such file or directory

PS> bash -c "uname -a"   # this "bash" is WSL, not an MSYS/MinGW bash on the Windows FS
Linux … 6.6.87.2-microsoft-standard-WSL2 … x86_64

Expected Behavior

The upgrade should either work, or fail defensively when the resolved bash cannot run a Windows-style script path. Ideas:

• Verify the resolved bash is actually an MSYS/MinGW bash (or located at a known Windows path such as Git's bash.exe) before choosing the curl method.
• Feed the script via stdin (bash -s -- --version …) so the script file path never has to be expressed in Windows form.
• On Windows, prefer a native path: PowerShell-based installer, or reuse the existing tarball/npm flow (@opencode/cli-windows-x64) directly.

Actual Behavior

Log (role=cli) at 2026-10-17 (redacted, 3 attempts — 18:51, 18:53, 18:54 UTC — identical):

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

The curl download of the installer script succeeds instantly (<1 s), then the bash invocation fails with the mangled path shown above and the upgrade UI reports "The OpenCode installer failed". No binary is downloaded or installed.

Note: WSL bash cannot open C:\... or even C:/... paths anyway (its Windows drives are mounted under /mnt/c), so path-translation alone would not be a complete fix if the resolved bash stays WSL.

Additional Context

• Related issues: updater: windows update dialog runs bash and fails when bash is not installed #50886 (update flow runs bash at all — on machines where bash is entirely absent it fails with 'bash' is not recognized); cli: Windows curl upgrade cannot replace the running opencode.exe (locked by the TUI and background service) #52025 (once this failure is fixed, the curl method still can't replace opencode.exe on Windows because it is locked by the running TUI/service).
• Full manual upgrade workaround that worked here: fetch https://registry.npmjs.org/@opencode/cli-windows-x64/-/cli-windows-x64-<ver>.tgz, extract package/bin/opencode.exe, then rename the running ~\.opencode\bin\opencode.exe to opencode.exe.old and copy the new one in (rename of a running exe is allowed; delete/copy-over is not — see cli: Windows curl upgrade cannot replace the running opencode.exe (locked by the TUI and background service) #52025).
• PATH for the failing processes did not include Git Bash, so a bare bash name picked the Windows-provided WSL stub. An absolute probe of common Git-Bash locations would make the curl method work on this setup.