Repository navigation
migrate-rollouts makes session_index-only thread names disappear #38761
Description
What version of Codex CLI is running?
codex-cli 0.148.0-alpha.9. I also reproduced the relevant behavior on main at commit a7edf37cb46b5fc4d50bd03df8e5999a86f602eb.
What subscription do you have?
Not applicable. This happens during an offline local-store migration.
Which model were you using?
No model call is involved.
What platform is your computer?
macOS arm64.
What terminal emulator and version are you using (if applicable)?
Not relevant to the reproduction.
Codex doctor report
Not attached. I can reproduce this with a synthetic Codex home, and a doctor report would include unrelated local-state information.
What issue are you seeing?
After codex migrate-rollouts --apply, a legacy thread can lose its display name even though the matching entry is still present in session_index.jsonl.
The index entry is not deleted. The problem is that the migration changes which name source is used:
- A legacy thread can have
threads.name IS NULLand get its effective name fromsession_index.jsonl. - Legacy reads and lists fall back to that index entry.
- The migration changes
history_modetopaginated, but does not copy the effective name intothreads.name. - Paginated reads use SQLite display metadata and no longer consult the legacy index for that thread.
The same thread is therefore named before migration and unnamed afterward. Searching for the old name also stops finding it.
What steps can reproduce the bug?
I used an isolated temporary Codex home with synthetic data:
All identifiers, names, timestamps, and rollout contents below are synthetic.
-
Create a valid legacy rollout and a matching SQLite
threadsrow withhistory_mode = 'legacy'andname = NULL. -
Add this entry to
session_index.jsonl:{"id":"00000000-0000-7000-8000-000000000001","thread_name":"named legacy thread","updated_at":"2026-08-15T00:00:00Z"} -
Read or list the thread and confirm that its name is
named legacy thread. -
Run
codex migrate-rollouts --apply --thread 00000000-0000-7000-8000-000000000001against the temporary home. -
Read or list the thread again.
After step 5, the rollout and SQLite row are paginated, threads.name is still NULL, and the displayed name is gone. The synthetic index entry is unchanged.
What is the expected behavior?
Migration should preserve the effective user-facing name. If a legacy thread has no SQLite name but resolves to one from session_index.jsonl, that name should be retained when the thread becomes paginated. An existing non-null SQLite name should stay authoritative.
Additional information
I traced the transition to these paths:
resolve_thread_namesreadssession_index.jsonlonly for legacy thread IDs.mark_thread_paginatedupdates onlyhistory_mode.finish_published_migrationperforms that promotion without preserving the legacy fallback name.
The smallest fix looks like resolving the effective legacy name before promotion and storing it only when the SQLite name is null, ideally as part of the same state transition. A regression test could migrate an index-only synthetic name and check that thread/read, thread/list, and name search return the same value before and after migration.
I wrote that regression test locally. It fails on current main because the post-migration name is None, then passes with the fallback stored during the SQLite promotion. The full codex-state (171 tests) and codex-thread-store (216 tests) suites pass with the focused change.
While tracing this migration, I found a second issue with persisted subagent history and reported it in #38762. I kept it separate because it affects the history boundary rather than name preservation.
If this matches the intended behavior, I'm happy to send the focused fix and regression test if a maintainer invites a PR.
Activity
jdcodes1 commentedon Aug 18, 2026
Verified your four-step mechanism on
main@ 1f41cc5 — both halves check out in code, and there's a one-line-shaped fix that heals already-migrated stores retroactively, not just future migrations.The gate. The session-index name fallback is explicitly conditioned on legacy mode —
read_thread.rs:codex/codex-rs/thread-store/src/local/read_thread.rs
Lines 268 to 274 in 1f41cc5
(
if thread.history_mode == ThreadHistoryMode::Legacy && … find_thread_name_by_id(…)), with the list-path equivalent inhelpers.rs#L262-L268consulting the index only forlegacy_thread_ids. Meanwhile the migration (thread-store/src/local/rollout_migration.rs) flipshistory_modewithout any name handling — there is nofind_thread_name_by_id/threads.namebackfill anywhere in that file. So the name source is switched off exactly when nothing has copied its value forward — your steps 3-4, precisely.The good news you already spotted: nothing is lost. The
session_index.jsonlentry survives migration, so this is a reachability bug, not data loss — which opens a cheaper fix than a forward-only migration change:threads.nameis NULL/preview-derived, regardless ofhistory_mode. One condition change at the two call sites, and every already-migrated thread gets its name (and name-search hits) back on the next read, no re-migration required.migrate-rolloutscopy the effective index name intothreads.namewhen flippinghistory_mode— makes paginated reads self-contained and lets (1) eventually retire.--applypermanently unnamed; doing (1) without (2) keeps a hidden dependency on the legacy index file. Both together, with (1) as the compatibility bridge, is the clean end state.The search regression follows automatically — name search reads the same effective-title path, so either fix restores find-by-old-name too. Test shape is your synthetic-home repro verbatim: legacy thread named only in
session_index.jsonl→migrate-rollouts --apply→ assert read/list/search still surface the name.