[Bug] Paginated thread history projection stops at a token_count record

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

Bundled runtime: codex-cli 0.145.0 (desktop build not included), 0.149.0 same

What subscription do you have?

Not disclosed for privacy

What platform is your computer?

Linux x86_64 (host and kernel identifiers omitted)

What issue are you seeing?

Several completed local chats display only the initial user message and the assistant's first progress update. Later tool activity, turns, and final answers are missing from the conversation pane even though the durable rollout still contains the complete transcript.

The failure occurs while materializing paginated thread history. The projection stops at an early token_count record and does not process later rollout records.

Sanitized errors:

invalid type: map, expected f64
thread history projection expected ordinal 17, got 18
failed to project durable rollout during shutdown

What steps can reproduce the bug?

Use Codex App with the bundled codex-cli 0.145.0 runtime and paginated thread history.
Run a local task that emits a token_count event containing structured rate-limit data.
Allow the task to continue through later turns and produce a final answer.
Close and reopen the chat.
Observe that the conversation pane contains only the messages before the rejected token_count event.

In the observed cases, restarting the app retries projection but does not repair the incomplete history.

What is the expected behavior?

The complete conversation, including later turns and final answers, should be reconstructed from the durable rollout and displayed after reopening the chat.

Additional information

History mode: paginated.
The projection cursor remains at ordinal 17. The next record is skipped, producing the subsequent ordinal-gap error.
The durable session data remains present; this appears to be a history-index/projection failure rather than transcript deletion.
The same failure pattern was observed in multiple local chats.

Privacy: No transcript, prompt, screenshot, filesystem path, account identifier, task/thread/session ID, repository name, hostname, raw log, token usage value, or private project information is attached or included.

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

[Desktop] Completed thread shows stale pre-crash state after restart while rollout & state DB stay intact — thread_history projection is never rebuilt #40112
[macOS Desktop] Reboot can switch app-server runtime and wedge paginated history at a duplicate ordinal #40178

Powered by Codex Action

Additional reproduction evidence from the same failure family:

Codex Desktop build: 26.818.61809
Codex CLI/app-server: 0.149.1
Reproduces across Linux Desktop, laptop Remote, and mobile Remote.
Affected long tasks show only the initial user message / early progress, or omit middle and later completed turns.
The durable rollout JSONL still contains the omitted user messages, assistant messages, tool activity, and completed turns.
Restarting the Desktop host and remote-control app-server does not restore the visible transcript.
Archiving was not involved.

A local diagnostic mitigation forced unknown-conversation recovery to call full paginated hydration (hydrateBackgroundThreads([threadId], { includeTurns: true })) before replaying deferred live notifications. The patched bundle was installed, its marker verified, and the app-server restarted. Mobile still displayed the truncated transcript.

This narrows the remaining failure below a renderer-only unknown-conversation recovery path: likely the remote thread/read history projection/index or the data returned to Remote clients. In affected tasks, a read can report hasMore: false while returning only the first visible turn even though the durable rollout has many later completed turns.

This also overlaps the visible symptom in #39011 (completed messages disappearing after steered follow-ups), though the durable projection failure here persists across reconnect/restart and devices.

Confirmed local recovery and narrowed the invariant failure further.

For two affected tasks, thread_history_projection_state showed:

next_rollout_ordinal = 18
next_rollout_byte_offset exactly equaled the end byte offset of rollout ordinal 18
the next durable line was ordinal 19

So the projector had consumed ordinal 18's bytes without advancing its ordinal checkpoint. Every subsequent append then failed with expected ordinal 18, got 19; 0 rejected rollout lines cannot cover that gap.

Transactionally advancing only next_rollout_ordinal by one, with the database backed up and rollout JSONL untouched, immediately restored an inactive task: its projection advanced from one visible turn/four items to the complete history.

The active task exposed a second restart-related invariant failure: duplicate ordinals were written around service restarts, initially token_count plus thread_settings_applied sharing ordinals 149 and 743. After backing up the rollout and removing only the duplicate token_count records, projection advanced to ordinal 1053 and restored 25 turns/339 items. A later restart produced another duplicate ordinal 1052. Advancing only the byte checkpoint past the already-accounted duplicate, while retaining next_rollout_ordinal = 1053, resumed projection normally; it advanced to ordinal 1087 with 26 turns/350 items.

This confirms two related correctness issues:

byte and ordinal checkpoints can diverge after a rejected or metadata-only rollout record;
resuming an active thread after app-server restart can reuse the previous ordinal.

Suggested regression coverage:

checkpoint byte/ordinal consistency after an undecodable token_count line;
successful projection of later valid records;
ordinal monotonicity across active-thread restart/resume;
safe handling of an already-accounted duplicate ordinal at the checkpoint boundary.

All repairs were performed against backed-up local state. No transcript content was deleted or reconstructed.

