browse: Playwright Chromium launch hangs on Windows (Bun pipe transport issue)

[claygeo]

Environment

• OS: Windows 11 Home (10.0.26200)
• Bun: 1.2.20
• gstack: 0.3.9 (commit bb46ca6)
• Playwright: 1.58.2
• Chromium: headless_shell-1155 + chromium-1155 (both tested)

Problem

browse goto <url> hangs indefinitely on Windows. The server never starts — it gets stuck at chromium.launch({ headless: true }) in browser-manager.ts:45.

Root Cause

Bun's child process pipe implementation on Windows does not properly handle Playwright's --remote-debugging-pipe transport. Chromium launches (PID visible) but the DevTools Protocol pipe never connects, causing a timeout.

Reproduction

# This hangs on Windows with Bun:
cd ~/.claude/skills/gstack
bun -e "import { chromium } from 'playwright'; const b = await chromium.launch({ headless: true, timeout: 15000 }); console.log('ok'); await b.close();"
# → Timeout 15000ms exceeded

# Same code works perfectly with Node:
node -e "import('playwright').then(async({chromium})=>{const b=await chromium.launch({headless:true,timeout:15000});console.log('ok');await b.close();})"
# → ok

Tested with both chromium_headless_shell-1155 and chromium-1155 (full browser). Also tried channel: 'chrome' (system Chrome). All hang with Bun, all work with Node.

Suggested Fixes

1. On Windows, spawn the server with node + tsx instead of bun — requires making server.ts runtime-agnostic (replacing Bun.serve with Node HTTP, Bun.spawn with child_process, etc.)
2. Use playwright.chromium.connectOverCDP() with websocket instead of pipe transport — would bypass the broken pipe
3. Wait for Bun fix — this is ultimately a Bun issue with Windows named pipes

Workaround

Created a standalone Node-based browse wrapper that uses Node + Playwright directly. Works but lacks the full gstack browse feature set.

[mvanhorn]

Submitted a fix in #84. Detects process.platform === 'win32' in browser-manager.ts and uses connectOverCDP() with websocket transport instead of the default pipe transport.

[KeKeDou810]

Retested on 2026-03-20 after upgrading Bun, and the failure is still reproducible on a slightly newer runtime.

Environment:

• OS: Windows 10 Pro (build 22631)
• Bun: 1.3.11+af24e281e
• Playwright: 1.58.2
• Chromium: playwright-managed chrome-headless-shell

What I verified locally:

• node + chromium.launch() works
• node + chromium.launch({ args: [''--remote-debugging-port=0''] }) works
• node + chromium.connectOverCDP(''http://127.0.0.1:9224'') works

But on Bun:

• bun + chromium.launch() still hangs / times out
• bun + chromium.launch({ args: [''--remote-debugging-port=0''] }) also still hangs
• bun + chromium.connectOverCDP(''http://127.0.0.1:9223'') also times out

The connectOverCDP() failure is especially important because it suggests the current problem is broader than just --remote-debugging-pipe. In my run, Bun successfully fetched the websocket endpoint from /json/version, but then timed out while connecting to the returned ws://127.0.0.1:9223/devtools/browser/... URL. Node succeeds against the same manually started browser.

So at least on this environment, #84's current direction (--remote-debugging-port=0 on launch) does not appear sufficient to fix the issue. The evidence now points to a broader Bun <-> Playwright browser transport compatibility problem on Windows, affecting both launch and CDP websocket connection paths.