Claude browser-extension native host (Bun 1.3.14) crashes during RegExp compilation on Windows (bmalloc allocation failure)

Open 💬 2 comments Opened Jun 15, 2026 by LivewaterTrading

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.report URL: https://bun.report/1.3.14/e_12a41ca9mggggEugggCg53vG6+q22C6rr42Cqvm22Cwmk22C84mk6C0xmk6Cqrsj7Ckgrm7Cu1/i7C0t8i7Cuhmj6Ck6jj6C48sj6Ckw/0+Bgwi1+Bq0o+oC4is/oCy6o/oC0o7+oCA3u//Bhnowu9D

  • 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

  1. Have the Claude Desktop app + the "Claude for Chrome" browser extension installed (native host registered under com.anthropic.claude_browser_extension).
  2. Chrome launches the native host → the bundled Bun 1.3.14 process crashes during startup (RegExp compilation), emitting the bun.report URL above.
  3. 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.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