claude-code - 💡(How to fix) Fix Claude Desktop (Windows): ~25% CPU + ~5 MB/s sustained disk writes when idle -- TanStack Query persistQueryClient rewrites entire conversation cache (~45 MB) under one IndexedDB blob on every mutation [5 comments, 2 participants]

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?

Claude Desktop's Electron main process sits at ~25% CPU continuously and writes ~5 MB/s sustained to disk (peaks 65–83 MB/s) even with zero user interaction. Over a 4-hour idle session this produced 67.9 GB of writes to %APPDATA%\Claude\IndexedDB\https_claude.ai_0.indexeddb.blob\.

Root cause: the renderer uses React Query's persistQueryClient to cache the entire conversation list — including full message bodies, tool-use outputs, and base64-encoded image attachments — under a single IndexedDB key named conversations_v2:<unix-ms-timestamp>. The persister rewrites the whole ~45 MB blob on every cache mutation (new message, server tick, anything). Four libuv pool threads (default UV_THREADPOOL_SIZE) in the main process are pegged at ~58% per core draining the renderer↔main IPC that this churn generates.

Structural, not stale-state: deleting the IndexedDB origin and relaunching reproduces the same pattern within ~2 minutes as the renderer rehydrates from server.

Blob content inventory (44.7 MB blob from a fresh-rehydrated cache, ASCII-scanned): 1 React Query key (conversations_v2:1777833625930), 1,781 distinct UUIDs, 39.5 MB of contiguous message-body text, biggest single text run 435,215 chars, 300 occurrences of base64 (inlined image attachments), ~300 repetitions each of cache_read_input_tokens / cache_creation_input_tokens / output_tokens / ephemeral_1h_input_tokens / ephemeral_5m_input_tokens.

What Should Happen?

The persistence layer should not rewrite the entire conversation graph on every mutation. Ordered by effort:

1. Throttle persister writes (e.g. throttleTime: 5000) so bursts coalesce into one disk write — drops write rate ~10x by itself.
2. Persist metadata only (id, title, model, last-message preview, timestamps), not full message bodies. Lazily refetch content when a conversation is opened.
3. Split per-conversation cache keys — replace one conversations_v2:<ts> key with conversation:<uuid> per conversation, persisted independently, so a mutation in one doesn't rewrite the bytes of all others.
4. Move conversation storage off persistQueryClient+blob entirely (IndexedDB object store, one record per conversation, or worker-backed SQLite).

A minimal first PR (1 + the metadata-only half of 2) should take write rate from ~5 MB/s to ~50 KB/s without touching the data model.

Error Messages/Logs

No errors are logged — bug is silent and steady-state. Repro evidence from process telemetry:


$main = Get-CimInstance Win32_Process -Filter "Name='Claude.exe'" |
    Where-Object { $_.CommandLine -notmatch '--type=' -and $_.CommandLine -notmatch 'claude-code\\' }
$pid = $main.ProcessId
$p = Get-Process -Id $pid
"uptime min: $([int]((Get-Date - $p.StartTime).TotalMinutes))"
"cores avg:  $([Math]::Round($p.CPU/((Get-Date - $p.StartTime).TotalSeconds),2))"
$i1 = Get-CimInstance Win32_Process -Filter "ProcessId=$pid"
Start-Sleep 3
$i2 = Get-CimInstance Win32_Process -Filter "ProcessId=$pid"
"WriteMB/s: $([Math]::Round((($i2.WriteTransferCount-$i1.WriteTransferCount)/3)/1MB,2))"
$blob = "$env:APPDATA\Claude\IndexedDB\https_claude.ai_0.indexeddb.blob\1\3a"
$a = Get-ChildItem $blob -File; Start-Sleep 60; $b = Get-ChildItem $blob -File
"hex-slot advance 60s: $([Convert]::ToInt32($a[0].Name,16)) -> $([Convert]::ToInt32($b[0].Name,16))"
"blob MB: $([Math]::Round($b[0].Length/1MB,1))"


My output (4h idle, account with accumulated history):


uptime min: 241
cores avg:  2.67       (= ~22% of 12-core box = ~25% in Task Manager)
WriteMB/s: 4.7         (peaks 65-83)
hex-slot advance 60s: 14974 -> 14975   (one ~45 MB rewrite per minute idle)
blob MB: 44.7


Top 4 threads in the main process each accumulated ~8400 CPU-seconds over 14,472 wall-seconds (~58% of a core sustained since process start) — that's the libuv default pool draining IPC.

Steps to Reproduce

Requires an account that has accumulated enough conversations to make the cache large (mine has ~1,800 distinct UUIDs).

1. Quit Claude Desktop fully — the Electron single-instance lock means closing the window is not enough. Kill every Claude.exe PID under WindowsApps\Claude_…\app\Claude.exe.
2. Optional clean start: Remove-Item -Recurse -Force "$env:APPDATA\Claude\IndexedDB\https_claude.ai_0.indexeddb.*"
3. Launch Claude Desktop. Do not interact.
4. Task Manager: the main Claude.exe (parent = explorer.exe, no --type= arg) sits at ~25% CPU on a 12-core box within ~30 seconds.
5. Run the PowerShell snippet in Error Messages/Logs. The hex-slot under IndexedDB\https_claude.ai_0.indexeddb.blob\1\3a\ advances at least once per minute idle — each advance is one full ~45 MB rewrite.
6. To confirm the bug is structural, repeat from step 1 — same pattern returns within ~2 minutes of relaunch as the renderer rehydrates from server.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

Unknown -- account is large enough that this likely manifests on any recent version once the persisted cache grows

Claude Code Version

Claude Code 2.1.138 (hosted in Claude Desktop 1.7196.0.0)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Existing similar reports (closed, distinct root causes):

• #43390 — 8-13 GB/h writes on macOS, but attributed to vm_bundles/claudevm.bundle/ (the Cowork VM disk image), a different subsystem from the IndexedDB blob path in this report. Same end-user symptom, different file path; both probably worth fixing.
• #35556 — macOS vnode exhaustion + kernel panic, symptom-only, no root cause named. The persistQueryClient churn in this report is a plausible upstream cause.
• #32020 / #32012 — "Claude Desktop renderer 80%+ CPU when idle." Same CPU symptom; the 45 MB-blob churn explains it cleanly.

Side bug, same desktop instance: the main Claude.exe accumulates headless ConPTY conhost children that are never reaped when their Claude Code CLI session inside the desktop exits. 9 alive after a 4-hour session, 4 with no shell process inside and no nearby CLI start. Idle (0% CPU) but leak handles/PIDs. Look at node-pty teardown in the Claude Code embedding path. Happy to file separately if preferred.

Environment: Lenovo Legion desktop, 12 logical cores, NVMe SSD. Install path C:\Program Files\WindowsApps\Claude_1.7196.0.0_x64__pzs8sxrjxfjjc\app\Claude.exe. IndexedDB origin %APPDATA%\Claude\IndexedDB\https_claude.ai_0.indexeddb.{blob,leveldb}. Long-time Claude Code + Cowork user, ~1,800 conversation UUIDs cached.

Available on request (contain private message content, so not attached): sample ~45 MB blob, 4-hour Win32 process IO-counter dump, PowerShell reaper for the orphan conhosts.