Windows: build-bundles.mjs resolves repo root via URL.pathname, producing C:\C:\... (all builds fail)

[redliuziqi]

Summary

On Windows, every build target fails immediately: scripts/build-bundles.mjs resolves the repo root via new URL("..", import.meta.url).pathname, which yields a leading-slash path (/C:/Users/...) on win32. resolve() then treats it as relative and produces a doubled drive letter (C:\C:\Users\...).

This blocks build:cli, build:plugin, prepublishOnly, verify:plugin-sync, and the check gate — i.e. a Windows contributor cannot build or validate at all.

Reproduction

Windows 11, Bun 1.3.14, Node v22.14.0, at a3e927f (v0.1.30):

> bun run build:cli
    at file:///C:/Users/<user>/agent-bridge/scripts/build-bundles.mjs:12:24
  errno: -4058,
  code: 'ENOENT',
  syscall: 'open',
  path: 'C:\\C:\\Users\\<user>\\agent-bridge\\package.json'

bun run build:plugin and bun run verify:plugin-sync fail the same way (the latter shells out to build-bundles.mjs).

Root cause

scripts/build-bundles.mjs:11

const repoRoot = resolve(new URL("..", import.meta.url).pathname);

URL.pathname is a URL path, not a filesystem path. On POSIX the two coincide; on win32 it is /C:/..., and path.resolve("/C:/x") → C:\C:\x.

scripts/code-hash.cjs already does this correctly with resolve(__dirname, "..") — this is the only occurrence of the URL-pathname form in the repo, so the fix is a one-liner.

Existing tests already cover this

Three tests in the current suite fail on Windows purely because of this bug, so no new test is required to lock the fix:

• build-bundles commit override (verify-plugin-sync mechanism) — 2 tests
• build-bundles codeHash stamping — 1 test

Before (pristine master, Windows): 20 pass, 3 fail
After (fileURLToPath): 23 pass, 0 fail

Proposed fix

import { fileURLToPath } from "node:url";
const repoRoot = resolve(fileURLToPath(new URL("..", import.meta.url)));

fileURLToPath performs the documented URL→path conversion (strips the leading slash and decodes percent-escapes) and is correct on all platforms.

Relationship to #231

This is a prerequisite for #231 rather than a duplicate: #231 tracks the runtime/POSIX-assumption gaps (state dir, unix socket transport, process-group kills, Windows CI). This one is a build-time blocker — it must be fixed before a windows-latest CI leg can build bundles to test anything else. It is not in #231's blocker list.

Environment note

Fixing this does not make the suite fully green on Windows. With the fix applied I see 1485 pass / 33 fail (87 files), and the remainder are separate environment gaps that belong to #231:

• symlink → EPERM (needs Administrator or Developer Mode)
• Unix file-mode assertions (expected 420 / 511)
• POSIX path joins producing C:\C:\... in other scripts
• SIGKILL signal-name expectations
• src/unit-test/logs-cli.test.ts spawns tail, which does not exist on Windows — this aborts the whole bun test src/unit-test run rather than failing one test, so a full count requires excluding that file. abg logs -f is presumably also non-functional on Windows for the same reason.