Claude Code Slow, Hanging, or Eating Memory? Start With the Silent Failures

If Claude Code is slow, hanging, or eating memory, the useful first move is /doctor — it checks your installation, settings, extensions and context usage, and proposes fixes it can apply after you confirm. If it won't start at all, run claude doctor from your shell instead.

But the causes worth knowing are the ones that produce no error at all. Slowness that announces itself is easy; what costs you a day is the failure that reports everything as fine.

The silent one: search quietly returns fewer results on WSL

This is the failure I'd check first if you're on Windows, because nothing tells you it's happening.

Working across file systems on WSL carries a disk read performance penalty, and the practical effect is that searches return fewer matches than they should. Search still works. It just misses things.

And the part that makes it genuinely nasty:

claude doctor shows Search as OK in this case.

So you get a green check, an agent that seems to not understand your codebase, and no error anywhere. Three fixes, in order of effectiveness:

1. Move the project onto the Linux filesystem — /home/ rather than /mnt/c/. This removes the penalty rather than working around it.
2. Run natively on Windows instead of through WSL, for better filesystem performance.
3. Narrow your searches — "Search for JWT validation logic in the auth-service package" instead of a repo-wide sweep.

The other silent one: bundled ripgrep won't run

If the Search tool, @file mentions, custom agents or custom skills aren't finding files, the bundled ripgrep binary may not run on your system at all.

Install your platform's package:

# macOS
brew install ripgrep
 
# Ubuntu/Debian
sudo apt install ripgrep
 
# Windows
winget install BurntSushi.ripgrep.MSVC

Then point the CLI at it, either in your shell environment or the env block of settings.json:

{
  "env": {
    "USE_BUILTIN_RIPGREP": "0"
  }
}

Verify it actually took effect rather than assuming: run claude doctor and check that the Search line shows the path to your system ripgrep instead of OK (bundled).

Autocompact is thrashing — what it actually means

If you hit this:

Autocompact is thrashing: the context refilled to the limit...

it does not mean compaction failed. Compaction succeeded — and then a file or tool output immediately refilled the context window, several times in a row. It stops retrying deliberately, to avoid burning API calls on a loop that isn't making progress.

That tells you the real problem: something in your workflow is dumping an enormous payload into context. Recovery, in order:

1. Ask Claude to read the oversized file in chunks — a line range or a single function, not the whole file.
2. Run /compact with a focus that drops the offending output: /compact keep only the plan and the diff.
3. Move the large-file work to a subagent so it runs in its own context window and only a summary comes back.
4. /clear if the earlier conversation no longer matters.

A related gotcha: /compact can return Not enough messages to compact. even when your context is full — that happens when a single large paste filled it, so there aren't enough turns to summarize.

High CPU or memory

Work through these before reaching for diagnostics:

• /compact regularly to keep context size down.
• Restart between major tasks. Long-lived sessions accumulate.
• Add large build directories to .gitignore.
• Restart with claude --safe-mode. This is the one people skip, and it's the highest-signal step: it disables every customization for the session. If usage drops, a plugin, MCP server or hook is your culprit, and you can bisect from a clean configuration.

If memory stays high after all that, /heapdump writes a heap snapshot and a diagnostics file to your Desktop, and prints a summary showing resident set size, JS heap, array buffers and unaccounted native memory, plus leak indicators like a high growth rate or an unusual number of open handles. The command doesn't appear in the command menu — type it in full.

⚠️ Do not attach the .heapsnapshot to a public issue. It contains every string in the process, which means your full conversation and your credentials. If you're reporting a bug, attach only the -diagnostics.json, which carries the statistics and no conversation content.

The summary also tells you whether memory is in the JS heap — which the snapshot captures, and which you can inspect in Chrome DevTools under Memory → Load, sorted by retained size — or in native memory, which it doesn't capture at all.

Hangs, and the fear of losing your session

If the CLI stops responding: press Ctrl+C to cancel the current operation. If it stays unresponsive, close the terminal.

Restarting doesn't lose your conversation. Run claude --resume in the same directory and pick the session back up. People tolerate a frozen terminal for far too long because they assume otherwise.

Two display problems that look like bugs

Slow rendering is one thing; garbled or corrupted text in the VS Code, Cursor or Devin Desktop integrated terminal is another — characters rendering as boxes, smears or wrong glyphs — is almost always the terminal's GPU renderer. Run /terminal-setup to switch terminal.integrated.gpuAcceleration to "off", then reload the window.

A truncated table isn't data loss. A Markdown table over 200 rows renders the first 200 followed by … N more rows not shown. Only the display is capped — the full table is still in the conversation, and /copy copies every row. For anything genuinely large, ask Claude to write it to a file instead.

When it's cost, not performance

Being slow and being expensive get conflated, and they have different fixes. If the symptom is your plan limit disappearing rather than the CLI feeling sluggish, the causes are different — long context re-sent on every turn, prompt cache expiry, idle sessions still spending. I covered those separately in why Claude Code burns tokens while you're not even using it.

And if the symptom is specifically that tools aren't available rather than slow, that's usually configuration rather than performance — see MCP server not showing up in Claude Code.

The pattern across all of these: the loud problems are the easy ones. A hang tells you it's hung. What costs you a day is search quietly returning half the matches while every diagnostic reports OK — so when the agent seems to have stopped understanding your codebase, check the silent failures before you rewrite your CLAUDE.md.

I run Claude Code on Windows daily, which is where most of these bite hardest; ContextZero came out of the adjacent problem of controlling what these tools know about a project in the first place.