fix(cli): pick a Windows bash for the curl installer - #51038

Issue for this PR

Fixes #50924 (#50924)
Relates #50886

Type of change

• Bug fix

What does this PR do?

The curl upgrade downloads https://opencode.ai/v2/install and runs it with a bare bash, which is a
different program on different Windows machines. Git Bash runs the downloaded script fine. The WSL entry
point at C:\Windows\System32\bash.exe eats the backslashes in the path and exits 127, which is the
failure in #50924:

/bin/bash: C:Usersming.cacheopencodeupdate-29WiNminstall: No such file or directory

Handing that same bash a converted /mnt/c/... path is worse, not better: the script then runs, and
because install installs whatever uname -s reports, it pulls a Linux binary into the Windows install
directory. So the thing to choose is the shell, not the path spelling.

curlShell asks each candidate which system it runs on and takes the first that reports
MINGW/MSYS/CYGWIN, the same classification install uses: OPENCODE_GIT_BASH_PATH (already documented
in packages/web/src/content/docs/cli.mdx, previously unused here), every hit from where.exe bash,
%ProgramFiles%\Git\bin\bash.exe, then bash. If none of them is a Windows bash the upgrade stops with
a message naming what to install instead of an exit-127 path. Non-Windows behavior is unchanged, still
bash with no extra spawns.

Correction (2026-09-25): I previously hedged that #50950 might have a second cause because its error keeps the backslashes, which is how Git Bash words a missing file. @jpgomezv disproved that with the script verified present: under a WSL bash, bash "C:\Users\<name>\.cache\opencode\update-XXXX\install" --version still fails with the backslashes intact. So both wordings come from a WSL entry point, and which one you see depends on which stub answers - System32\bash.exe on some machines, the WindowsApps alias on others. No deleted file is needed to explain #50950, and this PR is meant to cover both reports.

How did you verify your code works?

Not with the repo's checks: there is no Bun on this machine, so bun typecheck and bun run check did
not run and the module itself was never executed. What I did verify, on Windows 11 26200 with Git for
Windows and WSL both installed:

• Git Bash runs a script placed at C:\Users\<name>\.cache\opencode\update-nikDwW\install: exit 0, uname -s = MINGW64_NT-10.0-26200. So the path spelling is not the problem.
• C:\Windows\System32\bash.exe with that same argument: exit 127 with the stripped-path message quoted above. With a /mnt/c/... argument: exit 0 and uname -s = Linux, the wrong-platform outcome described above.
• The candidate order and the uname -s filter, ported to plain Node (same argv spawn semantics, no shell), in four setups: Git on PATH picks Git Bash; Git installed but absent from PATH recovers it from Program Files, which is the case that fails today; WSL-only reaches the new error; OPENCODE_GIT_BASH_PATH is honored.

What would close the remaining gap: bun typecheck in packages/cli, and one real
opencode upgrade --method curl from a shell whose PATH has no Git entry.

Screenshots / recordings

CLI rather than UI. Before, on a machine where bash is the WSL entry point (from #50924):

■  The OpenCode installer failed
■  /bin/bash: C:Usersming.cacheopencodeupdate-29WiNminstall: No such file or directory

After, where no Windows bash is reachable - this is the text the new branch emits, not a captured run:

■  The OpenCode installer needs Git Bash
■  Install Git for Windows or set OPENCODE_GIT_BASH_PATH, then run opencode upgrade again.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

"Tested locally" above means what the section says it means: the shell choice and the candidate order were exercised on this machine against real Git Bash and real WSL bash, but the module itself was not run and the repo checks did not run.