need fix

Independent sanitized confirmation from another Codex Desktop environment.

Environment

Runtime version persisted in local thread state: 0.146.0-alpha.3.1
Affected user-created threads use history_mode=paginated
No explicit paginated-history override was found in user or workspace configuration

Observed behavior

For a completed affected thread:

the Desktop/thread reader returns only one interrupted turn and reports no additional page;
the canonical rollout JSONL parses successfully and contains later user messages, assistant final messages, and a final task_complete;
the derived history store contains only one inProgress turn and four projected items;
the projection byte checkpoint lands exactly after a token_count record with ordinal N, while next_rollout_ordinal remains N;
the next durable rollout record is ordinal N+1, leaving later valid records unprojected;
approximately 110 KB of valid rollout data remained beyond the stored projection checkpoint.

The recurring sanitized log signatures are:

invalid type: map, expected f64
thread history projection expected ordinal 17, got 18
failed to project durable rollout during shutdown

Restart and shutdown retries did not reconcile the projection.

Aggregate scope

A read-only scan of the 14 most recent user-created paginated threads in this environment found the same boundary in 14 of 14 cases:

every projection checkpoint ended immediately after a token_count record;
every stored projection contained a single inProgress turn;
the next durable record was ordinal N+1;
multiple canonical rollouts already ended with task_complete.

This confirms a repeatable projection/index failure rather than transcript deletion or renderer-only state.

A supported repair or automatic re-projection path for already-wedged threads would be valuable, in addition to preventing the byte and ordinal checkpoints from diverging.

Privacy note: this report intentionally excludes prompts, transcript text, screenshots, task or thread identifiers, project and filesystem names, host information, account details, credentials, raw logs, and database files.

I can confirm that I am experiencing the same issue in Codex Desktop
connected to a remote Ubuntu 24.04 host running codex-cli 0.145.0.

Additional evidence from read-only diagnostics on this host:

1,419 legacy-history threads
24 paginated-history threads
24/24 paginated-history threads have incomplete projections
Raw history: 121 started turns, 110 completed turns
Projected history: 24 turns, 0 completed turns
19,987 occurrences of invalid type: map, expected f64
SQLite integrity checks pass
The affected rollout files remain present and valid

This suggests that the issue affects paginated history materialization,
rather than being caused by transcript deletion or SQLite corruption.

Seeing this as well, pretty significant user experience issue

Independent reproduction on 2026-08-26 that closely matches this issue and extends it to ChatGPT iOS Remote:

Originator: codex_chatgpt_ios_remote
Host: Linux x86_64 / Ubuntu 24.04
Runtime: codex-cli 0.145.0
Subscription: ChatGPT Plus
The iOS live view showed the complete assistant final response.
After reopening the thread, iOS showed only the initial user message and the assistant's first commentary/progress update.
The durable rollout contains a response_item assistant message with phase final_answer, immediately followed by task_complete.
A fresh read_thread reconstruction reports that same turn as inProgress and stops after the commentary item; it omits the later final answer and completion.
The first token_count record occurs at the cutoff boundary and contains structured rate_limits data (including primary, secondary, and credits objects), matching the projection-failure pattern described here.
The symptom reproduced across a mobile reload/network change (LTE to Wi-Fi); restarting/reopening did not restore the projected history.

This is therefore not model-output loss: the completed response remains in the host rollout, while the reconstructed/mobile history is truncated before the token-count boundary.

The private thread ID, screenshots, and exact transcript timestamps are available through OpenAI Support if maintainers need them.

I can independently reproduce what appears to be the same paginated thread-history projection bug on two separate new threads.

2 independent new paginated threads affected

Thread 1:
next_rollout_ordinal = 15
next_rollout_byte_offset = 119292
record at byte offset = ordinal 16

Thread 2:
next_rollout_ordinal = 14
next_rollout_byte_offset = 125677
record at byte offset = ordinal 15

raw rollout = intact
state metadata = intact
SQLite integrity_check = ok
projection = permanently stalled
Codex CLI/app-server = 0.146.0

Both affected threads remain present in the raw rollout/state metadata, but disappear or become incomplete in the Codex App history UI after reload.

No database repair, reindex, cleanup, or manual modification has been performed.

I can provide additional timestamps or metadata if useful.

Additional Windows ChatGPT Work reproduction, cross-referenced as #40907:

Surface: current ChatGPT/Codex Desktop app on Windows.
A long-running Work thread had multiple later user/assistant turns beyond an older tool-activity checkpoint.
After leaving and reopening the thread, the visible transcript repeatedly ends at the same older checkpoint; the later turns are no longer reachable by scrolling.
The cutoff also retains a stale Thinking state, consistent with a completion/later-turn record not being projected.
Reopening reproduces the identical cutoff rather than intermittently restoring the tail.

