cli: upgrade --method bun reports success on Windows but leaves the old binary in place #51386

Activity

1. github-actions

   assigned

   Hona

   on Sep 25, 2026
2. opencode-agent

   added

   2.0

   on Sep 25, 2026
3. github-actions

   added

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   and removed

   needs:complianceThis means the issue will auto-close after 2 hours.This means the issue will auto-close after 2 hours.

   on Sep 25, 2026
4. github-actions commented on Sep 25, 2026

   

   github-actionsBot

   on Sep 25, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the issue with the Bug Report description, reproduction steps, and system details!
5. Veld101 commented on Sep 29, 2026

   

   Veld101

   on Sep 29, 2026

   More actions

   Adding a real-world occurrence on Windows (x64) with 2.0.19, in case it helps pin the fix.

   After updating to 2.0.19, opencode failed to start at all:

   无法启动 'D:\Data\npm\global\node_modules\@opencode\cli\bin\opencode.exe'
   The specified executable is not a valid application for this OS platform.
   

   What was on disk:

   • bin/opencode.exe was a 229-byte shell stub, not a PE image:

     echo "Error: @opencode/cli's postinstall script was not run." >&2
     echo "" >&2
     echo "This occurs when installation scripts are disabled." >&2
     echo "Run the package postinstall script or reinstall with scripts enabled." >&2
     exit 1

   • node_modules/@opencode/cli-windows-x64 was not installed (only node_modules/@opencode/cli was present), so postinstall.mjs had nothing to link.
   • npm config get ignore-scripts returned false, so this was not npm's global config disabling scripts.
   • The global prefix D:\Data\npm\global contains bun/bunx shims, so bun may have been involved in the install path; bun does not run dependency lifecycle scripts by default.

   Reinstalling fixed it: bin/opencode.exe became a valid PE image (~206 MB, magic MZ), opencode --version reports v2.0.19, and opencode service status responds.

   One more artifact from the same update: the reinstall left an orphaned staging directory node_modules/@opencode/.cli-<id> containing a full node_modules tree (~196 MB) that was never cleaned up.

   So the failure mode here is not "the old binary stayed in place" but "the installed binary is a postinstall placeholder because the platform optional dependency / postinstall did not run". Reporting it here because the trigger surface (Windows + bun-style install) looks the same.
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report and diagnosis. Reproducing this depends on how Windows locks running executables, and our test sandbox is Linux, where a running binary can be replaced, so the failure can't happen there. A maintainer with a Windows machine will need to confirm it.

   One thing that may matter: your upgrade was run by 2.0.6. A Windows workaround for upgrading while opencode is running (#50819) first shipped in 2.0.15. Even so, the upgrade command reports success without checking that the binary on your PATH actually changed. If you can, please try again once you're on 2.0.15 or later (for example after closing all opencode processes and reinstalling), then run opencode update --method bun with opencode open and tell us whether opencode --version changes. That would help narrow it down.

   Related issues:

   • cli: upgrade reports success but the running binary is not replaced when another copy is registered with the package manager #52152: an upgrade reports success but the running binary isn't replaced (npm, another registered copy)
   • cli: Windows curl upgrade cannot replace the running opencode.exe (locked by the TUI and background service) #52025 / cli: v2 Windows PowerShell install cannot be upgraded in place #51755: Windows curl/PowerShell installs can't replace the locked running opencode.exe