browse: build-node-server.sh fails on Windows when ngrok produces multiple output files

[RonieKrasniker]

Bug

scripts/build-node-server.sh fails on Windows with:

error: cannot write multiple output files without an output directory

This means server-node.mjs is never generated, and the browse binary crashes at startup:

error: server-node.mjs not found. Run `bun run build` to generate the Windows server bundle.

Root Cause

The build script uses bun build --outfile dist/server-node.mjs, which writes a single file. On Windows, the ngrok native addon (ngrok.win32-x64-msvc.node, ~10MB) is emitted as a separate asset. Bun refuses to write multiple outputs to a single --outfile.

Fix

Replace --outfile with --outdir + --entry-naming:

- bun build "$SRC_DIR/server.ts" \
-   --target=node \
-   --outfile "$DIST_DIR/server-node.mjs" \
-   --external playwright \
-   --external playwright-core \
-   --external diff \
-   --external "bun:sqlite"
+ bun build "$SRC_DIR/server.ts" \
+   --target=node \
+   --outdir "$DIST_DIR" \
+   --entry-naming server-node.mjs \
+   --external playwright \
+   --external playwright-core \
+   --external diff \
+   --external "bun:sqlite"

This lets bun write both the main bundle and the ngrok native addon to dist/. The rest of the post-processing steps in the script work unchanged.

Environment

• Windows 11
• Bun 1.3.11
• gstack browse skill (latest as of 2026-04-11)

Verified the fix works: browse starts, navigates, and reads pages correctly after rebuilding with --outdir.

[acsezen]

+1 / extra data point: this isn't Windows-specific — the same bun build invocation fails on Linux too.

Repro on Linux x86_64:

• OS: Linux 6.17.0-20-generic
• Bun: 1.3.12
• gstack: v0.16.3.0 (c6e6a21)
• Command: the exact one from browse/scripts/build-node-server.sh:17-23

Output:

Building Node-compatible server bundle...
error: cannot write multiple output files without an output directory

On Linux, ngrok emits ngrok.linux-x64-gnu.node (same ~10 MB native addon, different triple), and bun build --outfile rejects the multi-output emission the same way. The failure is just hidden on Linux/macOS because browse/src/cli.ts:80-83 only hard-fails on server-node.mjs missing when process.platform === 'win32' — non-Windows users keep running against whatever stale server-node.mjs is left in dist/.

Side effect worth flagging: ./setup logs the error but exits 0 (the build script fails the bun build step but the rest of setup is in a separate shell context, so setup reports "gstack ready" despite the broken bundle). Easy to miss in install output.

The proposed fix (--outdir + --entry-naming) should solve both platforms at once — confirmed the --outfile path is the sole failure point in my repro. Happy to test a PR on Linux if useful.

[BenjaminDSmithy]

Also hitting this on macOS 15.7.4 (Sequoia) x86_64 with bun 1.3.11 on gstack v0.16.3.0 (commit c6e6a21). So the "multiple output files" error is confirmed on Windows 11, Linux x86_64, and macOS Intel — fully cross-platform at this point regardless of ngrok.

Surfaced mid-./setup during a routine 0.16.2.0 → 0.16.3.0 upgrade via /gstack-upgrade:

  [19ms]  bundle  3 modules
 [224ms] compile  browse/dist/browse
   [5ms]  bundle  1 modules
 [174ms] compile  browse/dist/find-browse
  [10ms]  bundle  16 modules
 [246ms] compile  design/dist/design
   [8ms]  bundle  1 modules
 [211ms] compile  bin/gstack-global-discover
Building Node-compatible server bundle...
error: cannot write multiple output files without an output directory
  linked skills: autoplan benchmark browse ...
gstack ready (claude).

Non-obvious downstream impact

Even on macOS where server-node.mjs isn't strictly needed (bun drives Playwright directly), the failure has a silent side effect. The bun run build chain in package.json:11 breaks at bash browse/scripts/build-node-server.sh, then hits the || true at the tail of the chain, which swallows the failure code. The downstream steps in the same chain are skipped:

"build": "... && bash browse/scripts/build-node-server.sh && git rev-parse HEAD > browse/dist/.version && git rev-parse HEAD > design/dist/.version && chmod +x browse/dist/browse browse/dist/find-browse design/dist/design bin/gstack-global-discover && rm -f .*.bun-build || true"

So a macOS user's upgrade path silently ends up with:

• no browse/dist/.version marker (upgrade-check code paths lose the SHA)
• no design/dist/.version marker
• no explicit chmod +x on the new binaries (probably still executable from --compile, but the belt-and-braces is gone)
• stray .*.bun-build temp files not cleaned

Setup still prints gstack ready (claude) after, so it's easy to miss. I only noticed because I was watching the output during an adversarial code review.

Side suggestion

Independent of whether you go with --outdir + --entry-naming (the fix already proposed in this issue), consider also wrapping build-node-server.sh with an OS guard so it exits early on non-Windows:

#!/usr/bin/env bash
set -e
case "$(uname -s)" in
  MINGW*|MSYS*|CYGWIN*|Windows_NT) ;;
  *) echo "Skipping Node-compatible server bundle (non-Windows platform)"; exit 0 ;;
esac
# ... rest of script

The script's own header comment says this bundle is Windows-only (bun can't drive Playwright there per oven-sh/bun#4253). Everyone else is paying the bun-build cost for something they'll never use. Early-exit also makes the original bug unreachable on macOS/Linux even without the --outdir change.

Happy to open a small PR for the early-exit if it'd help.

---

Apple Silicon + Linux testing: Finally pulled the trigger on a new MacBook Pro (M-series Max, 128 GB) — my current Intel Mac is well overdue for retirement. I work from home most days, but I have access to Apple Silicon Mac minis when I'm next in the office (likely Thursday or Friday next week), plus a personal desktop running Omarchy (DHH's Arch Linux) I can hit right now. Three surfaces to validate any fix against: arm64 macOS (office Mac mini end of next week, personal MBP later), x86_64 macOS (current), and x86_64 Linux (Omarchy, anytime). Happy to post validation back here within a day or two of whichever fix lands.