The user has not modified local rollout files or SQLite state. Exact runtime/build and private thread diagnostics are not yet available.

Based on the symptoms and the evidence already collected in this issue, the leading hypothesis is the same byte-offset / ordinal checkpoint divergence at a structured token_count record: the durable rollout may contain the later turns while the paginated projection remains permanently stalled.

Please correlate #40907 with this issue and check the affected Windows Work thread for history_mode=paginated, records after the visible cutoff, thread_history_projection_state consistency, and the known invalid type: map, expected f64 / ordinal-gap signatures. A privacy-scrubbed screenshot is available.

I can reproduce the same class of paginated-history failure on Windows Codex Desktop.

Environment:

Windows 11 x64
Codex Desktop: 26.820.7780.0
Current standalone Codex CLI: 0.150.0-alpha.8
Affected thread metadata reports codex-cli 0.149.0-alpha.4.1 and 0.149.0-alpha.4.3
History mode: paginated

I have two affected local threads. I am omitting thread IDs, paths, and transcript contents for privacy.

Case A:

The active, unarchived thread still exists in state_5.sqlite.
Its rollout segment is newline-valid with 0 malformed JSONL records and continues through ordinal 5104.
The thread-history projection contains only 589 items through ordinal 1658.
The projection cursor is next_rollout_ordinal=1662.
Later records include contact-form testing, email subject customization, sender display, and Reply-To behavior, but they are absent from the Desktop history view.

Case B:

The rollout is newline-valid with 0 malformed JSONL records and continues through ordinal 7729.
The thread-history projection contains only 194 items through ordinal 481.
The projection cursor is next_rollout_ordinal=484.
The visible freeze point is a completed tool-read item at ordinal 480.
Ordinal 483 appears twice in the rollout, followed by many later turns and final progress messages about gameplay UI and visual-effect integration.

Both state_5.sqlite and thread_history_1.sqlite pass SQLite quick_check. The rollout files and authoritative thread rows are still present; this appears to be a stale or wedged thread-history projection rather than transcript deletion.

Expected behavior:

Desktop should reconcile or rebuild the paginated projection from the durable rollout.
Existing threads created by older runtimes should be repaired automatically after upgrading.
Users should have a supported per-thread history repair command.

I have not modified the databases. Could you confirm whether these cases belong to the same projection bug tracked here, and whether there is a supported repair path for already-wedged projections?

I can confirm this issue on a remote Linux app-server used from Codex Desktop on macOS over SSH, with a larger blast radius and a successful recovery path.

Environment

Client: Codex Desktop on macOS
Remote host: Linux x86_64 over SSH
Runtime that created/served the broken projections: codex-cli 0.145.0
Upgraded runtime: codex-cli 0.150.1
History mode: paginated

Symptoms

Affected threads reopened with only the first user message and the first assistant progress message.
The thread reader returned exactly one turn and reported no additional page.
Selecting text and opening a side chat also failed on these remote paginated threads with:
Forking is not available for threads using paginated history yet.
Canonical rollout JSONL files remained present, newline-valid, and contained all later turns and final answers.

Projection evidence

This was not isolated to one thread:

17/17 paginated-history threads on the remote host had incomplete projections.
The canonical rollouts contained about 110 turns in aggregate.
thread_history_1.sqlite contained only 17 turns total: exactly one projected turn per affected thread.
Every projection cursor stopped very early (around rollout ordinal 14-18).
One representative rollout was about 18 MiB / 1,199 valid JSONL records / 10 turns, while the projection contained only 1 turn and 3 items and stopped at roughly 0.9% of the file.
Repeated server errors included:
- invalid type: map, expected f64
- followed by thread history projection expected ordinal N, got N+1

This matches the token-count/schema failure described in the issue: after rejecting the structured value, the cursor never advanced, and all subsequent records became unreachable through paginated history.

Version-skew detail

Upgrading the npm CLI alone did not replace the running server. Immediately after the upgrade:

{
  "status": "running",
  "cliVersion": "0.150.1",
  "appServerVersion": "0.145.0",
  "managedCodexVersion": null
}

The old 0.145.0 app-server was an unmanaged persistent process holding the control socket. codex app-server daemon restart correctly refused with:

app server is running but is not managed by codex app-server daemon

After terminating the old unmanaged instance and bootstrapping the managed daemon, both versions reported 0.150.1.

Recovery that restored all affected threads

Backed up the canonical rollout JSONLs and the SQLite projection.
Stopped the managed app-server daemon.
Moved thread_history_1.sqlite plus its WAL/SHM files aside (no rollout data was removed).
Started the managed 0.150.1 daemon.
Reopened each affected thread once. Projection rebuild is lazy: the new database did not exist immediately after daemon start, and each thread was rebuilt when first loaded.
All 17 affected threads recovered their complete visible histories. Side-chat creation also worked after the runtime upgrade.

Suggested product improvements

