Session picker (claude agents) takes minutes to open sessions with large JSONL transcripts; agents view pegs CPU

Status Fixed / completed

Reported on v2.1.198

Maintainer reply ✓ Yes — bcherny

Activity 3 comments · opened Jul 6, 2026 · closed Aug 17, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Environment

Claude Code: 2.1.198
Platform: WSL2 (Ubuntu) on Windows 11, kernel 6.6.87.2-microsoft-standard-WSL2
8 cores, 16 GB RAM

Description

Opening a session from the claude agents session picker shows "opening..." for minutes before the session attaches. In the worst state it never attaches at all until the daemon (claude daemon run) and its --bg-pty-host / --bg-spare workers are killed and the stale sockets under /tmp/cc-daemon-<uid>/<hash>/rv/ are removed; after a daemon restart sessions open again but still take minutes.

Observations

Session transcript JSONL files in ~/.claude/projects/ range 10-38 MB (long-running sessions with many tool calls). Open time appears to scale with transcript size, suggesting full JSONL replay on open with no index/cache.
The claude agents process itself sustains 50-60% CPU for over an hour while idle in the picker.
Stale zero-byte sockets accumulate in /tmp/cc-daemon-<uid>/<hash>/rv/; each failed open leaves one behind. Removing them alone does not fix it; new opens create new stuck sockets until the daemon is restarted.
Archiving old large transcripts out of ~/.claude/projects/ reduces the project-list scan but does not fix the per-session open time for remaining large transcripts.

Repro

Accumulate several sessions with transcripts >10 MB (heavy tool use over days).
Run claude agents, select a session with a large transcript.
Observe "opening..." for minutes; sometimes indefinitely until the daemon is restarted.

Expected

Session open time should not require a multi-minute full-transcript replay; stuck rv sockets should time out and self-clean rather than requiring a manual daemon kill.

Notes

v2.1.200 release notes mention fixes for stalled resume and background sessions stopping; filing this in case the large-transcript open cost and the CPU spin in the agents view are separate from those fixes. Happy to test on 2.1.201 and report back.

View original on GitHub ↗

3 Comments

junaidtitan · 3 months ago

The JSONL-size correlation you've measured is the root cause — 10–38 MB transcripts are slow to open because the session picker does a full replay with no index, and your analysis "open time appears to scale with transcript size" is exactly right.

What's inside those 10–38 MB? Mostly stale dead weight accumulated over long sessions: repeated full-page WebFetch results that were looked at once, tool outputs from completed sub-tasks that never need to be re-read, duplicate system-prompt injections across compaction boundaries, accumulated progress-tick entries. Very little of it is needed to understand the current working state.

I build cozempic (github.com/Ruya-AI/cozempic) specifically for this — it prunes the JSONL file on disk, selectively removing the categories above while protecting the conversation flow, compaction summaries, and anything that needs to be preserved. On 10–38 MB sessions it typically gets the files down 2–5x (depending on how tool-heavy the session was). Standard workflow:

cozempic current --diagnose          # see the breakdown of what's in the session
cozempic treat current               # dry-run: shows what would be removed
cozempic treat current --execute     # apply (make sure Claude isn't running)

What this doesn't fix: the underlying CC architecture issue you identified. Even after treatment, a 3 MB transcript will open faster than a 1 MB one on the current implementation because there's still no incremental index — Anthropic needs to fix the session picker to not do full-JSONL replay. The pruning buys headroom, not a permanent fix.

If you try it on your 10–38 MB sessions, I'd be curious what sizes you end up with and whether open time actually improves proportionally — that would help validate the "full replay" hypothesis. Happy to take an issue on github.com/Ruya-AI/cozempic if any session fails to open after treatment (that's a bug).

bcherny collaborator · 2 months ago

Thanks for the detailed report and the repro recipe. I followed it on 2.1.233 on Linux: fabricated a 30 MB / ~10,000-turn session transcript (valid uuid/parentUuid chain), opened it from the claude agents picker in tmux, and timed the open — both warm and cold, including after killing the daemon and its workers so stale sockets were left behind. The session attached in 1–3 seconds every time, with only a brief CPU burst and no pegged cores.

I also repeated the exact test on your version, 2.1.198, on the same machine: a cold open of the 30 MB session attached in ~2 seconds, and reopening worked even with stale sockets present under /tmp/cc-daemon-*/…/rv/.

Since 2.1.198, several related fixes have shipped: 2.1.214 fixed stale daemon sockets and background sessions that couldn't be reopened or removed, and 2.1.216 fixed a slowdown where per-turn processing cost grew quadratically in long sessions, causing multi-second stalls and slow resumes — see the changelog.

Given you saw minutes where native Linux shows seconds, WSL2 file I/O may be amplifying this — make sure ~/.claude lives on the Linux filesystem (ext4), not under /mnt/c, and check whether Windows Defender is scanning the WSL distro.

Closing as likely fixed in a recent release — please update and reply to reopen if opening large sessions is still slow on the latest version.

🤖 Generated with Claude Code

github-actions[bot] · 9 days ago

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.