[Bug] Windows self-update never applies: daemon stages the same release every 30 min for 12 days, and 'bsk update' reports staged without replacing the binary #305

Summary

On this Windows 10 machine the CLI self-update never applied anything for 12 days: the daemon staged the same release every 30 minutes and logged "cannot replace the running daemon in place", the staged bsk.exe.update-* files piled up next to the binary, and the installed CLI stayed on 0.2.0 while 0.2.1 and 0.3.0 were staged over and over. bsk update -y also reported success ("status": "staged") without replacing the binary. Replacing it manually (stop daemon → move file → start daemon) worked instantly.

This looks like the same failure class as #176 / #192 / #85 / #21, which are all merged — so either a regression, or 0.2.0 predates those fixes and could not bootstrap out of the broken updater.

Environment

• Windows 10 x64 (19045.7725)
• CLI at C:\Users\WIN10\.local\bin\bsk.exe (a second copy at C:\Users\WIN10\.dsh\bin\bsk.exe, installed by bsk install-skill)
• Failing version: 0.2.0 (file mtime 2026-09-09; 0.2.0 was published 2026-09-03, i.e. before fix(update): make Windows self-updates reliable #192 merged on 2026-09-07)
• Releases staged but never applied: 0.2.1 (published 09-09) and 0.3.0 (published 09-17)
• Browser extension connected the whole time (Edge, browser connected id=47c05e18)

Evidence 1 — daemon logs the same warning every 30 minutes

~/.bsk/daemon.log.2026-09-09 … daemon.log.2026-09-18:

{"timestamp":"2026-09-09T17:05:48.501712Z","level":"WARN","fields":{"message":"auto-update staged the new binary but cannot replace the running daemon in place; restart the daemon (or terminal) to finish the upgrade","latest":"0.2.1"},"target":"bsk::daemon::start"}

Same line at 17:35, 18:05, 18:35, 19:06, 19:35, 20:35, 21:06 (…), then every 30 min through 09-11, 09-12, 09-13, 09-15, and from 09-18 with "latest":"0.3.0" — 09-18 alone has ~12 of them (13:45 → 19:45). Two related lines also appear:

"auto-update postponed: agent session(s) active; will retry on the next tick","latest":"0.2.1","sessions":1
"periodic update check failed","error":"download https://github.com/Tencent/BrowserSkill/releases/latest/download/version.json"

The "restart the daemon (or terminal) to finish the upgrade" advice never helped: the daemon restarts on every bsk invocation (each CLI command auto-starts it), so it re-takes the lock on bsk.exe before the helper can replace it. I confirmed the lock directly:

[System.IO.File]::Open('C:\Users\WIN10\.local\bin\bsk.exe','Open','ReadWrite','None')
→ "The process cannot access the file ... because it is being used by another process."

Evidence 2 — 11 staged binaries, zero applied

C:\Users\WIN10\.local\bin\ accumulated these (deleted after the manual fix; sizes/timestamps as observed):

bsk.exe.update-20264  12083712  2026-09-10 08:05
bsk.exe.update-11224  12083712  2026-09-11 06:33
bsk.exe.update-11508  12083712  2026-09-12 02:00
bsk.exe.update-24824  12083712  2026-09-12 10:12
bsk.exe.update-19888  12083712  2026-09-13 02:06
bsk.exe.update-20392  12083712  2026-09-14 03:23
bsk.exe.update-20572  12083712  2026-09-16 00:22
bsk.exe.update-19940  14010368  2026-09-19 03:45
bsk.exe.update-25552  14010368  2026-09-21 00:27
bsk.exe.update-31184  14010368  2026-09-21 00:51

(each with a matching .cmd helper of 225–298 bytes; ~132 MB total). bsk.exe itself never changed: mtime stayed 2026-09-09 07:33 while bsk --version reported 0.2.0.

Evidence 3 — the CLI path reports staged and does not replace

Running the CLI updater directly (2026-09-21 00:51 local):

$ bsk update -y --json
{"status":"staged","current_version":"0.2.0","latest_version":"0.3.0",
 "install_action":"staged",
 "message":"staged bsk 0.3.0 for replacement after this command exits"}
STDERR: WARN bsk::daemon::start: daemon did not exit within 5s; sending KILL pid=35056

After the command exited: bsk.exe was still 0.2.0, the staged file was still there, and no cmd.exe helper was running or waiting (Get-CimInstance Win32_Process -Filter "Name='cmd.exe'" showed only unrelated processes). A daemon came back 17 s later (daemon ready pid=2652) and re-locked the file.

Evidence 4 — manual replacement works

bsk daemon stop
Move-Item bsk.exe.update-31184 bsk.exe      # succeeded immediately, no retry loop needed
Copy-Item bsk.exe "$HOME\.dsh\bin\bsk.exe"  # the second copy the skill installer placed
bsk daemon start
→ bsk 0.3.0 ; daemon_version 0.3.0 ; protocol 1.3 ; version_skew false

Also note the second copy at ~/.dsh/bin/bsk.exe was still 0.1.10 — i.e. bsk install-skill's copy never participates in self-update at all, and anything resolving bsk from that directory stays on an old CLI.

What I think is happening (not verified)

0.2.0 predates #192, so it may lack "旧 daemon 主动退出 + helper 完成替换" and the Windows helper-launch fixes. That creates a bootstrap trap: the fix for the broken updater only exists inside the release that the broken updater cannot install. If that is the case, a machine stuck on a pre-#192 CLI can never recover on its own, and bsk update should either apply the replacement itself or fail loudly instead of reporting "status": "staged".

Questions

1. Is a pre-fix(update): make Windows self-updates reliable #192 install expected to be able to self-update at all, or is manual reinstall/install.ps1 the documented recovery?
2. Should bsk update verify that the helper actually started (as fix(update): make Windows self-updates reliable #192 claims) and report failure otherwise? Here it printed staged with the binary untouched.
3. Should the daemon's "restart the daemon to finish the upgrade" advice be replaced, given that any bsk command restarts the daemon and re-locks the binary?
4. Should the ~/.dsh/bin/bsk.exe copy created by bsk install-skill be kept in sync (or be a symlink/shim), instead of staying on 0.1.10?

Related: #176, #192, #85, #21, #77, #282, #208. (Separately, bsk status/bsk doctor never exit on this machine — already covered by #24 / #265, not part of this report.)