### 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? Environment - OS: FreeBSD 15.1 - Compat layer: Linux binary compatibility (linux_base-rl9) - Claude Code CLI: reproduced on 283, 284, 285, 286, 2

[BUG] Claude Code CLI + VS Code extension hang/die after ~5 min on FreeBSD via Linuxulator

Status Open

Reported on v2.1.278

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 4 comments · opened Oct 3, 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?

Environment

OS: FreeBSD 15.1
Compat layer: Linux binary compatibility (linux_base-rl9)
Claude Code CLI: reproduced on 283, 284, 285, 286, 287, 288
Node: v24.19.0
Affected surfaces: CLI (terminal) and VS Code extension

Description

Running Claude Code under FreeBSD's Linux binary compatibility layer (Linuxulator, linux_base-rl9), it works normally for ~5 minutes, then the process stucks/hangs and
dies in the background — no error shown. Reproduces across CLI versions 283–288, and also in the VS Code extension, so not tied to one release or one frontend.

Steps to reproduce

Run claude (CLI) or use the Claude Code VS Code extension, on FreeBSD 15.1 with linux_base-rl9 compat layer active, Node v24.19.0.
Use normally for ~5 minutes.
Process stucks, then dies in background — no error output, no clean exit message.

Expected

Process keeps running, or exits with clear error if something fails.

Actual

Silent hang then background death, after a consistent ~5 min window, on both CLI and VS Code extension.

What Should Happen?

Process keeps running, or exits with clear error if something fails.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

Run claude (CLI) or use the Claude Code VS Code extension, on FreeBSD 15.1 with linux_base-rl9 compat layer active, Node v24.19.0.
Use normally for ~5 minutes.
Process stucks, then dies in background — no error output, no clean exit message.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.278

Claude Code Version

2.1.288

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

4 Comments

michael-adler · 7 days ago

Saw this too. Workaround: setting env BUN_JSC_useConcurrentGC=0 eliminates the hang.

Reproduced on FreeBSD 15.1, Linuxulator (linux_base-rl9), misc/claude-code 2.1.283 (embedded Bun v1.4.1). 2.1.268 is unaffected.

Trigger: leave the session idle ~60 s, then run any Bash command; it hangs and only SIGKILL works.

Analysis (procstat -kk + DTrace on linux_sys_futex):

A thread named via PR_SET_NAME as "Collector Thread" (JSC concurrent GC) does 10 s timed condvar waits and exits after 60 s idle. It is not present in 2.1.268.
On the next command, the main thread blocks in FUTEX_WAIT_BITSET on a condvar that no thread ever wakes.
All futex wait/wake pairs and CLONE_CHILD_CLEARTID wakes on thread exit behave correctly, so this does not look like a Linuxulator futex bug.

This also fixes hangs in the claude-code FreeBSD package.

duncan-bayne · 7 days ago

@michael-adler Thanks! I'll try this workaround soon. I "fixed" the issue by rolling back to 2.1.265 on both my FreeBSD systems; so I assume this behaviour was introduced sometime after that release.

csmarshall · 2 days ago

Confirming the BUN_JSC_useConcurrentGC=0 workaround, with a control run, on 2.1.296.

Environment: FreeBSD 15.1-RELEASE-p1 amd64, stock GENERIC kernel from freebsd-update (so linux64.ko does not have the PR 298878 fix), linux_base-rl9-9.7. Claude Code 2.1.296 is the native install (linux-x64 under the Linuxulator), not the port. Terminal is iTerm2 → ssh → tmux 3.7b, with TERM=xterm-256color.

A/B test. Both runs used the same binary, config and directory, with claude --debug started in a fresh tmux session.

| run | launch env | result |
|---|---|---|
| control | (none) | Froze during a 75 s idle right after startup. The prompt typed afterwards never rendered. |
| treatment | env BUN_JSC_useConcurrentGC=0 claude --debug | Survived a 75 s idle followed by a Bash tool call, then 3 rounds of (120 s idle → Bash tool call). Still responsive at 9m25s when stopped. |

Frozen control, procstat -kk. STAT is Is+, WCHAN is futex, CPU is 0.0%, and comm has been renamed ollector Thread:

86632 454372 ollector Thread     2.1.296      ... sleepq_wait_sig _sleep umtxq_sleep linux_sys_futex amd64_syscall
86632 789294 ollector Thread     HTTP Client  ... sleepq_wait_sig _sleep umtxq_sleep linux_sys_futex amd64_syscall
86632 789310 ollector Thread     Waitpid      ... sleepq_wait_sig _sleep inotify_read dofileread sys_read amd64_syscall

Two sessions that had hung earlier in normal use showed the same main-thread stack. Only SIGKILL cleared them.

Gotcha: the variable has to be in the environment at launch (shell rc or wrapper). An entry in the settings.json "env" block is most likely applied after the JSC VM has already started (I didn't test that path).

This is one ~10-minute treatment run against one control, so it's encouraging but not conclusive. I'll report back if it recurs with the variable set.

michael-adler · 2 days ago

@csmarshall thanks. I built a 15.1-RELEASE-p4 kernel with the patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298878 and have been running well so far without having to set BUN_JSC_useConcurrentGC=0. At least it will be in 15.2 in a couple months.