Make the projection parser backward/forward compatible with structured token-count/rate-limit/duration values.
Treat thread_history_*.sqlite explicitly as a rebuildable derived index and automatically retry/rebuild when the cursor is far behind a valid canonical rollout.
On Desktop/SSH connection, detect cliVersion != appServerVersion and clearly warn or safely replace an unmanaged incompatible server.
Provide a supported history doctor/rebuild command that scans all affected paginated threads, rather than requiring a manual database move and lazy reopening of every thread.
Surface the real projection/fork error in the UI instead of a generic “failed to open side chat” message.

No private prompts, hostnames, repository names, absolute paths, credentials, or thread IDs are included here.

Additional Windows reproduction with a clearer interruption/power-off trigger (2026-08-28).

Environment

Windows x64: Microsoft Windows NT 10.0.19045.0
Current local Codex runtime reports codex-cli 0.150.0-alpha.8
Desktop build number was not available from the read-only command-line diagnostic

Trigger pattern

This has now occurred in two separate long local chats:

A turn is running a local command/tool.
The user interrupts the running command/turn.
The computer is shut down before the chat visibly reaches a settled terminal state.
After reboot, Codex Desktop reopens the chat.
The conversation pane restores an old assistant progress message from much earlier in the task and presents that stale point as the visible/current task state.
Later completed turns remain missing from the pane after restarting the app.

In the latest occurrence, the stale message said that a proof-of-concept was only about to begin, while the repository's durable Git state already contained the later completed and validated implementation. This confirms that the project data was not rolled back; the Desktop history/task projection was stale.

Expected behavior

After an interrupted turn followed by an unclean host shutdown, startup recovery should:

reconcile the in-flight turn to an explicit interrupted/failed terminal state;
rebuild the visible history from the durable rollout;
preserve all later completed turns;
never surface an old intermediate progress message as the current source of truth.

This looks consistent with the projection/restart invariant failures already documented in this issue, but adds a repeatable user-level trigger: interrupt an active command, then shut down before the turn fully settles.

No session IDs, project names, paths, transcript text, screenshots, credentials, rollout files, or database contents are included. Local rollout/database state was not modified.

Confirming the same failure mode on macOS with Codex Desktop 26.820.60940 (build 7119).

After restart/reopen, an existing local thread renders blank. Read-only inspection shows no raw history loss:

canonical rollout JSONL: 36,211,173 bytes, 2,708 newline-valid records
independent extraction: 56 visible messages, 308 tool calls, and 308 tool outputs
thread_history_projection_state is stalled at next_rollout_ordinal=1046 / next_rollout_byte_offset=13389464
the exact source record at that boundary is event_msg/token_count
1,662 valid JSONL records remain after that boundary
history DB exposes only 3 projected turns; native thread reader returned one interrupted turn with hasMore:false
desktop logs show thread/read, thread/resume, thread/turns/list, and thread/items/list succeeding; restart did not rebuild the projection

No private thread ID, paths, or conversation content included here. This appears to be the same paginated projection bug, and the UI presents it as total history loss. A supported re-projection/rebuild action would help users recover without touching raw storage.

Independent Remote SSH reproduction with the exact frozen projection boundary (2026-08-29).

Environment

Codex Desktop connected through the built-in Remote SSH path to a Linux x86_64 host
Remote Codex CLI/app-server: 0.145.0
Rollout originator: Codex Desktop
History mode: paginated

User-visible result

The conversation pane shows only the original user prompt and the first assistant commentary message.
The native thread reader returns exactly one turn, marks it interrupted, sets completedAt: null, and reports hasMore: false.
The sidebar/task index has a later update timestamp, while the conversation projection remains at the beginning.
The canonical rollout contains the complete later work, including final assistant answers and task_complete events.

This is the concrete projection failure behind the Remote SSH symptom described in #40515 for this occurrence.

Read-only projection evidence

Canonical rollout: 14,577,410 bytes / 1,865 physical lines
thread_history_1.sqlite passes PRAGMA quick_check
thread_history_projection_state is frozen at:

next_rollout_byte_offset = 84637
next_rollout_ordinal     = 16

Only three items were projected:

ordinal 9   userMessage
ordinal 10  reasoning
ordinal 12  agentMessage

Rollout ordinal 16 is an event_msg/token_count whose rate_limits value is a structured object.
The record at byte offset 84637 is already ordinal 17 (event_msg/item_completed). In other words, the projector advanced the byte cursor past rejected ordinal 16 without advancing next_rollout_ordinal.
The logs repeatedly contain both sides of the failure:

skipping rejected rollout line while projecting ...:
invalid type: map, expected f64 at line 1 column 816

thread history projection ... expected ordinal 16, got 17

Much later in the same canonical rollout, valid final_answer and task_complete records are present. They are unreachable through the Desktop/thread-reader projection.

