Repository navigation
[macOS] Reopening a conversation loses recent visible history; task reader returns older turns despite newer local records #44409
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.903.61454 (build 8378), verified from the installed app bundle metadata.
What subscription do you have?
ChatGPT Pro.
What platform is your computer?
macOS 26.6.2, Apple Silicon.
Darwin 25.6.0 arm64 arm
What issue are you seeing?
When returning to an existing conversation, the user reports that recent conversation history is not preserved in the visible conversation. This prevents reliably resuming work and forces reconstruction of recent progress.
During investigation from another task, the app's task-reading tool also returned older turns as the newest available turns, even though the local session record contains many newer user messages, assistant messages, completed commands, and errors.
These are two observations to investigate together, not proof that the visible-history symptom and the task-reader discrepancy have the same cause. There is no evidence that the underlying local messages were deleted.
What steps can reproduce the bug?
User-observed UI sequence:
- Work in an existing conversation over multiple turns.
- Leave and return to the conversation.
- Recent history is missing from the displayed conversation.
Independent diagnostic observation from a second task:
- Read affected session
01a0820c-21a3-7381-9817-5dd5952beedeusingmcp__codex_app__read_thread, withturnLimit: 6,includeOutputs: true, andmaxOutputCharsPerItem: 14000, without an older-page cursor. - Response declares
page.order: "newest_first", but its first turn is01a08408-a4a8-7bb1-8d80-7b8c18d3a390, started on September 9 around 02:39 UTC, with an older video-comparison request. - The same response knows the task is in
systemErrorand reports an updated timestamp of1789013803(September 10, 04:16:43 UTC). - Inspect the local persisted session record read-only: it contains newer September 10 conversation entries, including the user's explicit request to report missing history at 04:16:32 UTC, the assistant's acknowledgement, a successful command, and the final error at 04:16:43 UTC. These are absent from the returned latest-turn page.
The tool mismatch was observed once in this investigation. The visible-history behavior is the user's report; I have not performed an independent GUI reproduction or established its exact trigger. The session is long-running and contains context compaction events; no causal relationship to compaction has been established.
What is the expected behavior?
Returning to a conversation should restore its current persisted message history. A task reader requesting the newest turns should return the latest persisted turns, including interrupted/error turns, or explicitly explain any unavailable/incomplete history. Recent work should remain available without manually reconstructing it from local records.
Additional information
Affected session: 01a0820c-21a3-7381-9817-5dd5952beede.
Latest user report turn: 01a08988-14af-7eb1-9f7e-5239a9ddb213.
The same session has repeated Bad Request failures, reported separately in #44408. Their causal relationship to history restoration is unknown.
Related user-visible symptom: #44127. This report adds a macOS occurrence and the discrepancy between newest-first task retrieval and newer local persisted events.
Private conversation content, project files, credentials, and full raw session logs have not been attached.
Activity
github-actions commentedon Sep 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
scottwalshnz commentedon Sep 10, 2026
Experiencing the same issue on MacOS.
Impacted session: 01a07f7e-4014-7790-ae57-4f93e126721e
What version of the Codex App are you using (From “About Codex” dialog)?
26.903.61454
What subscription do you have?
ChatGPT Pro.
What platform is your computer?
macOS 27.0 Public Beta 6, Apple Silicon.
jimmycarp966 commentedon Sep 11, 2026
Follow-up: the history/retrieval problem is still observable. I checked both the original affected task and a second task while recovering from the repeated failures reported in #44408.
Current installed app: 26.903.71938 (build 8576), bundle ID
com.openai.codex; macOS 26.6.2 (25G83), Apple Silicon. This is a newer installed build than the original report's 26.903.61454 (8378).1. The original newest-turn mismatch reproduces again.
Read-only request, without a page cursor:
{"threadId":"01a0820c-21a3-7381-9817-5dd5952beede","turnLimit":2,"includeOutputs":true,"maxOutputCharsPerItem":1000}The response declares
page.order: "newest_first", but its first turn is still01a08408-a4a8-7bb1-8d80-7b8c18d3a390, started 2026-09-09 02:39:14 UTC. The response's thread metadata hasupdatedAt: 1789015495(2026-09-10 04:44:55 UTC). The persisted local session still contains later September 10 content, including a failed turn01a089a1-e76d-7a01-9fa4-26bcab2b0caacompleted at 04:44:55.393 UTC. The returned latest page does not represent the latest persisted turns.2. A second task returns current turn headers but empty content.
Read-only request:
{"threadId":"01a08989-3438-7662-a2f3-040937b81fc4","turnLimit":6,"includeOutputs":true,"maxOutputCharsPerItem":2000}This response correctly lists recent turn IDs and statuses, including the four
Bad Requestfailures ending at 2026-09-11 01:07:36 UTC, and reportssystemError. However, all six returned turns haveitems: [], including two successfully completed turns.Concrete comparisons with the persisted local record:
01a08d66-3be4-7cf2-8699-c1a0a0a4db0c: local record contains a user message at 2026-09-10 22:18:03.060 UTC and an assistant final response at 22:18:13.113 UTC; the task reader returns an empty item array.01a08df7-d374-79e1-8e4c-29a0f17af289: local record contains the user's follow-up, multiple assistant progress messages, and completed tool/command records from 2026-09-11 00:57–01:06 UTC; the task reader returns an empty item array.01a08e01-0dac-7701-852c-7abcf695ea18and01a08e01-7746-7d02-8f61-d46754c0750c: local record preserves the user's short messages; even these are absent from the returned items.The second observation differs from the original stale-order symptom: headers are current, but message bodies are unavailable through the reader. I am documenting them separately, not assuming they have the same cause.
Practical impact: the task remained unfinished, and resuming required a new task plus reconstruction from local records because the normal task-reading result did not provide the recent conversation. The underlying local content is still present; this is not evidence of permanent message deletion. I have not independently reproduced the GUI reopening sequence in this follow-up, so the fresh confirmation here is of the retrieval discrepancies, not a new GUI-specific claim. The causal relationship to
Bad Requestor compaction remains unknown.Only identifiers, timestamps, and structural diagnostics are included; no private project content, credentials, media URLs, or full raw session logs are attached.
Whitelaughter commentedon Sep 11, 2026
Possibly related reports, in case they help correlate the failure modes:
#43276 — ordinary Chat conversations can exist in fresh account history but be absent from the desktop local catalogue after the Chat update subscription is unmounted.
#44035 — Windows: newer conversation records remain persisted locally while read_thread exposes stale older history.
#44362 — Windows: recent messages remain in the session JSONL while read_thread returns older turns as newest_first.
#44409 — macOS: recent persisted records similarly exist while reopening/task reading exposes older history.
I also posted independent Windows/web synchronization observations from our RETIS tests in #43276. Those tests distinguish Recents/sidebar visibility, explicit conversation search, persisted conversation state, and information actually retrievable by the assistant.
These may not share one root cause, but the reports seem useful to compare because they independently show divergence between different representations/retrieval paths for conversation history.
kys42 commentedon Sep 12, 2026
An update from my side: I experienced this across multiple conversations in the macOS desktop app. The visible history appeared stuck at an older point, while the assistant seemed to retain context from more recent messages. Restarting the app alone had not resolved it.
After updating to the latest version available to me and restarting, all of the affected conversations I checked now load their recent history again. Things appear to have recovered for now. I'll keep an eye on whether the issue recurs and report back if it does.
hogansung commentedon Sep 17, 2026
Another macOS occurrence on 26.908.70816 (build 9275), macOS 26.6.2, Apple Silicon (September 17, 2026). This is a read-only comparison; I have not isolated the root cause.
thread_history_1.sqlitehas indexed items for those same three turns (including user and assistant messages);PRAGMA quick_checkreturnsok. The projection state points to the JSONL EOF (byte offset 21,005,241; next ordinal 7,841).mcp__codex_app__read_threadreturns the correct three newest turn IDs and completed statuses, but each turn'sitemsarray is empty. This repeats when paging withturnLimit: 1. Older turns in the same task return populated items.idle, and its final answer and local work artifacts are present. I have not tried restarting or modifying the history database.This seems closest to the second-task symptom described in this issue's earlier follow-up: current turn headers with empty content. It differs from the stale-turn ordering variant. I am withholding the thread ID, raw transcript, and project paths because they contain private work; a redacted ordinal/item comparison could be supplied if useful. A supported, non-destructive history rebuild would help users recover the app view.