Repository navigation
[Bug]: Claude Code session import skips long sessions (transcript over 32 MiB memory budget) #29153
Description
Before submitting
- I searched existing issues and did not find a duplicate. The 32 MiB limit is only mentioned in a comment on [Bug]: Session import is unreachable after onboarding, so externally started sessions can never be imported #10961, which is about a different problem: the import being unreachable after onboarding.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server (Claude Code session import / AgentSessionImporter)
Steps to reproduce
- Have a long-running Claude Code session whose transcript
~/.claude/projects/<encoded-cwd>/<sessionId>.jsonlis over 32 MiB. Sessions that run for days and auto-compact many times grow well past that. - Import Claude Code sessions for that project (
agentSessions.import, through the/welcomewizard or a direct RPC call).
Expected behavior
The session is imported, and continuing it resumes the native Claude Code session (resume: <sessionId>), just like claude --resume <sessionId> in the terminal.
Actual behavior
The session is skipped on every run and counted in skippedCount. The server trace logs:
Could not read imported transcript … Transcript selected history exceeds the 32 MiB memory budget
The UI doesn't say why the session is missing.
Impact
Long-running sessions are the ones people most want to move into T3 Code, and they're exactly the ones that can't be imported. My main working session is 1.6 GB (about 305k lines). Another user on #10961 reported 57 MB, 76 MB and 107 MB sessions skipped on every run.
Version or commit
T3 Code desktop 0.1.6 (Beta). Claude Code CLI 2.1.316.
Environment
Windows 11, desktop app, default Claude Code provider instance (~/.claude).
Logs or stack traces
See above, as reported in #10961.
Suggested direction
- Read the transcript in a streaming way with a bounded window. The parser only keeps the first user message and the last ~199 messages anyway. Keeping a rolling window of recent records while reading, instead of everything up to the budget, would let any size import. Alternatively, start from the last
compact_boundaryrecord. - Don't load the full history for Claude threads at all. The model's context comes from the native resume (
resume: <sessionId>), so the importer needs only enough to show recent history and a title. This also fits the note on [Bug]: Imported Claude Code threads fail on their first follow-up with "Session ID … is already in use" #15243 that themanual_contexthandoff is redundant for resumed Claude threads. - Say why a session was skipped, for example "too large", "changed during read (still open in Claude Code)" or "older than 30 days".
Workaround
None in the app. The only way I found is to edit statev2.sqlite with T3 closed, pointing an existing Claude thread's nativeThreadRef.nativeId (and the matching provider-thread.updated / run-attempt.updated events) at the large session's ID. That isn't something users should have to do.
Related
- [Bug]: Session import is unreachable after onboarding, so externally started sessions can never be imported #10961: import unreachable after onboarding
- [Bug]: Imported Claude Code threads fail on their first follow-up with "Session ID … is already in use" #15243: imported Claude threads fail on the first follow-up
- [Feature]: Continue a Codex or Claude Code session started in the terminal as a T3 Code thread #15234 / Discussion [Feature]: continue threads from claude code #6873: per-session continue
Drafted with Claude Opus 5.5 in T3 Code.
Activity
Abirouk commentedon Nov 6, 2026
Two things about this budget from reading AgentSessionScanner.readTranscript and AgentSessionJson.createTranscriptJsonReader on main, checked against a transcript of mine.
The budget is not message text. The reader charges 64 bytes per selected JSON token plus two bytes per character of selected strings, and two bytes per character of every key in the record, selected or not. historyBytes grows by that amount for each record shouldRetainDecodedRecord keeps and never resets, so it accumulates over the whole file, not over the 200 messages the import keeps. Applying that accounting to a 34.5 MiB transcript of mine (about 2,980 lines, 62 retained user and assistant records, 23 KB of visible text) gives about 0.32 MiB, roughly 4.5 KB per retained record before any text. At that rate about 7,500 retained records exhaust 32 MiB with no text at all, so a long session trips the budget on record count. That is why the rolling window in the suggested direction would hold up where a bigger budget would only move the record count.
The 1.6 GB file in the report is also about 305k lines, which is over MAX_IMPORT_RECORDS (100,000). Once the budget stops throwing, that cap skips the same file silently (#31677), so both limits need to change for this transcript to import.