The rollout also contains one malformed partial tool-output record later in the file, but the projection was already frozen at ordinal 16, well before that record. It is therefore not the trigger for this missing-history symptom.

Expected recovery behavior

Every rollout reader should decode the structured token_count record consistently.
Rejecting a record must not advance the persisted byte cursor while leaving the expected ordinal behind.
An existing stale projection should be automatically rebuilt or reconciled from the canonical rollout.
Desktop should surface a projection/synchronization error instead of presenting a completed task as plausibly interrupted with hasMore: false.
A supported history doctor/rebuild command would provide a safe recovery path for already affected threads.

No prompts, repository names, local paths, hostnames, credentials, raw transcripts, databases, or thread IDs are included. The underlying evidence is retained locally if OpenAI needs it through a private diagnostic channel.

This comment was prepared and posted by OpenAI Codex at the user's request.

Observed a similar history-projection failure in an active Codex Desktop task on Windows with a local WSL workspace.

Previously visible messages disappeared from the task UI. The task itself remained active and accepted new messages; the user explicitly reported that the chat had disappeared and asked the assistant to resend the latest messages. The durable local rollout JSONL for the task still exists, and the assistant retained enough conversation context to reconstruct the missing content.

This looks like a display/history projection loss rather than deletion of the underlying transcript. I cannot confirm that the disappearance happened specifically at a token_count boundary, but the persistence/UI mismatch matches this report.

I've encountered this bug four times in a row. It causes this issue where subsequent chat history isn't displayed when the context of the conversation is compressed; I have to recreate the conversation each time to use it.

Additional occurrence observed on 2026-08-31 UTC in the Codex app:

Completed user and assistant messages that had already rendered disappeared from the conversation pane repeatedly while the same task was still being continued.
The missing content included full final messages and prior discussion, not only intermediate progress/tool output.
This was not context compaction: it was a loss of already-visible transcript content in the UI.
No deliberate close/reopen step was required for the recurrence.
The task remained usable, but earlier architecture decisions became unavailable in the visible transcript.

This appears consistent with a transcript history/projection or rendering-persistence failure rather than intentional context management. No transcript, repository content, task/thread ID, logs, account identifiers, or internal project details are included here for privacy.

Independent Remote SSH reproduction with a disk-full/interrupted-write trigger and a successful per-thread recovery (2026-09-02).

Environment

Client: Codex Desktop for Windows, build 26.831.21537
Remote host: Linux x86_64 through the built-in Remote SSH workflow
Remote Codex CLI/app-server: 0.145.0
History mode: paginated

User-visible result

The remote root filesystem filled while a long task was active; even a .codex/tmp path could not be created. After space was freed and Desktop reconnected, the task reopened with only the first user message, the first assistant progress message, and the first command. The remainder of the conversation was still in the canonical rollout.

Durable-rollout and projection evidence

Original rollout: 9,169,819 bytes / 1,150 physical lines.
A partial duplicate at physical line 553 was invalid JSON, consistent with an interrupted append while the disk was full.
Removing only that incomplete duplicate produced 1,149 valid records with a contiguous ordinal sequence 0..1148.
The repaired rollout still contained 6 task_started and 6 task_complete events, 46 assistant/user message items, 158 custom tool calls, and 158 matching outputs.
Restarting after this JSON repair did not restore the UI history.
thread_history_projection_state remained frozen at next_rollout_byte_offset=102062 and next_rollout_ordinal=17.
The derived history contained one inProgress turn and four projected items.
Rollout ordinal 17 was an event_msg/token_count record whose structured rate_limits value included object-valued primary and credits fields.
Server logs contained both signatures already reported here:

skipping rejected rollout line ... invalid type: map, expected f64
failed to project durable rollout ... expected ordinal 17, got 18

The projection was therefore already stuck near the start of the file, hundreds of records before the later malformed partial append. Repairing the malformed JSON alone could not recover the thread; the token_count schema rejection was an independent blocker.

Recovery that restored the full task

All source and database files were backed up first. The old remote app-server also had to be stopped: it was a persistent unmanaged process, so codex app-server daemon stop reported:

app server is running but is not managed by codex app-server daemon

For this single affected task:

The one incomplete duplicate JSONL line was removed, leaving every valid record and a contiguous ordinal sequence.
In each event_msg/token_count record, only payload.rate_limits was replaced with null; no record or ordinal was removed.
Only that task's rows were cleared from thread_items, thread_turns, and thread_history_projection_state in the derived history database.
The app-server was restarted and the task reopened.

The history projection rebuilt successfully and the full conversation reappeared in Desktop.

This was an unsupported manual recovery performed against backups, not a proposed end-user procedure. A supported history doctor/rebuild operation would be much safer. It would also help if Desktop surfaced both disk-write failures and projection failures instead of presenting the early prefix as the complete task.

