Browse CLI broken on Windows: Bun compiled binary can't create lock file with O_CREAT|O_EXCL #599

Bug

The browse CLI is completely broken on Windows. Every command fails with:

[browse] Another instance is starting the server, waiting...
[browse] Timed out waiting for another instance to start the server

Root Cause

In browse/src/cli.ts, acquireServerLock() uses fs.openSync(lockPath, fs.constants.O_CREAT | fs.constants.O_EXCL | fs.constants.O_WRONLY) to create the lock file atomically.

Bun compiled binaries on Windows don't support these numeric flags with openSync. The call throws ENOENT even when the parent directory exists. The catch block then tries to read the (non-existent) lock file, catches that error too, and returns null — which the caller interprets as "another instance holds the lock."

This is a Bun bug specific to compiled binaries on Windows. Node.js handles the same flags correctly, and Bun's non-compiled runtime also works fine.

Reproduction

# Works in Node:
node -e "const fs=require('fs'); fs.openSync('/tmp/test.lock', fs.constants.O_CREAT|fs.constants.O_EXCL|fs.constants.O_WRONLY)"
# => creates file successfully

# Fails in Bun on Windows:
bun -e "const fs=require('fs'); fs.openSync('/tmp/test.lock', fs.constants.O_CREAT|fs.constants.O_EXCL|fs.constants.O_WRONLY)"  
# => ENOENT: no such file or directory

Fix

Use the string flag 'wx' instead of numeric constants. They're equivalent per the Node.js docs, but 'wx' works correctly in Bun on Windows:

-    const fd = fs.openSync(lockPath, fs.constants.O_CREAT | fs.constants.O_EXCL | fs.constants.O_WRONLY);
+    const fd = fs.openSync(lockPath, 'wx');

One-line change in browse/src/cli.ts at the acquireServerLock() function.

Environment

• Windows 11 Pro
• Bun 1.x compiled binary (browse.exe)
• gstack v0.11.19.0