Headed mode fails to launch on macOS 26.4.1 (Tahoe stable): "Mach rendezvous failed" before any page loads

[Masashi-Ono0611]

Summary

browse --headed (and the equivalent $B connect / /open-gstack-browser flow) fails immediately on launch on macOS 26.4.1 (Tahoe stable). Chromium child processes cannot establish Mach IPC with the Bun-compiled gstack server, and launchPersistentContext reports the context closed before any page is reached.

This is not the 15s watchdog crash from #867 / #1006 / #870 / #943 (all fixed via #868 / v0.15.15.1) — those covered a different failure mode where the headed window stayed alive for ~15s before being killed. This one is an immediate failure during the Chromium spawn handshake.

Headless mode works perfectly, including all v1.28.0.0 features (--proxy, download --navigate, prettyscreenshot --cleanup, ux-audit, cleanup, /scrape skill run). The bug is specific to the headed launch path.

Environment

• macOS: 26.4.1 (Tahoe stable, build 25E253)
• gstack: 1.28.0.0 (commit 443bde0)
• Hardware: Apple Silicon (arm64)
• Binary: ~/.claude/skills/gstack/browse/dist/browse (Bun-compiled)
• Playwright Chromium: chrome-mac-arm64 build 1208 (Google Chrome for Testing)

Reproduction

B=~/.claude/skills/gstack/browse/dist/browse
$B disconnect
$B --headed status

Output

[browse] Starting server in headed mode...
[browse] Server failed to start:
[browse] Buffer flush failed: lastConsoleFlushed is not defined
[browse] Buffer flush failed: lastConsoleFlushed is not defined
[browse] Failed to start: persistentContext: Target page, context or browser has been closed
Browser logs:

<launching> /Users/.../ms-playwright/chromium-1208/chrome-mac-arm64/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing [...flags...] --remote-debugging-pipe about:blank
<launched> pid=90822
[pid=90822][err] WARNING:third_party/crashpad/crashpad/util/numeric/in_range_cast.h:38] value -634136515 out of range
[pid=90822][err] [90837:1631406:.../shared_memory_switch.cc:273] Mach rendezvous failed, terminating process (parent died?)
[pid=90822][err] [90838:1631421:.../shared_memory_switch.cc:273] Mach rendezvous failed, terminating process (parent died?)
[pid=90822][err] [90829:1631318:.../net/socket/ssl_client_socket_impl.cc:918] handshake failed; returned -1, SSL error code 1, net_error -3

The Chromium child renderer/utility processes immediately fail their Mach IPC handshake with the parent and exit. launchPersistentContext then reports the browser closed before any page can be reached.

Diagnostic angle

The Mach rendezvous failed, terminating process (parent died?) pattern points at Chromium's macOS shared-memory switch failing to associate child PIDs with the parent. On Bun-compiled binaries this is plausibly related to how Bun's bun build --compile wraps process metadata in a way macOS 26's tightened security policies / Mach namespace handling no longer accepts. Headless mode works because the renderer uses a different IPC bootstrap path that doesn't go through this rendezvous step.

Two minor quirks visible in the output that may or may not be related:

• Buffer flush failed: lastConsoleFlushed is not defined printed twice on every headed-startup failure
• value -634136515 out of range from in_range_cast.h — looks like a Chromium-internal warning, but the negative value suggests an integer overflow somewhere in the parent-handle plumbing

What's ruled in/out

• ✅ Headless mode works end-to-end
• ✅ Reproduces deterministically on every $B --headed invocation
• ❌ Not the 15s watchdog issue (Headed Chromium crashes after exactly 15s on macOS 26.5 (Tahoe beta) #867, Headed Chrome auto-terminates after ~15s due to parent process watchdog #1006, Browse: parent process watchdog kills server between CLI invocations #870, Watchdog kills browse server mid-workflow when invoked from skills #943 — all fixed via fix: pair-agent tunnel drops after 15s (v0.15.15.1) #868)
• ❌ Not extension-related (Chromium dies before extensions load)
• ❌ Not profile-corruption (same behavior on rm -rf ~/.gstack/chromium-profile)

Possibly related upstream

• [Bug]: Issue with Playwright 1.50.1 on macOS 15.3 (Sequoia) - Page closes unexpectedly in non-headless mode microsoft/playwright#34693 (macOS 15.3 Sequoia headed crash) — different symptom, same family
• Likely originates in Chromium itself: base/memory/shared_memory_switch.cc:273

Suggested mitigations (in order of effort)

1. Detect macOS 26.x at runtime and warn before attempting --headed so users aren't blindsided
2. Document chrome-devtools MCP and external Chromium-with-extension as the macOS 26 workarounds
3. Investigate whether running the daemon under Node (via server-node.mjs) instead of the Bun-compiled binary changes the headed-launch outcome — would localize the issue to the Bun compile path

I'm happy to test patches on macOS 26.4.1 when something lands.

---

Filed alongside #1378 (separate prettyscreenshot --hide argument-parsing bug found during the same v1.28.0.0 verification pass).