Session import scan stops at a fixed 64 MiB metadata budget, so the oldest sessions can never be imported #27163

What happened

I wanted to import all Claude Code sessions from a WSL2 backend. After repeated import runs, about 80 sessions inside the 30-day window were never offered or imported, however many times I re-ran import. The welcome wizard can show "Scan limit reached. Some projects or conversations may be missing.", but there is no way past it. Re-running the scan always stops at the same place.

Diagnosis

collectCandidates in apps/server/src/project/AgentSessionScanner.ts sorts transcripts newest first. It reads each one in 8 KiB chunks until it finds a record with cwd, and charges every read to MAX_METADATA_BYTES_PER_SOURCE (64 MiB per source). In Claude Code transcripts the first cwd record can sit behind, or inside, large records: here it cost about 150 KB per transcript on average. The budget ran out at transcript 443 of 524. Every older transcript gets no cwd, never joins a project candidate, and is invisible to prepareRecentThreads.

Because the order is always newest first, and already-imported transcripts are read again on every scan, re-running import can never get past the cut-off. The AlreadyImported shortcut in prepareRecentThreads does not help: the scan stage runs first and has already dropped the older transcripts.

docs/user/welcome-wizard.md documents the scan limit as a warning, but it gives no way to import the rest.

Possible directions: skip metadata reads for transcripts already recorded as imported, make the scan budget continuable or per project, or stream only the cwd field so large records cost less.

Steps to reproduce

1. Have enough recent Claude Code transcripts in ~/.claude/projects that reading up to each file's first cwd record exceeds 64 MiB in total. Here: 524 transcripts, about 150 KB each on average.
2. Open /welcome, select every project and import. Re-run until no new threads appear.
3. Compare the imported thread IDs (import:claudeAgent:<session id>) with the ~/.claude/projects/*/*.jsonl files inside the 30-day window. The oldest transcripts are never imported, and they all fall after one mtime cut-off.

Version

0.1.5

Environment

Windows 11 desktop app with a WSL2 (Ubuntu) backend, server 0.1.5 on both. The affected Claude Code transcripts are on the WSL backend.

Evidence

# Claude Code transcripts in the 30-day window: 519 (524 in total)
# Re-simulated scan metadata reads (newest first, 8 KiB chunks up to the first cwd record):
64 MiB budget exhausted at transcript #443 of 524 (mtime 2026-10-03 02:31)

# Imported vs. on disk, per project, after 4 import runs:
project A: 260 / 308   # the 48 missing are exactly the transcripts older than the cut-off
project B:   6 / 16
project C:   7 / 11
project D:   3 / 8
project E:  23 / 26

# 4th run: 0 new threads. Every missing transcript is older than the cut-off.
# After temporarily moving the already-imported transcripts out of ~/.claude/projects:
# scan used 19 MiB, the import added the missing threads, and every project matched.

Related issues

#17484 (per-import record budget, a different constant at a later stage), #21764 (mtime-based ordering), #10961 (no entry point after onboarding). None covers the scan-stage MAX_METADATA_BYTES_PER_SOURCE cut-off.

Fix applied or workaround

I temporarily moved the already-imported transcripts out of ~/.claude/projects. They stayed on the same filesystem, so inode and mtime were preserved. Then I reloaded the app (Ctrl+R), re-ran import and moved the files back. The reload is needed: without it the wizard reused the previous scan result, and the server's cached candidates still pointed at the moved files. That run reported every moved file as "could not be imported".

Filed by

Claude Code (Claude Opus 5.5) in a T3 Code triage session