Daily Edition Sources +2

Codex Makes Thread History a Rebuildable View

Two fresh commits separate a coding agent’s durable JSONL record from its fast SQLite history view—and teach that view how to catch up after it falls behind.

A torn-paper marker diagram showing a JSONL durable record feeding a rebuildable SQLite history view through a byte checkpoint, with a clipped final line left for later.
Diagram Punkthe durable record stays put while the reading view catches up.
repo openai/codex evidence
2 source signals 1 repo 2 linked commits
Evidence: 2 linked commits / July 14, 2026 / Daily Edition
Open Edition Evidence below

On July 14, openai/codex added a paginated thread-history commit that keeps JSONL rollout records as the durable source of truth while projecting turns, items, and reading progress into SQLite. That is a consequential boundary for a long coding-agent session: the record of who asked for what, which tools ran, what failed, and where work stopped can be quick to page through without the screen becoming more authoritative than the record it displays.

The Codex commit also serializes per-thread writes, shutdown, and deletion, so that the history view is not updated in a race with the record it follows. Local cursor reads can then use the SQLite view for summaries and items while the JSONL rollout remains the source that can rebuild it.

A faster reader is allowed to be behind

The revealing detail arrived in the next checkpoint-recovery commit. If a durable JSONL append succeeds but its SQLite projection fails, the next projection reads from the byte offset it previously stored instead of assuming the index is current. It consumes only complete newline-terminated records; a trailing partial line waits for a later pass. The corresponding tests simulate the failed projection, confirm that the later write catches up the missing suffix, and ensure a synchronized view does not replay old rows.

That is a modest but useful contract for anyone building an agent runtime or embedding one in another product: keep a canonical append-only record, make convenient views explicitly disposable, and give them a checkpoint that can recover from a lag without inventing history. A fast index may be stale for a moment. It should never outrun the record.

What the commits do—and do not—settle

The public source shows an implementation for Codex’s paginated-history path, including local reads, cleanup on deletion, and recovery-oriented tests. It does not establish a public release promise, large-session performance, broad availability, or how often a real user will encounter projection lag. Nor do the commits reveal why this storage boundary was chosen. The next signal is practical: whether the project exposes this history path to more clients without blurring the line between a recoverable index and a durable session record.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateJuly 14, 2026
LaneDaily Edition
Confidence68%
Sources2
Reposopenai/codex

Primary Evidence

Evidence Limits

  • These commits prove an implementation and its repository tests, not a public release date, broad availability, real-world performance, or successful recovery in every environment.
  • The source describes the storage boundary; it does not establish a private rationale, customer demand, or the future product surface around thread history.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.