Skip to content

fix(bcode-browser): detect compiled mode on Windows; pre-flight harnessDir#25

Merged
Alezander9 merged 1 commit intomainfrom
fix/windows-bunfs-dirname-detection
Apr 30, 2026
Merged

fix(bcode-browser): detect compiled mode on Windows; pre-flight harnessDir#25
Alezander9 merged 1 commit intomainfrom
fix/windows-bunfs-dirname-detection

Conversation

@Alezander9
Copy link
Copy Markdown
Member

Summary

Two-fix combo for a Windows-only false positive where the compiled bcode binary reports uv is not installed or not on PATH even when uv is present.

Repro

  1. Install bcode v0.0.5 on Windows 11 (uv already installed at ~/.local/bin/uv.exe, on PATH).
  2. bcode run "<anything that triggers browser_execute>".
  3. Agent gets UV_MISSING_HINT and stops.

~/.cache/bcode/harness is never created, even though the binary embeds 120+ harness files.

Why

packages/bcode-browser/src/harness.ts:40:

const isCompiled = __dirname.startsWith("/$bunfs/") || __dirname.startsWith("B:/~BUN/")

In a Bun-compiled binary on Windows, __dirname is B:\~BUN\root (native backslashes), not B:/~BUN/. So isCompiled === false, resolveHarnessDir() returns DEV_HARNESS_DIR = path.resolve(__dirname, "..", "harness") which doesn't exist on disk, and the harness is never extracted.

browser-execute.ts then calls ChildProcess.make(uv, [...], { cwd: harnessDir }). Bun's spawn on Windows, when cwd doesn't exist, throws code: "ENOENT" with path: "uv" ? it blames the command, not the cwd. isUvMissing() walks the cause chain looking for code === "ENOENT", matches, and returns true ? user sees the misleading uv hint.

Fix

  1. harness.ts: normalize __dirname to forward slashes before the bunfs prefix check, so the same comparison works on Windows and POSIX.
  2. browser-execute.ts: pre-flight fs.access(harnessDir) before spawn. If missing, fail with a clear message instead of falling into the spawn-ENOENT path that gets misclassified as uv-missing. This is belt-and-braces in case future regressions break extraction again.

Verification

  • Reproduced the false positive on Windows 11 with both v0.0.5 and a freshly-built binary from this branch's parent (main).
  • Traced the symptom to __dirname = B:\~BUN\root (backslashes), confirming isCompiled=false.
  • Built locally with the fix ? ~/.cache/bcode/harness is created on first call, contains 1457 files.
  • End-to-end: bcode run "connect to my open chrome..." attaches to Chrome and navigates successfully (no false uv error).
  • Sanity-checked dev mode (bun run dev run "...") still works.
  • bun typecheck clean.

Modification zone

Level 1 (Green) ? packages/bcode-browser/ only. No vendored harness changes, no opencode changes, no UPSTREAM.md update needed.

…ssDir

The bunfs root is /$bunfs/ on POSIX but B:\~BUN\ on Windows (native
separators), so `__dirname.startsWith("B:/~BUN/")` was always false in
Windows compiled binaries. Result: isCompiled=false, resolveHarnessDir
returned the dev path which doesn't exist on installs, the harness was
never extracted, and every spawn failed with cwd=ENOENT. Bun's spawn
attributes that ENOENT to path="uv", so isUvMissing matched and the
agent reported a misleading 'uv not on PATH' error -- even though uv
was installed and on PATH.

Two fixes:
1. harness.ts: normalize __dirname to forward slashes before the bunfs
   prefix check, so the same comparison works on Windows and POSIX.
2. browser-execute.ts: fs.access(harnessDir) before spawn. If the
   directory is missing, fail with a clear message instead of falling
   into the spawn-ENOENT path that gets misclassified as uv-missing.

Reproduced on Windows 11 with v0.0.5 binary (and a locally-built one).
Pre-fix: ~/.cache/bcode/harness was never created; agent reported uv
missing despite uv being installed and on PATH.
Post-fix: harness extracts on first run, agent attaches to Chrome,
end-to-end browser_execute works.
Copy link
Copy Markdown

@cubic-dev-ai cubic-dev-ai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

@Alezander9 Alezander9 merged commit 95bb954 into main Apr 30, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant