macOS Desktop: completed turn returns empty items although history DB contains the final answer

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

26.908.40834, build 8881, verified from the installed app's Info.plist. Bundled Codex CLI: 0.154.0-alpha.6.2.

What subscription do you have?

Not recorded in this sanitized diagnostic snapshot.

What platform is your computer?

macOS 26.5.1, Apple Silicon. uname -mprs: Darwin 25.5.0 arm64 arm.

What issue are you seeing?

Reopening tasks in Codex Desktop intermittently shows older conversation content even though work has finished. A read-only investigation on September 15, 2026 found a discrepancy between a completed turn's persisted history and the app's exposed task-reading tools.

For one affected local thread:

• thread_turns contains a completed latest turn, a completion timestamp, and a populated final_agent_item_id.
• thread_items contains 11 items belonging to that same turn. Its final assistant message has phase: "final_answer" and 291 characters of text.
• The history projection's byte offset equals the current source rollout file length. This sampled thread's projection is not behind the source file.
• codex_app.read_thread with turnLimit: 1 returns that same latest completed turn but items: [].
• codex_app.wait_threads with timeoutMs: 0 reports the same completed turn but latestAssistantMessageId: null and latestAssistantMessage: null.

The final reply still exists locally. This does not establish that the database, tools, and UI all share one root cause, but the differing results may help isolate the history-loading problem.

What steps can reproduce the bug?

Observed workflow, not yet a deterministic minimal reproduction:

1. Use a local desktop task for multiple turns involving tool calls and long-running work.
2. Let a turn finish, then switch away and reopen the task from the sidebar.
3. Observe older content or an absent latest final reply.
4. Compare the latest turn returned by the supported read_thread and wait_threads tools with the corresponding persisted turn and item records, using read-only database access.

The database comparison above was performed on an idle thread whose latest turn was completed. A separate sampled thread had a previous unfinished turn with no final message; that case was excluded from the missing-final-reply evidence.

What is the expected behavior?

Reopening a completed task should display its latest saved final reply. Task-reading tools should return the persisted items for that turn, or an explicit loading/error state, rather than silently returning an empty item list or null final message.

Additional information

Related warnings in local logs, with identifiers redacted:

2026-09-15 08:49:57 +08:00
WARN codex_app_server_protocol::protocol::thread_history
thread/resume: dropping turn-scoped item for unknown turn id <redacted>
item_id="exec-<redacted>"

2026-09-15 08:53–08:55 +08:00
error [electron-message-handler] [desktop-notifications][global-error]
ResizeObserver loop completed with undelivered notifications.

These warnings are correlated observations, not a confirmed explanation of the empty history result.

Storage and memory checks during the investigation:

• Approximately 432 GiB of free disk space.
• Swap usage and compressed memory both zero at the sampled time.
• Browser cache approximately 1.55 GiB; history database approximately 4.29 GiB.
• No typical disk-full, database-corruption, or database-locked messages matched in the sampled 8,000 recent backend log entries.

No history, cache, database records, credentials, or project files were deleted or modified during the investigation. Raw transcripts, customer/project content, account identifiers, local user paths, and credentials are omitted from this public report.

Possibly related: #35304 reports the same unknown-turn warning in the VS Code extension. This report concerns the macOS desktop app and additionally documents a saved final reply returning empty through task-reading tools.

Also reviewed #40178 and #40112, which describe a projection stopping behind the source rollout. In this sample the projection has reached the source file's end and already contains the final message, while the reading tools return no items. The root cause may still be related; no duplicate-ordinal or stuck-projection cause is asserted here.

Start by comparing the persisted thread_turns and thread_items records with the results of codex_app.read_thread and codex_app.wait_threads for a completed turn. Review the thread/resume unknown-turn warning in the backend logs and the related issues #35304, #40178, and #40112. Done means reopening a completed task shows its saved final reply and the reading tools return its persisted items or an explicit loading/error state.