[ChatGPT Web/iOS][data loss] Sending from a stale desktop tab can make newer mobile and voice turns disappear

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

ChatGPT/Codex desktop 26.915.31945 (build 9922).

Affected surfaces also include an already-open ChatGPT conversation in an in-app/web browser and the ChatGPT iOS text/realtime-voice client. The exact iOS build was not collected.

What subscription do you have?

Paid ChatGPT subscription. The exact tier is intentionally omitted from this public report.

What platform is your computer?

Darwin 27.2.0 arm64 arm

What issue are you seeing?

Summary

A stale desktop browser tab can apparently become authoritative when it submits a new message, causing newer turns created in the same conversation on another device to disappear.

In the observed sequence, the same existing ChatGPT conversation remained open in an older desktop tab. The conversation was then continued for an extended period on an iPhone using both text and realtime voice. Without refreshing the old desktop tab, a new message was later submitted from that stale view. After that send, the newer mobile and voice turns were no longer visible in the conversation and could not be recovered through normal reopening or refreshing.

This is reported as a recurring problem, not a single isolated occurrence. The amount of missing history can represent hours of conversation, accumulated context, decisions, and ideas.

No conversation excerpts, conversation IDs, private URLs, names, locations, account identifiers, screenshots, or raw logs are included in this public report.

Actual behavior

• The stale desktop client accepts the new message without warning.
• The conversation subsequently appears to continue from the older desktop checkpoint.
• Newer text and voice turns created on the mobile client disappear from the visible history.
• No stale-revision warning, merge conflict, version selector, recovery interface, or recoverable branch is exposed.
• The user cannot determine whether the newer turns were deleted, orphaned, hidden by an incorrect branch pointer, or omitted during state reconstruction.

This is not merely a delayed sidebar update. The visible conversation body loses newer turns after the stale client submits.

Impact

This should be treated as a data-integrity and potential data-loss defect. Normal multi-device use can result in the apparent irreversible loss of hours of text and voice conversation. A user cannot reasonably know that an already-open tab has become dangerous to use.

The failure undermines trust in long-running conversations, realtime voice, and cross-device continuity. It also makes downstream assistant responses operate without the context the user reasonably believes was saved.

What steps can reproduce the bug?

1. Open an existing ChatGPT conversation on a desktop browser or in-app browser. Leave that tab open without refreshing it.
2. Open the same conversation on an iPhone using the same ChatGPT account.
3. Continue the conversation on the phone with multiple text turns and a realtime voice session.
4. Confirm on the phone that the newer conversation is visible.
5. Return to the older desktop tab without refreshing or reopening it.
6. Submit a new message from that stale desktop view.
7. Reopen or refresh the same conversation on both clients.
8. Observe that the newer phone and voice turns may be absent and that the thread appears to continue from the stale desktop checkpoint.

Reproduction is intermittent, but the reporter has experienced this failure pattern repeatedly across multi-device use.

What is the expected behavior?

A stale client must never be allowed to remove, replace, hide, or orphan conversation turns already committed from another device.

When a client submits against an outdated conversation revision, the system should do one of the following:

1. Rehydrate the latest server state and append the new message to it.
2. Merge the new message into the current conversation revision.
3. Reject the stale write with a clear instruction to refresh.
4. Preserve both branches and expose a safe recovery or conflict-resolution interface.

The server should validate a client revision, message/event sequence, or equivalent concurrency token before accepting the write. An append operation must not silently replace the canonical conversation with cached client state.

Voice and mobile turns should be durably committed before their client reports them as saved. If synchronization or reconstruction is incomplete, the UI should explicitly report that state and prevent a potentially destructive send.

Additional information

Classification

• Data integrity / potential data loss
• Multi-device synchronization
• Stale-client write / lost-update concurrency failure
• Conversation branch or state-reconciliation failure
• Web/desktop + iOS + realtime voice

Suspected failure mode

This is a symptom report, not a confirmed root-cause diagnosis. The behavior resembles a lost-update concurrency defect in which an outdated client revision is accepted without reconciliation against newer server-side events. Other possibilities include an incorrect canonical branch pointer, incomplete voice-turn persistence, or history reconstruction selecting a stale checkpoint after the send.

Required safety properties

• Conversation messages should behave as append-only user data.
• Every write should be validated against the latest server revision.
• A stale client must be rejected or rebased, never treated as authoritative without reconciliation.
• Superseded branches/events should remain recoverable.
• Users should receive an explicit conflict warning before any risky send.
• Automated regression coverage should include desktop-to-mobile text, mobile realtime voice, an offline/stale desktop client, multiple stale tabs, and restart/reload recovery.

Related but not identical reports

• #43267: assistant replies missing from desktop history after mobile voice use.
• #45058: iOS conversation-state desynchronization with disappearing messages and stale-context responses.
• #42176: recurring conversation synchronization inconsistency across desktop, web, and iPhone.
• #43644: messages fail to appear consistently across mobile and desktop until restart.

Those reports establish a broader synchronization symptom family, but this report focuses on the destructive trigger: submitting from a stale desktop tab immediately before the newer mobile/voice history disappears.

Privacy and diagnostics

Private conversation content is intentionally excluded. If maintainers provide a secure private channel and a safe diagnostic procedure, the reporter can provide approximate incident timing, sanitized client metadata, or a feedback identifier. Public comments should not request raw transcripts, authentication cookies, access tokens, browser-profile data, or private conversation URLs.

No repository files, tests, or code entry points are identified. Start by reproducing the seven-step stale-desktop/mobile sequence and compare the conversation state before and after the stale send; done means newer turns remain preserved and the stale write is rejected, rebased, or safely surfaced as a conflict.