[Bug]: Shared import record limit skips valid conversations #17484

Activity

1. diogovalada

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 9, 2026
2. SriCharanK2002 commented on Oct 19, 2026

   

   SriCharanK2002

   on Oct 19, 2026

   More actions

   Reproduced on desktop 0.1.0 (macOS) with a related limit: the per-project transcript cap, MAX_IMPORT_TRANSCRIPTS = 100 (AgentSessionScanner.ts:95), rather than the record cap.

   One project had 148 eligible .jsonl transcripts, Codex and Claude together. prepareRecentThreads sorts them newest-first by mtime and reserves budget for every file it reads, including ones that then fail to parse. The onboarding trace shows exactly 100 AgentSessionScanner.readTranscript spans for that project's import, followed by silent skips:

   • 43 of the first 100 files were Codex subagent rollouts ([Bug]: Session import turns every Codex subagent into its own top-level thread #16222). 24 became top-level threads, and 19 were rejected for having no user message, but still used up budget.
   • That pushed 40 Claude Code conversations past position 100. They were reported only as part of "N threads could not be imported".
   • The record cap wasn't the limit here: those 148 files total about 81k records.

   Re-running the import (location.hash = '#/welcome' in the desktop DevTools) recovered all of them, because already-imported files with an unchanged identity don't consume budget. So the behavior is correct but invisible: nothing tells the user that a second run would import more, and there's no way to get back to the wizard after onboarding (#10961).

   +1 to batching automatically until no new files remain, or at least reporting "N skipped because of the import limit, run again to continue". Filtering subagent rollouts before budgeting would also help a lot.

   Comment prepared by Claude Code (claude-opus-5-5) via t3 triage.
3. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   Reproduced on current main 70e5e384da with the web client and a Linux dev server. Four synthetic Codex conversations in one project contained 20,000, 20,000, 20,000 and 58,000 JSONL records, newest first. The wizard discovered all four, then imported three and reported one could not be imported. Retrying imported the fourth conversation. Runtime transcript. No duplicate found in the open-issue scan.

   👍React with 👍1Reacted by Diogo Valada
4. mthsmb commented on Oct 29, 2026

   

   mthsmb

   on Oct 29, 2026

   More actions

   A related data point on 0.1.5 (Windows 11 desktop app + WSL2 backend), about the per-attempt file limit rather than the record limit:

   • One project had 308 Claude Code sessions in the 30-day window. Because of MAX_IMPORT_TRANSCRIPTS = 100, it took three manual wizard runs, plus a fourth to confirm nothing was left. Each run ended with "Imported N threads. M threads could not be imported." The docs do say "Run import again to continue a large batch", but the toast reads like a failure, so it's easy to assume the remaining conversations are broken.
   • Empty Codex sessions count as failures. Four rollouts that contain only session_meta and thread_settings_applied (opened in the VS Code extension and never used) show up as "4 threads could not be imported" on every run, permanently.

   In line with this issue's expected behavior: continue in batches automatically until done (or offer a Continue action), report "deferred by the batch limit" separately from "unreadable", and don't count sessions with no user messages as failures.

   There is also a separate scan-stage limit that re-running cannot get past: #27163.

   I've also opened an idea for making these limits configurable: #27165.
5. juliusmarminge

   closed this as completedin #23192on Nov 3, 2026