Claude Code "terminated by signal SIGSEGV (Address boundary error)": how to get it running again

You typed claude and the terminal came back with terminated by signal SIGSEGV (Address boundary error). That is the fish shell's wording; in bash and zsh the same crash shows up as Segmentation fault (core dumped), with exit code 139. Between August and September 2026 the official anthropics/claude-code repository piled up dozens of issues with this signal, and they fall into three different patterns. What decides the fix is when the process dies.

What does "terminated by signal SIGSEGV (Address boundary error)" mean?

The Claude Code process tried to read or write a memory address it was not allowed to, and the operating system killed it. It is not a bug in your code or your project: the crash happens inside the Claude Code binary.

The native Claude Code install is a single executable with the Bun runtime bundled in. Almost every September issue points inside that runtime, either a specific build that shipped broken or the JavaScriptCore garbage collector Bun relies on. That is why the fixes below are almost always about which version you run, not about configuration.

Which of the three cases is yours?

Look at when the crash happens. The table sums up the three patterns found in the official issues and the fix for each.

When it crashes	Typical sign	Cause	What to do
On launch, even claude --version, right after an update	Every time, 100%	The new version's build is broken on your system	Roll back to the last version that started and lock auto-update
During install	CPU lacks AVX support in the Bun report	Processor without AVX	No version fixes it today; run on another machine
In the middle of a session that was working	Intermittent, sometimes while idle	Runtime garbage collector failure	Resume with claude --continue and switch versions

Crashes on launch right after updating: how do I roll back?

If even claude --version hits SIGSEGV, the version auto-update installed is broken on your system. Go back to the previous one and turn off auto-update until the fix ships.

Two real cases in 2026:

• 2.1.243 (issues #89390 and #89484, Aug 25): immediate segfault on Linux x86_64 with glibc 2.44, while 2.1.239, 2.1.240 and 2.1.241 started normally on the same machine. According to reports in #89390, the fix landed in 2.1.250.
• 2.1.251 onward (issue #92749, Sep 7, still open): on some Linux machines, versions that bundle Bun 1.4.1 die about 25 ms after launch, and the last one that works is 2.1.243, with Bun 1.4.0.

Step 1: find out which versions you have on disk. The native install on macOS and Linux keeps each version in ~/.local/share/claude/versions/ and points ~/.local/bin/claude at one of them. Test each one:

ls ~/.local/share/claude/versions/
for v in ~/.local/share/claude/versions/*; do echo "$v"; "$v" --version; done

The one that prints something like 2.1.241 (Claude Code) is your good version. The broken one exits with code 139.

Step 2: reinstall the good version with the installer. You cannot use claude install here, because it runs inside the same binary that is crashing. The official script accepts a version number:

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.241

If you installed through npm, the equivalent is pinning the package version:

npm install -g @anthropic-ai/claude-code@2.1.241

Step 3: stop auto-update from bringing the broken version back. Without this, the next background check reinstalls the same version. In ~/.claude/settings.json:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

Confirm with claude doctor: the Auto-updates line should read disabled (set by env: DISABLE_AUTOUPDATER).

Alternative without turning off auto-update: replace the ~/.local/bin/claude link with a script that pins the version. The official docs confirm that since v2.1.207 auto-update respects a custom launcher at that path: new versions still download into versions/, but your script decides which one runs. This was the workaround suggested in #89390:

#!/bin/sh
PIN="${CLAUDE_PIN:-2.1.241}"
BIN="$HOME/.local/share/claude/versions/$PIN"
if [ ! -x "$BIN" ]; then
  echo "claude: pinned version $PIN not found in ~/.local/share/claude/versions" >&2
  exit 127
fi
exec "$BIN" "$@"

To test a new version without editing the script, run CLAUDE_PIN=2.1.283 claude --version.

Watch the models' version floor. In #92749, going back to 2.1.243 made the API refuse Fable 5.1 with claude_code_version_too_old: "version 2.1.251 or newer is required". If the downgrade leaves you without the model you use, switch models with /model until the fix ships.

Crashes on install with "CPU lacks AVX support": is there a way out?

Not today, on the version side. On x86-64 processors without AVX, the native installer and the npm package fail the same way, so switching install channels does not help.

Issue #87974 (Aug 19, 2026) shows the full sequence:

CPU lacks AVX support. Please consider upgrading to a newer CPU.
panic(main thread): Segmentation fault at address 0x43AE6000000
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

The reporter debugged it with gdb and showed the crash is a read of up to 3 bytes past the end of a memory block, not an illegal instruction. The issue was closed for inactivity on Sep 22, 2026, with no fix. Check whether your CPU has AVX before trying again:

grep -o -w 'avx\|avx2' /proc/cpuinfo | sort -u

Empty output confirms the case. The real path is running the agent on a machine with AVX and connecting over SSH.

Crashes mid-session: how do I keep my work?

Resume the conversation where it stopped and, if the crash repeats, switch versions. The session history is saved to disk, so SIGSEGV kills the process, not the conversation.

claude --continue   # resumes the most recent conversation in this directory
claude --resume     # pick which conversation to resume

This pattern is intermittent and harder to pin down. Two detailed September reports:

• #95655 (Sep 20, open): crashes in idle sessions on the linux-x64 binary, recurring from 2.1.210 to 2.1.278. The core dump analysis points to writes into already freed memory, which the garbage collector trips over later. The same report logs the rate jumping from 1 crash every 9 days to 2 in 39 hours after a large kernel and glibc upgrade.
• #96793 (Sep 24, open): regression in 2.1.280 on Remote Control sessions over VS Code Remote-SSH, with panic(main thread): Segmentation fault at address 0x0. Last known good version: 2.1.279.

For #96793, the stable channel fixes it directly: on Sep 27, 2026 it was on 2.1.274, before the regression, while latest was on 2.1.283 (dist-tags of the @anthropic-ai/claude-code npm package).

To attach to an issue, the kernel log shows the address and the exact version that went down:

journalctl -k | grep -i 'claude.*segfault'
coredumpctl list claude

How do I keep the next update from breaking it again?

Switch to the stable channel. According to the official docs, it ships a version about one week old and skips releases with major regressions, which is exactly what took down 2.1.243 and 2.1.280.

{
  "autoUpdatesChannel": "stable"
}

You can also change it in /config, under Auto-update channel, or install straight onto the channel:

curl -fsSL https://claude.ai/install.sh | bash -s stable

When the fix ships, undo what you locked. Remove DISABLE_AUTOUPDATER from settings.json and run claude update. If you used the custom launcher, delete the script and run the installer again, which recreates the link and goes back to managing versions:

rm ~/.local/bin/claude
curl -fsSL https://claude.ai/install.sh | bash