cli: Windows curl upgrade cannot replace the running opencode.exe (locked by the TUI and background service) #52025

Activity

1. github-actions

   assigned

   Hona

   on Sep 29, 2026
2. 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 29, 2026
3. github-actions commented on Sep 29, 2026

   

   github-actionsBot

   on Sep 29, 2026 – with GitHub Actions

   Contributor

   More actions

   Thanks for updating the issue with the required details and reproduction steps!
4. loisekk commented on Oct 11, 2026

   

   loisekk

   on Oct 11, 2026

   More actions

   Went looking for the mechanism behind this and think the premise needs re-testing, because mv may not hit the lock you expect.

   Your probe is accurate for a native Win32 caller:

   [System.IO.File]::Open('...opencode.exe','Open','ReadWrite','None')
   → being used by another process
   

   But the installer's final step isn't a Win32 open. install.sh:343 is mv "$tmp_dir/package/bin/$binary_name" "$INSTALL_DIR/$installed_binary", and under MINGW64 coreutils mv that succeeds against a running executable. Ran the real installer against a sandboxed HOME with the install-dir binary live:

   running install-dir binary: pid=1185 nlink=1
   hash before: e4224d18c3c96826
   $ HOME=$SANDBOX bash install.sh --version 2.0.19 --no-modify-path
   installer exit status : 0
   hash after            : 100c90202ec358bd
   VERDICT: BINARY WAS REPLACED
   

   Same-fs and cross-fs both replace, verified by hash change rather than exit code:

   [same-fs ] mv -> exit 0, hash CHANGED (e4224d18c3c96826 -> dafaac0690b4eb16)
   [cross-fs] mv -> exit 0, hash CHANGED (e4224d18c3c96826 -> dafaac0690b4eb16)
   

   The reason your probe and the installer disagree is sharing mode, not locking. Native Win32 opens don't request FILE_SHARE_DELETE, so the probe is refused; Cygwin/MSYS does request it, so mv is allowed. Both results are correct for their own caller — the probe measures .NET, the failure you predicted comes from mv, which isn't .NET.

   The claim I'd push back on is "Windows allows renaming a running executable but not overwriting or deleting it, so a coreutils mv that replaces the destination fails." Renaming a running exe does work, and mv is a rename — MSYS2 gets to rename because of FILE_SHARE_DELETE, so the lock you're reasoning about doesn't apply to it.

   Your rename-then-swap suggestion works, and it's the right shape for the path that genuinely is broken — but for mv it isn't needed.

   Where a real failure does happen is the cp path, install.sh:354, used by --binary and effectively by anyone following the PowerShell route in #51755:

   $ bash install.sh --binary /tmp/payload.exe
   cp: cannot create regular file '.../opencode.exe': Device or resource busy
   exit=1
   

   cp must open the destination for writing, which is refused even with FILE_SHARE_DELETE on the caller. That needs rename-aside, and it explains #51755's .old workaround exactly.

   Also relevant to the retained-image.ts question: the hard link it creates does allow unlink of a running image (I measured EPERM at nlink=1, OK at nlink=2), but the curl installer never unlinks the destination, so retaining() isn't what rescues that path.

   Two caveats on all of this. I used ping.exe as the stand-in running binary rather than opencode.exe itself — same Windows semantics, but it's not the same image. And it was a single process; I didn't try to reproduce your multi-process TUI-plus-service setup, so if the number of concurrent holders is what tips it over, my run wouldn't have caught that.

   If you still see it fail with a real Git Bash bash.exe, the installer's stderr would settle it — opencode upgrade currently discards it, and --print-logs --log-level DEBUG didn't surface it for me either. Surfacing installer stderr on failure looks like the more useful fix than the locking theory.
5. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the detailed report and the lock-probe output. I think this is a duplicate of #51755, which reports the same problem on v2: the Windows in-place upgrade can't replace the running %USERPROFILE%\.opencode\bin\opencode.exe. It also uses the same rename-aside workaround.

   Possible duplicates and related issues, most likely first:

   • cli: v2 Windows PowerShell install cannot be upgraded in place #51755: v2 in-place upgrade on Windows blocked by the running opencode.exe. Same problem and same rename-then-replace workaround. A commenter there argues that the installer's mv does succeed under Git Bash because MSYS opens files with FILE_SHARE_DELETE, unlike the PowerShell File.Open(..., 'None') probe. Your evidence that it still fails with Git Bash and several live processes would help that discussion.
   • bug: opencode upgrade fails silently on Windows - binary never replaced #37055: the same kind of failure on v1 (closed).
   • fix(cli): pick a Windows bash for the curl installer #51038 / cli: upgrade --method curl fails on Windows (mangled backslash path passed to bash) #50924 / cli: Windows curl upgrade fails when bash on PATH is WSL (backslash script path is mangled) #56486: choosing the right bash for the curl upgrade on Windows. Related, but a separate problem, as you noted.

   It would help to add your probe results and a note on whether the real installer mv failed under Git Bash (with its exact error) to #51755. The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
6. opencodejr

   added

   pending close

   triaging

   on Oct 28, 2026
7. opencodejr

   closed this as duplicateon Oct 29, 2026
8. opencodejr commented on Oct 29, 2026

   

   opencodejrBot

   on Oct 29, 2026

   Contributor

   More actions

   We haven't heard back in the last day, so I'm closing this as a duplicate of #51755. That issue tracks the same v2 problem: the Windows in-place upgrade can't replace the running %USERPROFILE%\.opencode\bin\opencode.exe.

   Your write-lock probe, and the note that the lock remains after the #51038 shell-selection fix, would be useful on #51755. There is a discussion there about whether the installer's mv actually fails under Git Bash. If your problem turns out to be different, reply here and we can reopen it. Thanks for the detailed report!