Codex Desktop: paginated thread loses visible history after update - recent turns exist but their items are empty

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

0.154.0-alpha.6.2

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

After updating Codex Desktop, one of my long-running conversations appears truncated in the UI.

The conversation now stops at a much earlier message, even though I continued using the same thread for many turns afterward.

I investigated the local Codex state and found that the original rollout still exists and contains data beyond the point currently displayed by Codex Desktop.

More importantly, the app-server still sees the recent turns, but the corresponding persisted thread items appear to be missing from the paginated history.

This looks like a possible issue in the legacy -> paginated history migration/materialization rather than actual loss of the original rollout.

What steps can reproduce the bug?

1. Open a long-running Codex Desktop thread that existed before the recent legacy -> paginated history migration.

2. After updating Codex Desktop, reopen the thread.

3. The conversation is truncated in the Desktop UI and stops at a substantially older message, even though the same thread was used for many additional turns afterward.

Affected thread ID:

019f86f6-cb9c-72c2-93bc-2e7d82ac9846

The affected thread is unusually large:

• Created: 2026-07-22
• Used through: 2026-09-12
• Rollout size: ~2.4 GB
• SQLite tokens_used: ~7.95 billion cumulative tokens
• Current history_mode: paginated

The original rollout still exists and contains data beyond the point where the Desktop UI currently stops.

I performed the following read-only diagnostics.

1. Migration status

Running:

codex migrate-rollouts `
  --thread 019f86f6-cb9c-72c2-93bc-2e7d82ac9846 `
  --json

returns:

{
  "outcomes": [
    {
      "thread_id": "019f86f6-cb9c-72c2-93bc-2e7d82ac9846",
      "rollout_path": "C:\\Users\\Davide\\.codex\\sessions\\2026\\07\\22\\rollout-2026-07-22T01-15-48-019f86f6-cb9c-72c2-93bc-2e7d82ac9846.jsonl",
      "status": "already_paginated",
      "bytes_processed": 0,
      "message": null
    }
  ]
}

The affected rollout is not present in rollout_migration_skipped_rollouts.

Both the SQLite thread metadata and the rollout session_meta report:

history_mode = paginated

The relevant rollout session_meta contains:

session_id    : 019f86f6-cb9c-72c2-93bc-2e7d82ac9846
id            : 019f86f6-cb9c-72c2-93bc-2e7d82ac9846
history_mode  : paginated
source        : vscode
thread_source : user
originator    : Codex Desktop
cli_version   : 0.145.0-alpha.27

The current app-server reports version:

0.154.0-alpha.6.2

2. Direct app-server test: recent turns still exist

I queried the local Codex app-server directly through its stdio JSON-RPC interface.

After initialize / initialized, I sent:

{
  "method": "thread/turns/list",
  "params": {
    "threadId": "019f86f6-cb9c-72c2-93bc-2e7d82ac9846",
    "cursor": null,
    "itemsView": "full",
    "limit": 3,
    "sortDirection": "desc"
  },
  "id": 2
}

The app-server successfully returns recent completed turns, including:

01a09747-b877-7f31-af3e-e4da978a3552
01a09742-cb08-7592-900e-d812485b5924
01a0973b-677c-7aa1-aa57-c7e9eb69fe30

For example, the response contains:

{
  "id": "01a09747-b877-7f31-af3e-e4da978a3552",
  "items": [],
  "itemsView": "full",
  "status": "completed",
  "error": null
}

The response also contains valid pagination cursors, for example:

backwardsCursor rolloutOrdinal: 250076
nextCursor rolloutOrdinal: 249870

Therefore, the paginated thread history still knows about recent turns that are beyond the portion of the conversation currently visible in Codex Desktop.

However, every returned recent turn contains:

"items": []

even when explicitly requesting:

"itemsView": "full"

3. Direct app-server test: persisted items for a recent turn are empty

I then queried one of those recent turns directly using thread/items/list:

