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

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.