Repository navigation
[macOS/iOS Remote] Persisted mobile turns are omitted from the next Desktop model context in the same thread #37620
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.803.41515 (build 6321)
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Darwin 25.4.0 arm64 arm (macOS 26.4.1)
What issue are you seeing?
Turns sent from ChatGPT iOS Remote were persisted in the canonical Codex thread and visible in the task history, but they were omitted from the context supplied to a later Desktop model run in that same thread.
This was not a missing-message UI issue:
list_threadsshowed exactly one task, not a fork or duplicate.read_threadfor that task contained the iOS turns, their image attachment, and the assistant replies in the correct order.- The later Desktop model input did not contain those turns and answered as if they had never happened.
- After being asked explicitly, the Desktop agent used
read_thread, found the omitted turns, and recovered the missing context.
The durable thread and model-visible context therefore diverged.
What steps can reproduce the bug?
- Start a long-running Codex task in the macOS app. In this case the task ran for several hours and had at least one recorded context compaction.
- Open the same active task from ChatGPT iOS Remote.
- Send a follow-up from iOS and receive a completed assistant response.
- Send another iOS follow-up with an image attachment, receive a response, then send one more text follow-up.
- Later, continue the same task from Codex Desktop.
- Ask the Desktop agent about the iOS messages.
- Observe that the agent's supplied context does not include them.
- Inspect the canonical task with
read_thread: the iOS turns and responses are present in the same thread and ordered before the Desktop continuation.
Observed on 2026-08-08. The iOS turns completed around 19:25–19:34 CEST; a later Desktop continuation around 22:19 CEST received stale/incomplete context.
The private thread/session ID and a screenshot are available to OpenAI staff through a private channel if needed. They are omitted here because the conversation contains private project data.
What is the expected behavior?
Every new model run should build its context from the latest canonical history of the selected thread, regardless of whether prior turns were created from iOS Remote or Desktop.
If cross-device reconciliation cannot guarantee this, Desktop should block the continuation or warn that its context is stale. It should never silently run from a history snapshot that omits already-persisted turns.
Additional information
- Codex CLI bundled with the app:
0.147.0-alpha.6.5 - Model:
gpt-5.6-sol - The macOS UI and the canonical
read_threadresult eventually agreed; only the model-visible input was stale. - The thread had undergone context compaction, so stale checkpoint/compaction reconciliation may be involved. This is an inference, not a confirmed root cause.
- Related but distinct: Codex Desktop open thread view does not refresh after another app-server client appends a turn #21743 covers an open Desktop view not refreshing after another app-server client appends a turn. Here the turns were present in the canonical/UI history but absent from the subsequent model context.
- Related but distinct: ChatGPT mobile SSH sessions do not live-sync back to Codex App and can conflict with active macOS app sessions #29094 covers mobile/SSH turns not live-syncing into Desktop. This case used the supported ChatGPT iOS Remote flow and demonstrated durable-history versus model-input divergence.
Activity
github-actions commentedon Aug 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Devby commentedon Aug 8, 2026
Reviewed #37030. The symptom may share a context-rehydration root cause, but the observed trigger and failure shape differ:
read_thread.list_threadsshowed one task, with no fork or duplicate.I am keeping this issue open because the mobile-to-Desktop reconciliation path is independently reproducible and narrower than #37030. Maintainers can merge it if both paths are confirmed to share the same root cause.
Devby commentedon Aug 9, 2026
Second reproduction in the same thread as the original report.
read_threadreturns the full sequence.read_thread.list_threadsstill reported one task. There was no fork, duplicate, or cross-thread delegation at the failure boundary.This reproduces the original selective reconciliation failure: canonical history is complete, while a later Desktop model context skips the intervening iOS turns. It is not only a UI rendering issue. The evidence does not identify which checkpoint or context-building component caused the omission.
Versions:
26.803.41515(build6321)0.147.0ropepop commentedon Aug 12, 2026
Adding an adjacent data point from the view-selection side (2026-08-12) — same machinery, opposite direction of the divergence you've pinned down:
Here the canonical thread is complete,
read_threadsees everything, but the next Desktop model context skips the iOS turns. In my setup the divergence is the client side: iOS remote shows a thread's reasoning/tool items live during the run, then after completion renders only the summary view (user message + final answer) viathread/resumewithitemsView:"summary", even though the same thread's full items are present and renderable on desktop. Leaving the thread and reopening forcesthread/turns/list(full view) and the middle reappears.So mobile↔desktop state divergence shows up in both directions: (a) here, persisted iOS turns omitted from a later Desktop model context; (b) in my case, full desktop materialization but summary-only remote rendering. The common thread is the mobile↔desktop reconciliation boundary — different paths hydrate state in each direction and each can silently skip what the other surfaced. If reconciling mobile turns into the next model context is fixed, the same pass should also make the remote view always use the full read path so the client stops hiding data the rollout contains.