No prompts, transcript text, task IDs, repository names, usernames, hostnames, absolute paths, credentials, or raw data are included here. The original and repaired artifacts are retained privately if maintainers need a narrowly scoped diagnostic.

This comment was prepared and posted by OpenAI Codex at the user's request.

I am seeing a related regression on macOS in the ChatGPT desktop app.

Environment:

ChatGPT Desktop: 26.831.21537 (build 7579)
Bundled Codex CLI: 0.152.1
macOS

Observed behavior:

Reopening an affected local Codex task shows history only through the previous day.
The task-history reader returns its newest persisted turns from that cutoff and includes stuck in-progress turns.
App logs from the missing days show later turns being executed for the same local task route, but those turns are absent from the reloadable task history.
The standard local session transcript did not contain a newer durable session file for those later turns.

This is not a sidebar filter or archived-thread issue. Refreshing/reopening the task does not restore the missing days. No transcript content, account information, project path, task ID, or raw logs are included here for privacy.

The symptom appears consistent with an interrupted history persistence/projection path on a newer desktop build. I can provide sanitized diagnostic excerpts privately if useful.

Independent Windows reproduction observed on 2026-09-03.

Environment

Codex Desktop: 26.901.1978.0
Codex CLI/runtime: 0.149.0
Windows 11 x64: 10.0.22621
Long-running local Desktop task using paginated history

User-visible behavior

The conversation pane shows a long blank gap where recent user and assistant turns should appear, while older content before the gap remains visible.
Revisiting the task does not rehydrate the missing turns.
The task remains active and can continue accepting work, which makes the blank region look like a possible model-context loss.

Read-only evidence

The native task reader returns the newest completed turn and the current in-progress turn, but both have empty item arrays.
The same reader still reports the task as active.
The canonical rollout JSONL contains the omitted user messages, assistant progress messages, the completed final answer/task-complete event, and later progress for the active turn.
A short follow-up equivalent to “continue with that design” was interpreted correctly and execution followed the immediately preceding hidden design, so the model continuation retained the required context at least functionally. The failure appears to be in history projection/display rather than raw transcript deletion.
The rollout is still appendable and was not modified. No database repair or unsupported recovery was attempted.

Expected behavior

Desktop and the native task reader should reconstruct and display all recent turns from the durable rollout.
If history projection cannot advance, the app should surface a synchronization error instead of rendering an unexplained blank gap.
A supported re-projection/rebuild action would help recover already affected tasks.

Privacy note: no prompt text, screenshot, task/thread identifier, project name, filesystem path, account details, raw logs, database, or token-usage values are included. A screenshot and narrowly scoped diagnostics are retained locally if maintainers need them through a private channel.

This comment was prepared and posted by OpenAI Codex at the user's request.

Confirmed on 0.153.2: persisted checkpoint mismatch survives upgrade/restart; targeted recovery verified

Independent reproduction and recovery on 2026-09-04.

Environment and symptoms

Codex Desktop on macOS, connected to a Linux x86_64 host through built-in Remote SSH.
Affected task metadata: historical cli_version=0.145.0, history_mode=paginated.
Remote agent upgraded to 0.153.2. The actual serving executable was verified as the 0.153.2 binary, not merely the version on the shell PATH.
Updating Desktop, restarting the remote agent through Connections, and fully quitting/reopening Desktop did not restore the history. Exact Desktop build was not captured.
The task displayed only the first prompt, first assistant commentary, and an image-view item. The task reader returned one turn/four items, hasMore=false, and nextCursor=null, although the canonical JSONL contained the later completed work.
The user also observed missing history on iOS before repair; iOS was not independently retested afterward.

Exact inconsistent checkpoint

The affected thread_history_projection_state row in thread_history_1.sqlite contained:

next_rollout_ordinal     = 17
next_rollout_byte_offset = 1608697

Read-only byte-boundary inspection showed:

Ordinal	Starting byte offset	Next byte offset	Record
16	1191383	1607901	custom_tool_call_output
17	1607901	1608697	token_count
18	1608697	1609062	item_completed

The byte position already points to ordinal 18 while the saved ordinal expects 17.

Sanitized log errors:

invalid type: map, expected f64
thread history projection ... expected ordinal 17, got 18;
0 rejected rollout lines cannot cover that gap

The ordinal-gap error continued under the verified 0.153.2 runtime. The transcript was valid JSONL and retained later completed turns. This proves the checkpoint mismatch, not the precise field causing every f64 deserialization error.

Controlled tests on isolated copies

Only this task's metadata/history rows and transcript were copied to temporary Codex homes; credentials and live configuration were not copied. Separate 0.153.2 app-server processes were used, with no model turn submitted.

