[Bug]: Session import turns every Codex subagent into its own top-level thread #16222

Activity

1. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the detailed report and the thread counts, @alcxyz! That made this easy to trace.

   What I found

   • Codex history import treats every rollout-*.jsonl under ~/.codex/sessions as its own conversation. A spawn_agent child is written as a separate rollout with the same cwd as its parent, so project discovery counts it and import publishes it as a top-level thread (parentThreadId: null).
   • The title comes from the first line of the first user message, which on child rollouts is injected setup text (# AGENTS.md instructions, <recommended_plugins>, and so on), which explains the odd titles.
   • parseAgentSessionRecords only reads payload.id / payload.session_id from session_meta. TranscriptRecord doesn't declare payload.source, and the decode drops unknown fields, so the parent link is lost before the import decision.
   • Top-level Codex sessions use a string source (cli, exec, vscode, appServer, unknown) or {custom}. Child rollouts use an object key: subagent on disk, subAgent in the app-server session schema. Its value isn't only thread_spawn; it also covers review, compact, memory_consolidation, and other.
   • This is separate from Bug: Imported Codex tasks use <recommended_plugins> as their titles #10513 (bad titles on real top-level sessions). fix(server): prevent duplicate and subagent history imports #11807 tried to cover both and was closed unmerged, so the subagent exclusion never landed. fix(server): skip imports of native agent sessions #10950 and fix(server): skip native sessions during bulk import #15634 only skip sessions T3 already owns.

   Likely fix area

   • AgentSessionScanner.ts / parseAgentSessionRecords: one option is to decode payload.source and exclude a rollout when the subagent/subAgent key is present, rather than only when thread_spawn is set.
   • Where the check runs matters. Reporting these as Skipped would bump skippedCount, which onboarding shows as "could not be imported" and which keeps the project out of the fully-imported set. Returning null from the parser may also be too late, since each file is reserved against the 100-transcript import budget before parsing, so child rollouts could crowd out real sessions.
   • The same check likely belongs in the project-candidate transcript count, since child rollouts share the parent's cwd.
   • For comparison, Claude import also doesn't attach subagents to a parent thread (it drops sidechain/meta records), so linking Codex children into their parent during import would be a separate change. A fix here wouldn't remove threads that were already imported.

   A maintainer will decide on the fix direction.

   👍React with 👍1Reacted by André Lucas Carvalho
2. juliusmarminge

   added

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

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 5, 2026
3. SriCharanK2002 commented on Oct 19, 2026

   

   SriCharanK2002

   on Oct 19, 2026

   More actions

   Still reproduces on desktop 0.1.0 (macOS, codex-cli 0.162.1) through the onboarding import. One user's import created 30 import:codex:* threads that are subagent rollouts, out of 130 Codex imports.

   Two additions:

   1. There's more than one kind of subagent. Besides {"subagent": {"thread_spawn": {"parent_thread_id": …}}}, this machine has many rollouts whose session_meta.payload.source is {"subagent": {"other": "guardian"}}. Of 389 Codex sessions active in the last 30 days, 260 were subagent sessions, and about 180 of those were guardian. A filter that only checks thread_spawn would miss them, so checking for source.subagent of any kind seems safer.
   2. They also cost real conversations. Subagent rollouts count against the per-project 100-transcript import budget, even when they're then rejected for having no user message. In one project they took 43 of the 100 slots, which pushed 40 Claude Code conversations out of that import (details in [Bug]: Shared import record limit skips valid conversations #17484).

   Comment prepared by Claude Code (claude-opus-5-5) via t3 triage.
4. juliusmarminge

   closed this as completedin #16662on Oct 19, 2026