[BUG] SIGILL on main thread inside JSC JIT code during "Compacting conversation…", 2.1.296 / Bun 1.4.3, Linux x64

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet (searched SIGILL, Illegal instruction, bun.report). #91914 is the closest open report and is a different signature: a GC HeapHelper thread fault inside JSC::IsoCellSet::parallelNotEmptyMarkedBlockSource. This report is the main thread faulting inside JIT-compiled code. #19967, #80443, #89033 and #96402 are startup SIGILLs on CPUs without AVX or SSE4.1; this CPU has AVX2, BMI1, BMI2 and FMA and the session ran for 85 minutes before the fault.
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.296, native installer)

What's Wrong?

The native Linux x64 build died with SIGILL on the main thread while the CLI was showing Compacting conversation… (0s). The turn had already finished: the final assistant message and the away summary were written to the session transcript at 21:11:43Z and 21:14:46Z on 2026-10-12, and the process dumped core at 22:05:29Z. The status line at the crash showed 31% context used, so this was not an automatic compaction at the context limit. What triggered the compaction is not recorded in the transcript. The session was one long autonomous turn (423 messages, about 2.5 MB of transcript) that used Bash, the Artifact tool and a Claude Docs MCP server.

The faulting instruction pointer is inside JavaScriptCore's JIT code region, not in the claude binary and not in libc. From the core dump:

• Below the signal frame, every frame on the main thread is in anonymous memory with no file backing. The fault address 0x7effbc127ac6 lies in a 64 MiB anonymous executable mapping (0x7effba0de000–0x7effbe0de000, flags ALLOC LOAD CODE), which is the JSC executable memory pool.
• The bytes around the fault address decode to a coherent JSC sequence: a call into a runtime function in the claude binary's .text (0x47ca050), then a GC write barrier on a constant heap cell. The fault address is three bytes inside the ten-byte mov rsi, imm64 that loads that cell, so the CPU was fetching from a point that is not an instruction boundary:

7effbc127aac  mov  rdi, 0x3abfe780000     ; same pointer passed to both runtime calls, reads as VM*
7effbc127ab6  mov  r10, 0x47ca050         ; inside the claude binary's .text (0x0192a800-0x054ef98c)
7effbc127ac0  call r10
7effbc127ac3  mov  rsi, 0x3ac043c3ba0     ; heap cell. fault RIP 0x7effbc127ac6 is inside this instruction
7effbc127acd  cmp  byte [rsi+7], 0        ; JSCell cellState vs blackThreshold
7effbc127ad1  ja   +0x17                  ; skip write barrier
7effbc127ad7  mov  rdi, 0x3abfe780000
7effbc127ae1  mov  r10, 0x...7ca250       ; second runtime function near the first (write barrier slow path)

Raw bytes at the fault address: 3b 3c 04 ac 03 00 00 80 7e 07 00 0f 87 17 00 00 00 48 bf 00 00 78 fe ab 03 00 00 49 ba 50 a2 7c. There is no ud2 or int3 at the fault address.

• The return addresses in frames 7–16 of the main thread repeat the same four values in a cycle (0x7effba529a5b, 0x7effba27c00f, 0x7effbb57a3d6, 0x7effba7ef40e), so the fault happened inside a recursive JIT-compiled JavaScript routine.
• Execution from the middle of an instruction means either a bad control transfer (a stale call target or return address into JIT code that was freed and reused) or code at that location being rewritten between the fault and the dump. Both point at JIT code lifetime or patching inside the bundled JSC/Bun.

Caveats: the dump was taken after Bun's crash handler ran and re-raised the signal, and JSC compiler threads can write into the JIT region during that window, so the bytes may not be exactly what the CPU saw. The core carries no JavaScript-level symbols, so the JS function cannot be recovered from it. The bun.report decode shows only llint_op_call_ignore_result frames for these addresses, which is the symboliser's guess for anonymous memory and should not be trusted.

What Should Happen?

Compaction completes, or fails with a recoverable error inside the CLI. The runtime should not die with a signal.

Error Messages/Logs

Terminal output at the crash:

Bun v1.4.3 (eecfd55de) Linux x64
Linux Kernel v7.1.13 | glibc v2.41
CPU: sse42 popcnt avx avx2
Args: "claude"
Features: Bun.stderr(2) Bun.stdin(2) Bun.stdout(2) WebSocket abort_signal(4) fetch(1149) jsc spawn(6801) standalone_executable yaml_parse(44…
Elapsed: 5105831ms | User: 397399ms | Sys: 35946ms
RSS: 0.44 GB | Peak: 0.59 GB | Commit: 8.1 GB | Faults: 0 | Machine: 33.15 GB

panic(main thread): Illegal instruction at address 0x7EFFBC127AC6
oh no: Bun has crashed. This indicates a bug in Bun, not your code.

https://bun.report/1.4.3/l_1eecfd55mgggkQ+hogC______67qz6D67qz6D_67qz6D67qz6D_67qz6D67qz6DA3+v/B1zi29jC

[1]    703526 illegal hardware instruction (core dumped)  claude

The bun.report link above has been opened, so the redacted crash report has been submitted to the Bun team.

coredumpctl info for the process:

Signal: 4 (ILL)
Timestamp: Mon 2026-10-12 15:05:29 PDT
Executable: ~/.local/share/claude/versions/2.1.296
Stack trace of thread 703526:
#0  0x00007effbe4b769c n/a (libc.so.6 + 0x9469c)
#1  0x00007effbe462c42 raise (libc.so.6 + 0x3fc42)
#2  0x00000000033a13f2 n/a (claude 2.1.296 + 0x31a13f2)   ; Bun crash handler
#3  0x00000000033a07dd n/a (claude 2.1.296 + 0x31a07dd)
#4  0x00000000033a11a4 n/a (claude 2.1.296 + 0x31a11a4)
#5  0x00007effbe462d70 n/a (libc.so.6 + 0x3fd70)          ; signal frame
#6  0x00007effbc127ac6 n/a (n/a + 0x0)                    ; fault, JIT region
#7  0x00007effba529a5b n/a (n/a + 0x0)
#8  0x00007effba27c00f n/a (n/a + 0x0)
#9  0x00007effbb57a3d6 n/a (n/a + 0x0)
#10 0x00007effba7ef40e n/a (n/a + 0x0)
#11 0x00007effba529a5b n/a (n/a + 0x0)
#12 0x00007effba27c00f n/a (n/a + 0x0)
#13 0x00007effbb57a3d6 n/a (n/a + 0x0)
#14 0x00007effba7ef40e n/a (n/a + 0x0)
#15 0x00007effba529a5b n/a (n/a + 0x0)
#16 0x00007effba536e77 n/a (n/a + 0x0)
#17 0x00007effbbbe5034 n/a (n/a + 0x0)

The 115 MB core dump (zstd) is retained locally and can be shared privately on request.

Steps to Reproduce

Not reproduced a second time. Shape of the session that crashed:

1. claude in a React Native repository, native installer build 2.1.296, inside tmux.
2. One autonomous turn of about 30 minutes: a repository audit using Bash, the Artifact tool and a Claude Docs MCP server, 423 messages, transcript about 2.5 MB.
3. Turn ends, final message and away summary print, context at 31%.
4. About 50 minutes later the CLI shows Compacting conversation… (0s) and the process dies with SIGILL.

Claude Model

claude-fable-5-1

Is this a regression?

Unknown. No earlier version was run with this session shape on this machine.

Last Working Version

Unknown

Claude Code Version

2.1.296 (native installer, ~/.local/share/claude/versions/2.1.296), bundled Bun v1.4.3 (eecfd55de)

Platform

Linux x64

Operating System

Debian GNU/Linux 13 (trixie), kernel 7.1.13+deb13-amd64, glibc 2.41. CPU: Intel Core Ultra 7 258V (flags include avx2, bmi1, bmi2, fma, f16c, movbe, abm). Bare metal, 33 GB RAM.

Terminal/Shell

tmux, zsh

Additional Information

The session transcript (~/.claude/projects/<project>/<session-id>.jsonl) is intact and ends with the final assistant message and the away_summary system entry. claude --resume <session-id> works. Nothing typed after the away summary was persisted.