Unmodified copy, read and resume: one turn/four items, no further page, same expected-17/got-18 failure.
Corrected copy: changed only next_rollout_byte_offset from 1608697 back to 1607901, retaining ordinal 17, then resumed the copied task. All eight turns in that snapshot, 287 indexed items, and seven final replies became available.
Fresh reader of corrected copy, without resume: all eight turns remained readable.
Negative check: deleting index rows in another disposable copy and issuing reads alone returned zero turns; reads did not automatically rebuild the projection. This is not a recommended workaround.

Backed-up live recovery and user confirmation

After user authorization, a consistent SQLite backup and transcript-prefix backup were created and checked. A guarded transaction corrected one checkpoint row's byte offset, after revalidating the task identity and exact boundaries.

The running projector caught up without a remote daemon restart. At verification:

Nine turns were indexed: eight completed turns plus the then-current diagnostic turn.
All eight final-answer texts matched their canonical task_complete records exactly.
A fresh isolated reader of the repaired live-state snapshot returned all nine turns and 321 indexed items.
The backed-up transcript prefix remained byte-for-byte unchanged; normal task activity only appended records.
The existing Desktop view retained stale loaded items. After fully quitting and reopening Desktop, the user confirmed the entire conversation was visible and readable.

No canonical transcript edits, task deletions, global database replacement, or modifications to other task rows were needed.

Safety: These offsets describe one occurrence; they must not be applied to other tasks. Manual SQLite edits are not a general supported recovery procedure. Backups, exact boundary checks, and concurrency safeguards were used here.

Requested product behavior

Please prevent inconsistent byte-offset/ordinal checkpoints and recover checkpoints already left inconsistent by older runtimes. A supported per-task re-projection/recovery action and a visible history-load error would avoid presenting this as permanent conversation loss.

This confirms a recovery failure for an already-affected task on 0.153.2; it does not establish that 0.153.2 created the original inconsistent checkpoint.

Privacy: no prompts, conversation text, screenshots, task IDs, hostnames, project names, absolute paths, raw logs, databases, credentials, or token-usage values are included.

Prepared and posted by Codex at the user's request, using measured diagnostics and the user's post-repair confirmation.

Additional Linux confirmation with a larger local sample. This appears to reproduce the same failure pattern exactly.

Environment:

The affected thread rows and the long-lived app-server runtime report codex-cli 0.146.0.
The npm CLI installed on disk is now 0.153.2, but the active app-server was started before the upgrade and continued running the old executable. /proc/<pid>/exe points to a deleted pre-upgrade binary.
History mode is paginated.

Read-only store-wide results:

431 paginated threads had projection state.
431/431 projections were behind their rollout files.
For all 431 threads, the number of physical JSONL records consumed at next_rollout_byte_offset was exactly next_rollout_ordinal + 1.
For all 431 threads, the record immediately before that byte offset was event_msg/token_count.
Later valid records remained in every rollout; about 1.95 GB of durable rollout data was collectively beyond the stored projection cursors.
PRAGMA quick_check returned ok for both the state and thread-history databases, and the cursor-adjacent JSONL records were valid JSON.

The live logs repeatedly contain both forms of the failure:

skipping rejected rollout line while projecting ...: invalid type: map, expected f64
failed to project durable rollout ...: thread history projection ... expected ordinal 17, got 18

A newly created thread also wedged at ordinal 17 after its first tool activity, so opening a fresh chat did not help while the stale 0.146.0 app-server remained active. The raw rollout continued to grow while the projected UI history remained at the first turn/four items.

The stale server also retries projection on subsequent writes and emits a large warning burst, causing the local logs database to grow rapidly. Low disk space can therefore become an amplifier/consequence even when there is no SQLITE_FULL error or physical database corruption.

This also closely matches the stale-runtime behavior documented in #38792 and the legacy representation incompatibility in #41276. No repair or mutation has been attempted on this store yet. A supported self-healing projection rebuild and a reliable way for an upgraded CLI/app to replace or reject stale app-server runtimes would both help.

Independent sanitized confirmation observed on 2026-09-09.

Environment

Codex CLI/app-server version recorded by the affected thread: 0.145.0
History mode: paginated
Remote client session

Observed behavior

The conversation UI displays only the initial user message, an early assistant progress update/tool summary, and then Conversation interrupted.
The canonical rollout for the same turn contains a completed assistant final_answer, immediately followed by task_complete.
Fully quitting and restarting Codex does not restore the missing final output.
The durable transcript remains present, so this is consistent with a thread-history projection/read failure rather than transcript deletion.

This appears to match the failure already documented in this issue and provides a fresh confirmation that restart alone does not recover an affected thread.

Privacy: this confirmation intentionally excludes prompts and conversation content, screenshots, task/thread/session IDs, project or repository names, filesystem paths, account information, device identifiers, credentials, and raw logs.

Prepared and posted by Codex at the user's request.

Additional native Windows occurrence observed on 2026-09-09, with a reused ordinal at the exact frozen projection checkpoint.

