Claude browser-extension native host (Bun 1.3.14) crashes during RegExp compilation on Windows (bmalloc allocation failure)
Summary
On Windows, the Claude browser-extension native host (chrome-native-host.exe, shipped with the Claude Desktop app) crashes inside its bundled Bun 1.3.14 runtime. The decoded bun.report trace shows the panic happens while compiling a regular expression — an allocation failure in JSC's Yarr engine trips bmalloc's crash-on-error handler (reported as "Illegal instruction").
This appears distinct from the previously reported socket-listener / assertion-failure crashes of the same component (#31470, #21381, #9261, #23034), which were about listener/socket setup. This one is a RegExp construction → allocation failure.
Crash report
- Bun version: 1.3.14 (commit 2a41ca9)
- Build: Windows x86_64_baseline, StandaloneExecutable
- Panic: "Illegal instruction" — i.e.
pas_allocation_result_crash_on_error(bmalloc allocation failure)
Decoded stack trace (top frames)
pas_allocation_result_crash_on_error (pas_allocation_result.h:121)
pas_local_allocator_try_allocate_small_segregated_slow
bmalloc_heap_config_specialized_..._slow
pas_local_allocator_try_allocate
bmalloc_allocate_casual (bmalloc_heap.c:49)
WTF::FastMalloc::malloc (FastMalloc.h:235)
WTF::VectorBufferBase<>::allocateBuffer (Vector.h:235)
WTF::Vector<>::reserveCapacity / expandCapacity / appendSlowCase
JSC::Yarr::YarrPattern::eitherUnicode() (YarrPattern.cpp)
JSC::Yarr::YarrPatternConstructor::atomPatternCharacter
JSC::Yarr::Parser<>::parseEscape / parseAtomEscape / parseTokens / parse
JSC::Yarr::YarrPattern::compile (YarrPattern.cpp:2628)
JSC::RegExp::finishCreation / createWithoutCaching
JSC::RegExpCache::lookupOrCreate
JSC::regExpCreate / constructRegExp
JSC::constructWithRegExpConstructor (RegExpConstructor.cpp:402)
The crash is a Vector buffer growth (expandCapacity) during Unicode regex term construction that fails to allocate and triggers the fatal handler. This is at native-host startup, before the MCP browser bridge is usable.
Environment
- OS: Windows 11 Pro 10.0.26200
- CPU: Intel Core i7-8650U (Kaby Lake R; supports AVX2, yet the baseline Bun build is what's bundled/used)
- Claude Desktop app: 1.12603.1.0 (x64, MSIX/Store —
Claude_pzs8sxrjxfjjc) - Claude Code CLI: 2.1.177 (npm/Node build — unaffected; Node, not Bun)
- Native host:
...\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe - Registered host:
com.anthropic.claude_browser_extension(HKCU Chrome NativeMessagingHosts)
winget upgrade reports no newer Claude version available, so this reproduces on the current shipping build.
Repro
- Have the Claude Desktop app + the "Claude for Chrome" browser extension installed (native host registered under
com.anthropic.claude_browser_extension). - Chrome launches the native host → the bundled Bun 1.3.14 process crashes during startup (RegExp compilation), emitting the
bun.reportURL above. - The browser bridge never connects.
Workaround in use
Removing the HKCU native-messaging-host registration (HKCU\Software\Google\Chrome\NativeMessagingHosts\com.anthropic.claude_browser_extension) prevents Chrome from launching the crashing host. The Claude Desktop app and the Claude Code CLI continue to work. (The Desktop app may re-register the key on next launch.)
Likely area to investigate
- A regex being compiled at native-host startup whose Unicode-pattern term vector growth fails under bmalloc — either a genuinely large/pathological pattern or an allocation issue specific to the x86_64_baseline Bun build on Windows.
- Worth checking whether bundling the non-baseline (AVX2) Bun build, or upgrading past Bun 1.3.14, resolves it.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