[Windows][CLI 0.153.4] Paginated thread reads return only earliest turn despite newer persisted rollout responses

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

Observed on 2026-09-14:

• Windows MSIX package: OpenAI.Codex 26.903.9818.0
• Installed Electron package version: 26.903.71938
• CLI / session writer: 0.153.4
  These were obtained from package/runtime metadata; the About dialog was not independently captured.

What subscription do you have?

Not collected for this diagnostic.

What platform is your computer?

Windows native execution. App Server userAgent reported Windows 10.0.26100; x86_64.

What issue are you seeing?

A local thread receives new requests and persists complete responses, but its structured history-reading interfaces return only the earliest turn. This prevents a remote Mac task from retrieving the Windows task's response.

The same failure reproduces locally through a fresh, read-only stdio App Server process, without depending on the remote connection:

• The affected thread has historyMode: "paginated".
• The actual rollout contains a new request at 2026-09-14T14:49:50.875Z, followed by an actual tool output and final assistant response at 14:55:38.079Z. Both response records contain the complete 14,687-character payload. This was verified against the saved payload, rather than inferred from file timestamps or tool-call arguments.
• codex_app.read_thread with turnLimit: 3, includeOutputs: true, maxOutputCharsPerItem: 20000 returns one early turn with 14 items, hasMore: false, and nextCursor: null.
• thread.updatedAt advances, while the returned conversation body remains stale.
• An independently started stdio App Server's thread/read resolves to the same growing rollout file (over 11 MB at the time).
• In that process, thread/turns/list with both default ordering and explicit sortDirection: "desc" returns the same earliest turn, 14 items, and nextCursor: null.
• thread/read(includeTurns: true) also returns just that early turn and omits the later response.
• The early turn was reported as inProgress by the app tool and interrupted by the independent process, with no completedAt in the retained summaries. We have not established whether that state is causal.

What steps can reproduce the bug?

The initiating trigger is not yet known. The following reproduces the read inconsistency on the affected saved thread:

1. Verify that a recent request and matching actual response exist in the local rollout, using a unique marker.
2. Read that exact thread through the app's read_thread tool with outputs included.
3. Start the same installed CLI as app-server --stdio, initialize it, and issue these read-only requests (replace <affected-thread-id> with the real local ID):
   • thread/read: {"threadId":"<affected-thread-id>"}
   • thread/turns/list: {"threadId":"<affected-thread-id>","limit":3,"itemsView":"full"}
   • Repeat the previous request with "sortDirection":"desc".
   • thread/read: {"threadId":"<affected-thread-id>","includeTurns":true}
4. Compare returned turn IDs/items with the marker's actual persisted response.
5. Observe that only the earliest turn is returned and the turn-list response provides no next cursor.
6. Exit the diagnostic process.

No thread resume/start calls, database/history edits, or network listener were used in this diagnostic.

What is the expected behavior?

Structured history reads should expose the latest persisted responses, or provide valid pagination that reaches them. An updated timestamp or completed-task signal must not mask unavailable response content.

If reconstruction cannot proceed, return an actionable error and a supported recovery path rather than silently presenting an incomplete history as the final page.

Additional information

• CLI binary SHA256: 3d6ca7085c932b62ef4ee4877e92f15b050fb94b2eb8e6c10a346a06248c6004.
• A separate Windows-local fs/readFile test could read current files, including a file updated within the same process. That does not establish a remote file-reading workaround: the remote task's exposed tools did not offer a host-selectable file-read method.
• There were also intermittent remote thread-discovery/connection errors. Their cause is unknown; they do not explain why the independent local history reads are stale.
• The exact backend function, index condition, or parsing failure is not established. No projection ordinal mismatch has been verified in this case.
• Potentially related: #42197, #43124 (projection stalls with verified ordinal mismatches), #41591 (orphaned historical turn), and #40014 (completed turn with empty items). This report adds native Windows CLI 0.153.4 reproduction through a fresh stdio App Server, with only the earliest turn returned and no turn-list continuation cursor; shared causation is unconfirmed.
• Please investigate paginated history reconstruction and cursor generation, and provide a supported recovery procedure or fixed version.
• This report contains sanitized technical summaries only. Private thread IDs, local user/company paths, conversation contents, raw logs, and business source files are omitted.

Start with the paginated history paths behind thread/read and thread/turns/list, using the affected saved thread and a fresh app-server --stdio process to reproduce the missing later response. Compare the persisted rollout with default and descending turn-list results, including cursor generation; done means current responses are returned or pagination reaches them, with an actionable error when reconstruction cannot proceed.