Repository navigation
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
Title
Critical performance regression on WSL2: Slash commands trigger infinite futex spinlock causing 110% CPU usage
Description
Summary
Claude Code v2.0.76 and v2.0.67 has a critical performance regression on WSL2 that makes the application unusable. Typing the "/" character immediately triggers an infinite futex spinlock, causing CPU usage to spike to 110%+ and remain elevated indefinitely. This does not occur in v2.0.50 where I have rolled back too.
Environment
- Claude Code Version: 2.0.76
- OS: Windows 11 with WSL2 (Ubuntu 24.04)
- WSL Version: Latest WSL2
- Installation Method: Native installer (
curl -fsSL https://claude.ai/install.sh | bash) - Terminal: Ubuntu terminal in WSL2
Actual Behavior
- CPU usage immediately spikes to 110%+
- CPU usage remains elevated indefinitely (does not drop back down)
- Severe input lag makes the application unusable
- Occurs even with completely fresh installation (all config deleted)
Diagnostic Details
System call analysis with strace:
sudo strace -p $(pgrep claude) -c -f -e trace=futex
# After 10 seconds during lag:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00 169.127094 1471 114924 4232 futexFull system call breakdown:
83.16% 323 seconds 248,803 calls futex
8.34% 32 seconds 404,808 calls sched_yield
0.05% 196ms 11,384 calls access
0.05% 181ms 11,236 calls statx
The application spends 83% of CPU time in futex (fast userspace mutex) calls with a high error rate (4,232 errors out of 114,924 calls), indicating thread synchronization deadlock or livelock.
Thread analysis:
ps -T -p $(pgrep claude)
# Shows 17 threads including:
# - Main claude thread
# - 7 HeapHelper threads
# - 3 JITWorker threads
# - 5 Bun Pool threads
# - HTTP Client threadThe application is built with Bun runtime. The futex contention suggests an issue with Bun's thread pool synchronization on WSL2.
Timing Analysis
- Idle state: 1-2% CPU (normal)
- Typing "/": CPU immediately jumps to 110%+
- After typing "/": CPU remains at 110%+ indefinitely
- No recovery: CPU never drops back down, even after minutes
Configuration Testing
Tested with:
- ✅ Fresh installation (no previous config)
- ✅ Deleted
~/.claudeand~/.claude.json - ✅ Empty project directory
- ✅ Linux filesystem (
/home/user/code/*) - ✅ Different working directories
Result: Bug persists in all configurations.
Regression Confirmation
- v2.0.50: ✅ Works perfectly, no performance issues
- v2.0.76: ❌ Completely unusable due to this bug
This confirms the issue is a regression introduced somewhere between v2.0.50 and v2.0.76.
Additional Context
The issue appears to be in the slash command typeahead/autocomplete system. The futex spinlock is triggered immediately when the "/" character is typed, suggesting the command suggestion/completion system enters an infinite wait state.
Given that v2.0.50 works fine, this is likely related to changes made to the slash command handling, UI rendering, or Bun runtime updates between these versions.
Suspected Root Cause
Based on the diagnostics, this appears to be a compatibility issue between:
- Bun runtime's threading model
- WSL2's futex implementation
- Recent changes to the slash command autocomplete system
The changelog between v2.0.50 and v2.0.76 mentions several UI rewrites and improvements to slash command handling that may have introduced this regression.
Workaround
Downgrade to v2.0.50:
curl -fsSL https://claude.ai/install.sh | bash -s 2.0.50Impact
This bug makes Claude Code completely unusable on WSL2 (a major development platform) in the latest version. Users cannot access any slash commands without triggering this performance issue.
What Should Happen?
- Slash command autocomplete menu should appear
- CPU usage should remain low (< 10%)
- System should remain responsive
Error Messages/Logs
Steps to Reproduce
- Install Claude Code 2.0.76 on WSL2 Ubuntu 24.04 (Windows 11)
- Navigate to any directory (tested both
/home/user/code/projectand empty directories) - Run
claude - Type the "/" character
- Observe CPU usage with
topin another terminal
Claude Model
Not sure / Multiple models
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.0.5.0
Claude Code Version
2.0.67 and 2.0.76
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
WSL (Windows Subsystem for Linux)
Additional Information
No response
Activity
github-actions commentedon Dec 29, 2025
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
ltoshea commentedon Dec 29, 2025
Note: Based on the bug report #14991 where people are using "pure" linux it suggests that it's not a bug specific to WSL2 implementation.
LunarLollipop commentedon Dec 29, 2025
Note: CPU usage returns to normal after closing the menu by either deleting the "/" character or selecting an item from the list.
ylluminate commentedon Jan 9, 2026
Yep, happens on macOS as well and with the most recent release.
davidszp commentedon Jan 10, 2026
I've been experiencing the same issue on native Linux (x86-64) and — using Claude Code itself — did some investigation into the bundled
cli.js.What I found:
Two issues appear to contribute to the CPU spike:
Fuse.js index recreation — The function computing slash command suggestions creates a new Fuse.js search index on every React render cycle, rather than caching it.
React referential equality — Multiple places set state with
suggestions:[], but each[]is a new object. Since[] !== []in JavaScript, React sees every setState as a change, triggering render loops.Proof-of-concept workaround:
I put together a small patch script that demonstrates one possible fix strategy:
https://github.com/davidszp/patchclaude
It wraps the suggestion function with a simple cache and replaces
suggestions:[]with a constant empty array. After applying it, the CPU spikes disappear for me.Disclaimer: This is unofficial, for demonstration only, and modifies Anthropic's bundled code. Not recommended for production — just sharing in case it helps diagnose the root cause.
Hope this helps!
davidszp commentedon Jan 22, 2026
This issue no longer occurs for me and appears to be fixed in 2.1.14+
github-actions commentedon Feb 27, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Mar 9, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.