Bug
txcript version: main (HEAD as of 2026-09-17)
Agent: Codex CLI, local sessions (default --from codex, no --from chatgpt involved)
Codex CLI has a native archive feature: the TUI's /archive and the codex archive / codex unarchive CLI commands move a rollout out of the date-sharded ~/.codex/sessions/YYYY/MM/DD/ tree into a flat sibling directory, ~/.codex/archived_sessions/ (or $CODEX_HOME/archived_sessions when CODEX_HOME is set). The archived files keep the same rollout-<timestamp>-<uuid>.jsonl naming and internal format, just without the date subdirectories.
CodexStore::discover() in src/harness/codex.rs only walks self.sessions_dir (CODEX_HOME/sessions or ~/.codex/sessions, set in CodexStore::default_root()). It never looks at archived_sessions/, so any session archived through Codex's own archive feature is invisible to txcript list --from codex / view / MCP list_sessions until it's unarchived back into sessions/.
Confirmed on a real machine: ~/.codex/archived_sessions/ held 531 flat rollout-*.jsonl files going back to the very first session, none of which txcript list --from codex returned.
(This is unrelated to #52/#53, which were about the separate chatgpt.com-cloud harness. My original report in #52 mixed the two up — the actual repro was this local-archive gap.)
Expected
Discovery should also enumerate rollouts under archived_sessions/, so an archived Codex session is still visible to txcript (even though codex archive's own UI hides it from Codex's session picker).
Proposed fix
Give CodexStore an optional archived_sessions_dir, set by default_root() to the sibling archived_sessions directory, and have discover() walk both sessions_dir and (when present) archived_sessions_dir, merging the results. CodexStore::new() keeps its current single-argument shape (it's also used to construct a fresh store when writing a new session, which should always land in sessions_dir, never archived_sessions_dir).
Happy to open a PR for this.
Bug
txcript version: main (HEAD as of 2026-09-17)
Agent: Codex CLI, local sessions (default
--from codex, no--from chatgptinvolved)Codex CLI has a native archive feature: the TUI's
/archiveand thecodex archive/codex unarchiveCLI commands move a rollout out of the date-sharded~/.codex/sessions/YYYY/MM/DD/tree into a flat sibling directory,~/.codex/archived_sessions/(or$CODEX_HOME/archived_sessionswhenCODEX_HOMEis set). The archived files keep the samerollout-<timestamp>-<uuid>.jsonlnaming and internal format, just without the date subdirectories.CodexStore::discover()insrc/harness/codex.rsonly walksself.sessions_dir(CODEX_HOME/sessionsor~/.codex/sessions, set inCodexStore::default_root()). It never looks atarchived_sessions/, so any session archived through Codex's own archive feature is invisible totxcript list --from codex/view/ MCPlist_sessionsuntil it's unarchived back intosessions/.Confirmed on a real machine:
~/.codex/archived_sessions/held 531 flatrollout-*.jsonlfiles going back to the very first session, none of whichtxcript list --from codexreturned.(This is unrelated to #52/#53, which were about the separate
chatgpt.com-cloud harness. My original report in #52 mixed the two up — the actual repro was this local-archive gap.)Expected
Discovery should also enumerate rollouts under
archived_sessions/, so an archived Codex session is still visible to txcript (even thoughcodex archive's own UI hides it from Codex's session picker).Proposed fix
Give
CodexStorean optionalarchived_sessions_dir, set bydefault_root()to the siblingarchived_sessionsdirectory, and havediscover()walk bothsessions_dirand (when present)archived_sessions_dir, merging the results.CodexStore::new()keeps its current single-argument shape (it's also used to construct a fresh store when writing a new session, which should always land insessions_dir, neverarchived_sessions_dir).Happy to open a PR for this.