bug(storage): Claude Code transcripts over 64 MiB vanish from the import catalog with no explanation #5140

What happened

Claude Code transcripts larger than CLAUDE_TRANSCRIPT_MAX_BYTES (64 MiB) are silently omitted from the External Session import catalog. They never appear in Desktop → Settings → Import Tasks → Claude Code, so the user cannot select them, retry them, or even see that they exist — no row, no error, no hint.

Reproduced locally: of 1186 transcripts under ~/.claude/projects/<proj>/*.jsonl, 3 exceed the cap — 155.8 MiB, 135.9 MiB and 66.8 MiB — and two of those were written in the last 48 hours. Every one of them is invisible in the catalog.

This is the Claude Code counterpart of #4642 (Codex rollouts over 64 MiB). It is worse than the Codex case was: there the session was at least listed and the limit surfaced on Import; here the session is absent with no signal at all.

How to reproduce

1. Have a Claude Code transcript larger than 64 MiB at ~/.claude/projects/<encoded-cwd>/<uuid>.jsonl (long sessions reach this; 155 MiB observed locally).
2. Open Desktop → Settings → Import Tasks → Claude Code.
3. The session is absent from the catalog, with nothing explaining why.

Root cause

packages/storage/src/claude-code-session-adapter.ts:

• #parse() (line 253): if (info.size > this.#maxBytes) return undefined;, where #maxBytes defaults to CLAUDE_TRANSCRIPT_MAX_BYTES = 64 MiB (line 61). The whole file is then read with readFile(path, 'utf8') (line 261), so the cap is what bounds memory — that part is correct.
• #summaryOf() caches the undefined result, and listSessions() does if (!summary) continue, so the oversized session is dropped from the catalog entirely.
• readSession() re-parses the same way, so even a direct import attempt would fail with Claude Code transcript could not be read: <id>.

The defect is that the size limit is enforced as absence rather than as a reported, unimportable state. (The Codex adapter, after #4642/#4227, bounds the read and reports the limit instead.)

Expected

Either import the session within bounded limits (windowed / streaming read instead of one whole-file string), or list it as present-but-unimportable with an actionable, sanitized message that names the 64 MiB limit — the way Codex now does. What must not happen is a real session disappearing from the catalog with no explanation.

Environment

• Maka main: f09119884 (2026-09-10)
• OS: macOS (Darwin 24.6.0)
• Surface: Desktop; the same adapter backs the CLI catalog, so it is affected too.

Additional context (secondary, can ride along)

Same adapter, and the same "the scanner and the importer must not disagree" contract the file's own header states: collectTitle() (line 326) dispatches on record.type but has no custom-title case, while the shared scanner reads the record.customTitle field regardless of type (@maka/core/foreign-session).

Current Claude Code writes {"type":"custom-title","customTitle":"…"} records — measured 491 such records across 400 local transcripts (15 files). The importer ignores them, so those sessions show the first user prompt instead of the title the user explicitly set. Lower severity than the drop above, but it is the exact scanner/importer divergence the comment warns against.