Codex local history index becomes stale and recent sessions cannot be resumed

Bug Report: Codex local history index becomes stale and recent sessions cannot be resumed

Summary

Codex VSCode/local history sometimes fails to show or resume recent sessions even though the actual session data still exists on disk.

This appears to be an index synchronization bug in Codex's local history management.

Environment

• Product: Codex VSCode integration / local Codex
• CLI version observed in session metadata: 0.125.0-alpha.3
• Platform: Linux
• Source in local thread DB: vscode
• Model configured: gpt-5.5

Impact

Recent Codex conversations can disappear from the visible history/resume list. This causes repeated context loss and additional token usage because the agent cannot reliably load the immediately prior work.

This is especially costly for long-running coding and research sessions where continuity is expected.

Evidence

Recent sessions existed in the local Codex data store:

• ~/.codex/state_5.sqlite
• ~/.codex/sessions/YYYY/MM/DD/rollout-...jsonl

However:

• ~/.codex/session_index.jsonl was stale and only listed sessions up to the previous day.
• The current-day session was missing from the visible/resume history index.
• state_5.sqlite integrity check returned ok.
• logs_2.sqlite integrity check returned ok.

Additionally, an internal approval-review/guardian thread was inserted into the normal threads table:

• source: {"subagent":{"other":"guardian"}}
• model: codex-auto-review
• title: began with The following is the Codex agent history whose request action you are assessing...

This internal review thread appeared alongside user-facing threads and polluted the history table.

Observed State Before Repair

The local threads table contained the recent user-facing thread:

• archived: 0
• source: vscode
• rollout_path: pointed to an existing ~/.codex/sessions/.../rollout-...jsonl

But session_index.jsonl did not include it until manually rebuilt.

Manual Repair Performed

The following local repair was performed:

1. Backed up:

• config.toml
• session_index.jsonl
• state_5.sqlite
• logs_2.sqlite

1. Rebuilt session_index.jsonl from state_5.sqlite.
2. Marked internal guardian / codex-auto-review threads as archived so they do not appear as normal user history.
3. Ran SQLite WAL checkpoints.

After repair, the missing recent session appeared in session_index.jsonl.

Expected Behavior

• Recent user-facing sessions should always appear in the history/resume list if the session exists in state_5.sqlite and the rollout JSONL exists.
• session_index.jsonl should stay synchronized with state_5.sqlite.
• Internal approval-review / guardian / codex-auto-review threads should not be inserted into, or at least not surfaced through, normal user-facing history.
• If session_index.jsonl is stale or corrupt, Codex should rebuild it automatically from state_5.sqlite and/or sessions/**/*.jsonl.

Actual Behavior

• Recent sessions existed on disk but were missing from the history index.
• The visible history could not reliably load the latest work.
• Internal review-agent threads appeared in the same local thread store as normal user sessions.

Requested Fix

Please fix Codex local history handling so that:

1. session_index.jsonl is transactionally updated or automatically regenerated when stale.
2. Recent sessions are discovered from state_5.sqlite / rollout JSONL even if the index is stale.
3. Internal guardian / approval-review threads are excluded from user-facing history.
4. WAL/checkpoint behavior cannot leave the UI with a stale history list after a normal session.

Severity

High for paid users relying on Codex continuity. The issue causes context loss, duplicate work, and avoidable token spend.