[Bug][Windows] Auto-update leaves proxy dead after npm EPERM on bun binary replacement #281

Summary

When the auto-update flow runs (ocx update) on Windows, npm cannot fully clean up the old bundled bun binary because bunx.exe is still locked by a running process. The bun postinstall script is also blocked. After the update, the port-availability check times out and the proxy restart is unreliable.

Note on the "proxy dies silently after restart" claim: Further investigation showed that the post-update proxy (PID 5176 in the original report, uptime ~12s) did not crash -- a monitoring script with a too-short healthz timeout mistakenly killed it. The EPERM cleanup failure and blocked postinstall are still real issues worth fixing independently.

Steps to reproduce

1. Have the proxy running on Windows
2. Trigger an update (via UI or ocx update)
3. The update stops the old proxy, runs npm install -g @bitkyc08/opencodex@latest
4. npm fails to clean up the old bun binary with EPERM: operation not permitted, unlink 'bunx.exe'
5. npm's bun postinstall script is also blocked (bun@1.3.14 postinstall: node install.js not run due to allow-scripts)
6. The update flow logs "Port 10100 still busy after stop" and starts the proxy anyway

Evidence from update-job.json

"npm warn cleanup Failed to remove some directories"
"npm warn cleanup   'C:\\...\\@bitkyc08\\.opencodex-1JejBqbZ\\node_modules\\bun\\bin\\bunx.exe'"
"npm warn cleanup     [Error: EPERM: operation not permitted, unlink ...]"
"npm warn install-scripts bun@1.3.14 (postinstall: node install.js) blocked"
"Port 10100 still busy after stop; starting with --port 10100 anyway."

The orphaned temp directory .opencodex-1JejBqbZ containing the old bunx.exe is left behind and persists across reboots.

Why it happens

On Windows, a running executable cannot be deleted or replaced while it is in use. The update flow stops the proxy (killing the main bun.exe process), but something -- possibly a lingering node/npm subprocess or a file handle from the previous session -- still holds bunx.exe open. npm therefore cannot complete its cleanup, the postinstall script for bun is skipped, and orphaned temp dirs accumulate in node_modules/@bitkyc08/.

Impact

• Every auto-update on Windows leaves orphaned temp dirs in node_modules/@bitkyc08/
• The bun postinstall script is never run, so every npm-based update is technically incomplete
• The port-availability wait races against Windows' TCP drain, occasionally causing the restart to fail
• No user-visible error beyond the npm warn lines buried in update-job.json

Suggested fix

1. After npm install, attempt cleanup of orphaned .opencodex-* temp dirs in the node_modules/@bitkyc08/ directory -- these are safe to delete after install completes since the old binary is no longer needed.
2. Extend the port-availability wait or retry before logging the "still busy" warning, giving Windows more time to drain the TCP socket after taskkill.

Environment

• OS: Windows 11, PowerShell
• Node: v24.15.0 (via nvm)
• Installer: npm global
• Updated from: 2.7.31 to 2.7.33
• OpenCodex version: 2.7.33