### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Calling `mcp__claude-in-chrome__tabs_context_mcp` while the Chrome extension is not connected returns the expected "Browser extension is not connected" er

[BUG] Native CLI segfaults (Bun 1.4.0) right after claude-in-chrome tabs_context_mcp reports "Browser extension is not connected"

Status Open

Reported on v2.1.221

Maintainer reply None cached

Activity 0 comments · opened Aug 4, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Calling mcp__claude-in-chrome__tabs_context_mcp while the Chrome extension is not connected returns the expected "Browser extension is not connected" error, and then the CLI process dies with SIGSEGV about three seconds later, in the middle of the turn.

The failure itself is handled correctly: a normal tool error comes back to the model. What is not handled is whatever runs after it. The session file on disk survives and claude -r resumes it, but the in-flight turn is lost.

Timeline from the session transcript (UTC), cross-referenced with systemd-coredump in the journal:

22:07:54.318 tool_use tabs_context_mcp { createIfEmpty: true }
22:08:05.906 tool_result "Browser extension is not connected. ..."
22:08:09 kernel process terminated abnormally with signal 11/SEGV

That tool_result is the last record written to the transcript, nothing follows it.

After starting the browser, the very same call succeeded and browser automation worked normally for the rest of the session, so the crash looks specific to the not-connected path.

What Should Happen?

The not-connected case is already a recoverable tool error: the message is generated, returned to the model, and written to the transcript. The CLI should stay alive after reporting it, and the turn should continue.

Error Messages/Logs

Bun v1.4.0 (eb835313a) Linux x64 (baseline)
Linux Kernel v6.18.41 | glibc v2.44
CPU: sse42 popcnt avx avx2
Args: "<path>/claude" "--dangerously-skip-permissions"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) WebSocket abort_signal(340) fetch(362) jsc spawn(139) standalone_executable process_dlopen yaml_parse(194) claude_code
Elapsed: 2301288ms | User: 54612ms | Sys: 15901ms
RSS: 0.57 GB | Peak: 0.64 GB | Commit: 2.94 GB | Faults: 0 | Machine: 20.91 GB

panic: Segmentation fault at address 0x2724AF8A60

--- journal, same second ---
systemd-coredump: Process NNN (claude) terminated abnormally with signal 11/SEGV, processing...
systemd-coredump: Resource limits disable core dumping for process NNN (claude).
systemd-coredump: Process NNN (claude) terminated abnormally without generating a coredump.

RLIMIT_CORE is 0 in this environment, so there is no core file and no backtrace.
Memory was not a factor: RSS 0.57 GB on a 20.9 GB machine, zero faults.

Steps to Reproduce

Environment note: Linux, Claude browser extension installed, but the browser process not running at the time of the call.

Step 1. Make sure Chrome/Chromium is not running, so the extension cannot connect.
Step 2. In a Claude Code session, load the claude-in-chrome tools (invoking the claude-in-chrome skill does this).
Step 3. Call mcp__claude-in-chrome__tabs_context_mcp with createIfEmpty: true.
Step 4. The "Browser extension is not connected" result comes back normally and is written to the transcript.
Step 5. About three seconds later the CLI process dies with SIGSEGV, printing the Bun panic block above.

Observed once, on a session that had been running about 38 minutes. I have not deliberately re-triggered it, because doing so kills the live session; happy to retest under instruction if that helps. Starting the browser and repeating the same call worked fine, and the rest of that session drove the browser without problems.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.221 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

Chromium 150.0.7871.186 with the Claude extension 1.0.84 installed; the browser process was not running at the time of the call. Wayland session, Arch-based distro, kernel 6.18.41-1-lts, glibc 2.44, fish shell.

Related, but not the same bug:

https://github.com/anthropics/claude-code/issues/83471 and https://github.com/anthropics/claude-code/issues/59561 are about the Windows native host crashing at startup on named-pipe listen. This report is Linux.

https://github.com/anthropics/claude-code/issues/79445, https://github.com/anthropics/claude-code/issues/81465, https://github.com/anthropics/claude-code/issues/83645 and https://github.com/anthropics/claude-code/issues/83839 are about the extension failing to connect. That is the trigger condition here, not the bug itself: the bug is that the CLI dies after the condition has already been reported cleanly.

https://github.com/anthropics/claude-code/issues/40756 (closed as not planned) looks like the same root cause approached from the other direction: the CLI session dying when the claude-in-chrome unix socket disconnects. If that is the same code path, the failure mode is still present in 2.1.221 and now surfaces as a hard SIGSEGV rather than a silent exit.

View original on GitHub ↗