›_ Codex Issues
Codex Issues / #37620

[macOS/iOS Remote] Persisted mobile turns are omitted from the next Desktop model context in the same thread

Open 💬 4 comments Opened Aug 8, 2026 by Devby
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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_threads showed exactly one task, not a fork or duplicate.
  • read_thread for 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?

  1. 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.
  2. Open the same active task from ChatGPT iOS Remote.
  3. Send a follow-up from iOS and receive a completed assistant response.
  4. Send another iOS follow-up with an image attachment, receive a response, then send one more text follow-up.
  5. Later, continue the same task from Codex Desktop.
  6. Ask the Desktop agent about the iOS messages.
  7. Observe that the agent's supplied context does not include them.
  8. 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_thread result 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: #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: #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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 19 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37030

Powered by Codex Action

Devby · 19 days ago

Reviewed #37030. The symptom may share a context-rehydration root cause, but the observed trigger and failure shape differ:

  • #37030 follows a cross-thread delegation and subsequent requests become effectively current-message-only.
  • #37620 occurred through the supported ChatGPT iOS Remote flow. There was no cross-thread delegation at the failure boundary.
  • The iOS turns were already persisted in the same canonical thread and visible through read_thread.
  • The later Desktop run retained older task context but omitted the intervening iOS turns specifically. This was not a complete history collapse.
  • list_threads showed 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 · 18 days ago

Second reproduction in the same thread as the original report.

  • A sequence of messages sent from iOS completed normally and was persisted. read_thread returns the full sequence.
  • The next Desktop model turn retained older history and the current message, but omitted every intervening iOS turn from its input context.
  • The Desktop model did not know about the intervening discussion until the missing history was manually recovered with read_thread.
  • list_threads still 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:

  • ChatGPT macOS: 26.803.41515 (build 6321)
  • Codex CLI: 0.147.0
ropepop · 15 days ago

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_thread sees 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) via thread/resume with itemsView:"summary", even though the same thread's full items are present and renderable on desktop. Leaving the thread and reopening forces thread/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.