Environment

Installed Windows app package: OpenAI.Codex 26.901.6511.0.
Affected thread's persisted cli_version: 0.153.4 (this is thread metadata, not a separately verified version of the currently serving executable).
Windows 11 Pro, 10.0.26200, x64; local Windows workspace.
Affected thread: unarchived, history_mode=paginated.

Symptoms

The user reports that later messages have disappeared and the conversation has jumped back to an earlier point. Two read-only calls to the app-provided read_thread surface, requesting the newest page with turnLimit=8 and then turnLimit=1, also return an old turn as inProgress with completedAt=null. The thread's metadata update time advances, but the newest returned turn remains the one started at 2026-09-08T16:01:15Z.

The canonical rollout contains the later assistant final messages and their completion records. This is an observed existing-session failure; a minimal synthetic reproduction and the precise initial trigger have not been established.

Exact read-only checkpoint evidence

Only this affected thread was queried. Both SQLite connections used mode=ro and query_only=ON; projection state and projected turns were read in one transaction.

Observation	Value
`next_rollout_byte_offset`	`21534739`
`next_rollout_ordinal`	`2179`
Projected turns	17 total, 16 with completion timestamps
Newest projected turn	start ordinal `1263`, `inProgress`, no completion timestamp
Canonical rollout size at the evidence snapshot	42,062,678 bytes
Later `task_complete` records after the checkpoint	8

The byte boundary aligns exactly with these consecutive durable records:

physical line 2179
  bytes:       [21533918, 21534739)
  ordinal:     2178
  event:       token_count
  timestamp:   2026-09-08T17:24:09.581Z

physical line 2180 (the stored next byte offset)
  bytes:       [21534739, 21536742)
  ordinal:     2178
  event:       thread_settings_applied
  timestamp:   2026-09-08T17:25:00.035Z

In other words, the checkpoint expects ordinal 2179, but the next durable record reuses ordinal 2178. The previous record has already consumed that ordinal. More than 20 MB of later rollout data exists after this boundary. JSON decoding succeeded for every line during the read-only pass.

This appears relevant to the duplicate-ordinal/restart variant discussed earlier in this issue. Unlike the original skipped-ordinal example, this case has a reused ordinal at the next byte offset. The evidence does not establish what caused the ordinal to be reused, whether a restart was responsible, or whether the original invalid type: map, expected f64 error also occurred.

Expected behavior

Later valid messages and completed turns should remain available through the conversation UI and history reader. Please investigate duplicate ordinal handling and a supported recovery path for already-stalled projections that preserves the durable records.

No app restart, database modification, rollout rewrite, or local repair was attempted during this diagnosis. This comment contains only sanitized structural evidence; no conversation text, task/thread IDs, local paths, credentials, screenshots, or raw logs are attached.

[Bug] Paginated thread history projection stops at a token_count record #40342

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Aug 24, 2026

maxstralin commented on Aug 24, 2026

maxstralin commented on Aug 24, 2026

richardwhatever commented on Aug 24, 2026

CharlesZHEN commented on Aug 25, 2026

Environment

Observed behavior

Aggregate scope

Daily0715 commented on Aug 25, 2026

thedch commented on Aug 25, 2026

catlaverdure commented on Aug 26, 2026

gn2554115-png commented on Aug 26, 2026

BananaMeow-del commented on Aug 26, 2026

onovich commented on Aug 26, 2026

WjzZwd commented on Aug 28, 2026

Environment

Symptoms

Projection evidence

Version-skew detail

Recovery that restored all affected threads

Suggested product improvements

JH-builds commented on Aug 28, 2026

Environment

Trigger pattern

Expected behavior

garpunzel commented on Aug 28, 2026

mjaerdevi commented on Aug 29, 2026

Environment

User-visible result

Read-only projection evidence

Expected recovery behavior

SenlerBot commented on Aug 29, 2026

g453607063-blip commented on Aug 30, 2026

Jay2109 commented on Aug 31, 2026

sri299792458 commented on Sep 2, 2026

Environment

User-visible result

Durable-rollout and projection evidence

Recovery that restored the full task

clancy-Li commented on Sep 2, 2026

old-li-tou commented on Sep 3, 2026

Environment

User-visible behavior

Read-only evidence

Expected behavior

bbar commented on Sep 4, 2026

Confirmed on 0.153.2: persisted checkpoint mismatch survives upgrade/restart; targeted recovery verified

Environment and symptoms

Exact inconsistent checkpoint

Controlled tests on isolated copies

Backed-up live recovery and user confirmation

Requested product behavior

yangzhao1230 commented on Sep 4, 2026

pabloruano commented on Sep 9, 2026

Environment

Observed behavior

Barry-886 commented on Sep 9, 2026

Environment

Symptoms

Exact read-only checkpoint evidence

Expected behavior

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development