codex - 💡(How to fix) Fix Codex App upgrade can break opening older local threads when rollout session_meta lacks thread_source

What version of the Codex App are you using (From “About Codex” dialog)?

Upgraded from 0.130.0-alpha.5 to 0.131.0-alpha.9.

What subscription do you have?

ChatGPT Plus / Codex-enabled individual subscription.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After upgrading the Codex App, newly created threads open normally, but many pre-upgrade local threads fail to open in the desktop app and render the generic error UI:

Oops, something went wrong

This affected old local threads only. The underlying local rollout files were still present and valid JSONL, and new post-upgrade threads were healthy.

I investigated the local session files and found a consistent metadata mismatch:

• working new threads created after upgrade had session_meta.payload.thread_source
• broken old threads created before upgrade often did not have session_meta.payload.thread_source
• those old rollout files were otherwise valid and readable

On my machine, locally backfilling thread_source: "user" into the indexed old rollout files under ~/.codex/sessions/**/rollout-*.jsonl restored the broken threads.

So this looks like a desktop compatibility / migration regression for older local rollout metadata, not a data loss issue.

PII note:

• I am not attaching raw local session payloads
• thread IDs below are real local examples but contain no user content
• absolute local paths are omitted except for the standard ~/.codex storage layout

What steps can reproduce the bug?

1. Use Codex App on Windows with local session history already present from an older app version.
2. Have at least one older local thread created by 0.130.0-alpha.5 where the first JSONL line (type=session_meta) lacks payload.thread_source.
3. Upgrade Codex App to 0.131.0-alpha.9.
4. Open a new thread after upgrade: it works.
5. Open one of the older local threads: the app shows the generic error UI instead of loading the thread.

Representative local thread IDs I used while debugging:

• works after upgrade: 019e2ffa-66a8-7073-8b8f-a24fe3b96c86
• broken before local repair:
  • 019e2b25-4ce4-7073-a2bb-974d8c56021e
  • 019e2ad4-4455-70e1-8633-76bd7c64fc6b
  • 019e24a9-999c-73d3-9fff-92b360ae3e7b
  • 019e201a-f2c1-7093-aad2-82de2d35d842

Observed local evidence:

• session_index.jsonl still listed the threads
• rollout files still existed under ~/.codex/sessions/YYYY/MM/DD/
• rollout files were valid JSONL
• the key structural difference was missing session_meta.payload.thread_source on many older user threads

Local mitigation that fixed the issue:

1. scan indexed rollout files
2. for each visible top-level thread with missing thread_source
3. backfill thread_source: "user" into the session_meta payload
4. restart Codex App

After that, the previously broken old threads opened again.

What is the expected behavior?

Upgrading the Codex App should not break opening older local threads.

If older rollout metadata is missing a now-required field like thread_source, the app should either:

• tolerate the missing field and infer a safe default for old local top-level threads, or
• run a local migration/backfill when reading old rollout files

The app should never show a generic unrecoverable error UI for otherwise valid historical local threads solely because a new metadata field was introduced.

Additional information

Additional debugging details:

• This looked specific to pre-upgrade local threads, not newly created threads.
• A full local scan on my machine showed the indexed / visible threads became healthy once thread_source was backfilled.
• I suspect the right long-term fix is in the desktop / app-server compatibility path that reads old rollout session_meta, rather than asking users to mutate local history files manually.

Useful places to inspect in the repo:

• desktop / app conversation loading path
• app-server conversation summary / thread summary loading from rollout files
• any session metadata migration / compatibility layer

I also noticed the repo already has app-server test fixtures that explicitly create rollouts with thread_source: None, which may be a good starting point for a regression test.