Skip to content

[BUG] Critical performance regression on WSL2: Slash commands trigger infinite futex spinlock causing 110% CPU usage (v2.0.76 & v2.0.67) #15689

Closed as not planned

Description

@ltoshea

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 futex

Full 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 thread

The 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 ~/.claude and ~/.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:

  1. Bun runtime's threading model
  2. WSL2's futex implementation
  3. 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.50

Impact

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

  1. Install Claude Code 2.0.76 on WSL2 Ubuntu 24.04 (Windows 11)
  2. Navigate to any directory (tested both /home/user/code/project and empty directories)
  3. Run claude
  4. Type the "/" character
  5. Observe CPU usage with top in 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

  1. github-actions commented on Dec 29, 2025

    @github-actions

    Found 1 possible duplicate issue:

    1. [Bug] High CPU usage when opening menu list with "/" #14991

    This issue will be automatically closed as a duplicate in 3 days.

    • If your issue is a duplicate, please close it and 👍 the existing issue instead
    • To prevent auto-closure, add a comment or 👎 this comment

    🤖 Generated with Claude Code

  2. ltoshea commented on Dec 29, 2025

    @ltoshea
    Author

    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.

  3. LunarLollipop commented on Dec 29, 2025

    @LunarLollipop

    Note: CPU usage returns to normal after closing the menu by either deleting the "/" character or selecting an item from the list.

  4. ylluminate commented on Jan 9, 2026

    @ylluminate

    Yep, happens on macOS as well and with the most recent release.

  5. davidszp commented on Jan 10, 2026

    @davidszp

    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:

    1. 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.

    2. 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!

  6. davidszp commented on Jan 22, 2026

    @davidszp

    This issue no longer occurs for me and appears to be fixed in 2.1.14+

  7. github-actions commented on Feb 27, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  8. github-actions commented on Mar 9, 2026

    @github-actions

    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.

  9. locked as resolved and limited conversation to collaborators on Mar 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinghas reproHas detailed reproduction stepsperf:memoryplatform:windowsIssue specifically occurs on WindowsstaleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions