Install script on WSL2 treats the Windows npm shim as an existing install and skips the native Linux install

[yxloveql]

Install script on WSL2 treats the Windows npm shim on PATH as an existing install and silently skips the native Linux install

Environment

WSL2 (Ubuntu, systemd) on a Windows host where opencode is also installed on Windows via npm (opencode-ai global). Because WSL interop appends the Windows PATH, opencode resolves inside WSL to /mnt/c/Users/<win-user>/AppData/Roaming/npm/opencode — the POSIX shim that execs the Windows package.

Repro

1. In a fresh WSL shell run:
   curl -fsSL https://opencode.ai/install | bash -s -- --version 1.18.15
2. The script prints something like Version 1.18.15 already installed and exits.
3. No native binary is placed in ~/.opencode/bin (the script's expected location); ~/.opencode/bin/opencode does not exist afterwards.
4. opencode --version still succeeds because it runs the Windows copy through interop — so the failure is silent.

Impact

Users believe opencode is natively installed in WSL. In reality every invocation executes the Windows binary under WSL with the Linux $HOME/XDG data dirs — a Windows build writing session/DB state into Linux directories, which can produce mixed-state/schema issues, and anything expecting the native binary path (~/.opencode/bin/opencode, editors, launchers) breaks.

Suggested fix

Before the "already installed" early exit, resolve command -v opencode and treat it as not installed when it points under /mnt/ (or when the resolved file is a Windows PE / has a sibling .cmd/.ps1). In that case proceed with the native install, or abort with a clear message explaining the WSL-interop shim situation.

Secondary observation

Installing via npm (opencode-ai + the platform optional dependency opencode-linux-x64) installs the binary as bin/opencode.exe even on Linux (the package bin target name) — cosmetic, but part of the same cross-platform detection confusion.

No personal data included. Happy to provide more details if needed.