{
  "method": "thread/items/list",
  "params": {
    "threadId": "019f86f6-cb9c-72c2-93bc-2e7d82ac9846",
    "turnId": "01a09747-b877-7f31-af3e-e4da978a3552",
    "cursor": null,
    "limit": 100,
    "sortDirection": "asc"
  },
  "id": 2
}

The app-server returns:

{
  "id": 2,
  "result": {
    "data": [],
    "nextCursor": null,
    "backwardsCursor": null
  }
}

Therefore, the paginated history knows that the recent turn exists, but no persisted ThreadItem is returned for that turn.

4. Original rollout still contains later conversation data

The original rollout file still exists:

~/.codex/sessions/2026/07/22/rollout-2026-07-22T01-15-48-019f86f6-cb9c-72c2-93bc-2e7d82ac9846.jsonl

Its size is approximately 2.4 GB.

Searching the rollout directly finds messages/data belonging to portions of the conversation that occur after the point where Codex Desktop currently stops displaying history.

For example, a user message that is currently near the last visible portion of the Desktop history can be found in the rollout around ordinal/line regions that are followed by many additional records.

The rollout continued to be updated through the end of the actual conversation.

5. SQLite / migration state

The affected thread exists normally in state_5.sqlite and reports:

source        = vscode
thread_source = user
originator    = Codex Desktop
history_mode  = paginated
archived      = 0

The local migration state contains:

migration_id = legacy_to_paginated_v1

Most local threads have already been migrated:

history_mode  threads
------------  -------
legacy        3
paginated     124

The affected rollout is NOT listed in:

rollout_migration_skipped_rollouts

Therefore Codex appears to consider this thread successfully migrated.

Observed state

The resulting state appears to be:

Original rollout JSONL
    |
    +-- Later conversation data still present
    |
    v
Paginated thread history
    |
    +-- Recent turns are present
    |     thread/turns/list -> OK
    |
    +-- Recent ThreadItems are unavailable
          thread/turns/list itemsView=full -> items=[]
          thread/items/list -> data=[]
    |
    v
Codex Desktop
    |
    +-- Conversation appears truncated at a substantially older point

This therefore does not currently look like deletion of the original source rollout.

It appears that the paginated history can still identify recent turn boundaries, while the corresponding persisted ThreadItem history is not being returned.

The visible result in Codex Desktop is that a substantial later portion of the conversation appears to have disappeared.

What is the expected behavior?

No response

Additional information

This does not currently appear to be actual deletion of the source conversation.

The original rollout is still present:

~/.codex/sessions/2026/07/22/rollout-2026-07-22T01-15-48-019f86f6-cb9c-72c2-93bc-2e7d82ac9846.jsonl

Its size is approximately 2.4 GB, and searching it directly finds conversation data beyond the point currently displayed by Codex Desktop.

The current state appears to be:

• source rollout: later history still present
• paginated turn history: recent turns present
• paginated item history: recent items unavailable / empty
• Codex Desktop: conversation appears truncated

The affected thread is marked paginated both in state_5.sqlite and in the rollout session_meta.

The local migration state contains:

legacy_to_paginated_v1

Most of my local threads have already been migrated:

• paginated: 124
• legacy: 3

The affected rollout is NOT listed in rollout_migration_skipped_rollouts.

I have deliberately NOT modified:

• the original rollout JSONL
• state_5.sqlite
• history_mode
• migration state

and I have not run a destructive/manual recovery attempt because I want to preserve the source history.

Is there a supported way to force a rebuild/re-materialization of the paginated ThreadItem history for an already-paginated thread?

Currently migrate-rollouts reports:

already_paginated

with:

bytes_processed: 0

so it does not appear to repair this state.

I can provide additional sanitized app-server responses, SQLite metadata, rollout ordinals, or run further read-only diagnostics if useful.

I cannot provide the complete rollout because it is approximately 2.4 GB and contains private project source code and conversation data.

Start with the migrate-rollouts path and the app-server methods thread/turns/list and thread/items/list, using the reported thread ID and read-only diagnostics. Compare the existing rollout records with paginated state and migration metadata. Done means an already-paginated thread returns its persisted recent ThreadItems and Codex Desktop displays the later conversation history.