Codex App upgrade can break opening older local threads when rollout session_meta lacks thread_source

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #22984

Powered by Codex Action

I have an additional data point from a local mitigation that consistently restored the broken pre-upgrade threads on my machine.

This was done with a sanitized local compatibility repair, not by recreating threads and not by recovering from backups.

Observed repair rule:

1. Read ~/.codex/session_index.jsonl to identify user-visible local thread IDs.
2. Scan ~/.codex/sessions/**/rollout-*.jsonl.
3. For each rollout:

• parse the first JSONL line
• if it is type == "session_meta"
• and payload.id is present in session_index.jsonl
• and payload.thread_source is missing or empty
• then backfill payload.thread_source = "user"

1. Restart Codex App.

Important safety constraint:

• do not blindly infer thread_source for every rollout on disk
• only repair indexed / user-visible top-level threads
• do not overwrite existing thread_source values such as subagent threads

Minimal sanitized Python version of the local repair logic:

import json
from pathlib import Path

codex_home = Path.home() / ".codex"
session_index = codex_home / "session_index.jsonl"
sessions_root = codex_home / "sessions"

indexed_ids = set()
for line in session_index.read_text(encoding="utf-8").splitlines():
    if not line.strip():
        continue
    try:
        indexed_ids.add(json.loads(line)["id"])
    except Exception:
        pass

for rollout in sessions_root.rglob("rollout-*.jsonl"):
    lines = rollout.read_text(encoding="utf-8").splitlines()
    if not lines:
        continue

    try:
        first = json.loads(lines[0])
    except Exception:
        continue

    payload = first.get("payload") or {}
    thread_id = payload.get("id")
    if thread_id not in indexed_ids:
        continue
    if payload.get("thread_source"):
        continue

    payload["thread_source"] = "user"
    lines[0] = json.dumps(first, ensure_ascii=False, separators=(",", ":"))
    rollout.write_text("\\n".join(lines) + "\\n", encoding="utf-8")

This local repair fully restored the old broken threads for me.

Additional verification from the repaired dataset:

• all indexed / user-visible rollout files became compatible
• newly created post-upgrade threads were already fine and were left unchanged
• non-indexed rollouts were intentionally not inferred / rewritten

I also wrote local tests for this repair rule before applying it, covering:

• indexed rollout with missing thread_source gets repaired
• rollout not present in session_index.jsonl is not modified
• rollout with an existing thread_source is preserved

This is obviously only a mitigation, not the correct product fix. But it strongly suggests the app should either:

• treat missing thread_source on older local rollout metadata as a backward-compatible user default when appropriate, or
• run a built-in one-time metadata migration for historical local rollouts.

Additional Windows data point from another machine after upgrading Codex Desktop.

Observed behavior:

• After upgrading Codex Desktop, clicking older local sidebar threads shows the generic error UI: Oops, something went wrong
• Check for updates and Retry do not recover the thread.
• Re-authorizing the Codex / ChatGPT login state also does not recover the thread.
• Newly opened/current threads still work.

Environment:

• Windows Codex App package: OpenAI.Codex 26.513.3673.0
• Current desktop/app telemetry version observed in logs: 0.131.0-alpha.9
• Affected historical thread was created with cli_version: 0.130.0-alpha.5
• Current bundled nested CLI under AppData\Local\OpenAI\Codex\bin\76ac88818493fc45\codex.exe reports codex-cli 0.131.0-alpha.9
• Top-level AppData\Local\OpenAI\Codex\bin\codex.exe still reports codex-cli 0.130.0-alpha.5, so the machine also has mixed old/new CLI binaries after update.

Affected local thread example:

• Thread id: 019e2bfc-163c-7750-9829-460a1d9135d4
• Local rollout file exists under ~/.codex/sessions/2026/05/15/
• File size: 8031308 bytes
• JSONL validation: 3874 lines, 0 invalid JSON lines
• First JSONL line:
• type=session_meta
• payload.id=019e2bfc-163c-7750-9829-460a1d9135d4
• payload.cli_version=0.130.0-alpha.5
• payload.source=vscode
• payload.thread_source is missing

This independently matches the suspected compatibility issue described here:

• the historical rollout file is still present
• the rollout file is valid JSONL
• the thread was created by 0.130.0-alpha.5
• the desktop app after update is 0.131.0-alpha.9
• thread_source is missing from session_meta.payload
• the desktop UI fails to open the old thread with the generic error page

I am not attaching raw session files because they contain user/workspace content. This comment only includes sanitized metadata and validation results.

We've issued a hotfix to address this. Please update to the latest version.

When older local sessions fail to open after app updates because session_meta records lack newly expected schema fields (such as thread_source), Codex Rescue can diagnose the schema drift across your historical rollouts without modifying them in place.

You can inspect persisted schema generations and coverage across your local sessions using:

npx --yes codex-rescue schema

Or run doctor on the latest session:

npx --yes codex-rescue doctor --latest

It runs completely locally and read-only. If you run it, sharing whether it flags the schema gap on your older sessions would provide useful field signal.