[Remote / Work] Link messages fail to appear across mobile and desktop; Work stalls until restart restores mobile thread state

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

Not captured for the affected desktop session. Filing from the recovered conversation; the reporting agent does not have the desktop About dialog or host logs. Mobile and bundled-runtime versions at the time of the incidents were also not captured. Please do not treat the reporting cloud workspace's runtime as the affected desktop build.

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

ChatGPT/Codex desktop app in Work mode, with the same conversation also used through ChatGPT mobile Remote. Exact desktop OS/build and mobile OS/build have not been verified for these incidents.

What issue are you seeing?

The mobile Remote and desktop Work views appear to fall out of sync after attempts to send a link. The assistant does not receive/recognize the new link in the available conversation, the desktop thread becomes stalled/idle, and a full desktop-app restart restores the thread state seen on mobile and responsiveness. The link still has to be pasted again.

This happened with two different Google Sheets report links in the same ongoing conversation. The latest incident required quitting and relaunching ChatGPT/Codex; the earlier missing-link incident did not require quitting.

The distinctive failure sequence is:

1. A link is pasted with the intention of sending it to the current conversation.
2. On switching between desktop Work and mobile Remote, the link is missing from the conversation available to the assistant and/or from the other client's timeline.
3. Pasting it again on desktop does not immediately restore a responsive thread in the latest incident.
4. The desktop thread is described by the user as stalled and idle.
5. After fully quitting and reopening ChatGPT/Codex, the desktop shows the thread status/state from the mobile Remote version and the assistant becomes responsive again.
6. The user must paste the link again before it is acknowledged.

“Stalled/idle” describes the user-visible thread behavior. An OS-level application freeze, backend deadlock, permanent message deletion, or confirmed failure of a particular storage layer has not been established.

What steps can reproduce the bug?

These are the observed user steps, not a deterministic minimal reproduction. Exact elapsed times and server delivery acknowledgements were not captured.

Latest incident: switching clients, apparent desktop stall, restart recovery

1. Work in an existing, long-running conversation in desktop Work.
2. Paste a Google Sheets report link into the conversation and attempt to send it.
3. Switch to the mobile Remote view of the same conversation.
4. Observe that the assistant says it cannot see the new link.
5. Return to desktop and paste the link again.
6. Observe that desktop Work remains stalled/idle.
7. Fully quit ChatGPT/Codex and reopen it.
8. Observe that the desktop conversation now reflects the thread status/state from the mobile Remote view and becomes responsive again.
9. Paste the link again; it is then acknowledged.

Earlier incident in the same conversation

1. Attempt to share a different report link.
2. The link does not appear as expected.
3. Return to desktop and find the link missing there too.
4. Paste it again on desktop.
5. Continue without needing to fully quit the app.

At least two missing-link incidents were reported. Only one restart-recovery sequence was reported. Repeated pasting was a recovery attempt, not a controlled test of duplicate submission.

What is the expected behavior?

• A submitted message should appear consistently in the same conversation across desktop Work, mobile Remote, and the context supplied to the assistant.
• The client should clearly indicate whether a message is pending, accepted, or failed, including when switching devices.
• Returning from Remote to desktop should reconcile the current conversation and run state without leaving the thread silently idle.
• Restarting should not be necessary to obtain the current thread state or regain responsiveness.
• Retrying an uncertain submission should not silently lose the message or result in duplicate execution if the earlier attempt was actually accepted.
• A failed synchronization or submission should expose a useful recoverable state rather than making the assistant repeatedly ask the user to resend material.

The underlying research task had deliberately been paused for discussion. The reported problem is receipt/acknowledgement of a new message and synchronization of the thread state; the requested fix is not to make a paused task run automatically.

Additional information

Evidence available in the recovered conversation

The transcript contains two missing-link exchanges, followed by later explicit link messages and acknowledgements:

• In the earlier exchange, the user asked, “Did you get the link”; the assistant said it had the original asset-sheet link but did not see a new results-report link. A subsequent message explicitly containing the link was received, and the report was successfully opened through Google Sheets.
• In the later exchange, the user said, “It was sent.” The assistant checked the previously known sheet's header, found the old report period, and said it did not see a new report. The user then provided an explicit new Google Sheets URL, which was acknowledged.
• The user subsequently described the mobile/desktop switching, desktop stall, full quit/relaunch, recovery of the mobile thread state, and repeated pasting that are reported above.

The user's observations are the evidence for the cross-device UI behavior and restart recovery. The transcript independently supports the repeated missing-link/repaste/acknowledgement pattern. It does not show the absent original messages or prove whether their initial submission reached the server.

The earlier report was readable once its link was available. That is relevant because the visible failure preceded opening the new document; a document-sharing permission problem alone would not explain the reported cross-client missing message and desktop stall. The later link was acknowledged but document analysis remained intentionally paused.

Impact

• Cross-device continuation of an existing Work session is unreliable.
• Users cannot tell whether a message was received, whether they are looking at stale history, or whether the agent is waiting versus stalled.
• Repeated pasting and status checks interrupt work and create uncertainty about duplicate delivery or acting on the wrong report.
• A full app restart was needed in one occurrence to recover visible state and responsiveness.

Diagnostic boundaries and suggested investigation

This is a symptom report, not a confirmed root-cause diagnosis. No desktop logs, client network trace, feedback ID, canonical rollout inspection, message acknowledgement IDs, or precise incident timestamps are attached. Report prepared on September 8, 2026.

Useful points to correlate in a reproduction:

• Original composer submission, local pending-message state, and server acknowledgement.
• Thread identity and message/event sequence seen by both clients.
• Context actually delivered to the next assistant turn versus what each client renders.
• Remote/desktop reconnect, history hydration, pagination, and cached conversation state.
• Queued prompt and active-turn/writer state when desktop becomes idle.
• What changes during full app restart, and whether pending messages are replayed, lost, or only re-rendered.

No claim is made that a writer conflict, duplicate rollout ordinal, context limit, or a specific recent update caused this incident.

Existing reports checked

Searched openai/codex for Remote synchronization, mobile missing messages, desktop stalls, and “out of sync,” and read the closest reports. Filing separately because none of these establishes the same full input-message disappearance + cross-client state mismatch + desktop stall + restart recovery sequence:

• #43600 — stale newest history on Windows Desktop/Mobile Remote while the host continues accepting messages. Related history synchronization symptoms; the host remains working and temporary recovery occurred without restart.
• #41733 — assistant messages remain invisible until restart while MCP approval dialogs continue. Related restart/rendering symptom; concerns assistant output and live approval dialogs rather than missing submitted link messages while switching clients.
• #43590 — Android/macOS task sync issue involving project membership/sidebar visibility, rather than messages inside an existing thread.
• #37403 — Remote/desktop handoff with an explicit “already has an active writer” error. No such error was captured here.
• #43124 and #41566 — frozen history with verified rollout/projection ordinal inconsistencies. No corresponding storage diagnosis has been made here.
• #41081 — desktop Send stops submitting prompts on Windows; no matching mobile-to-desktop reconciliation sequence is established in that report.

If maintainers identify a common cause, linking or merging this report into the appropriate issue would be welcome.

Official Remote connections documentation describes continuing the same chat across signed-in devices; this report concerns reliability of that continuity.

Private report URLs, spreadsheet contents, client/project names, account identifiers, and raw conversation/log files are omitted. Example payload shape: https://docs.google.com/spreadsheets/d/<redacted-report-id>/edit?usp=sharing.

No source files or tests are named. Start by reproducing the desktop Work/mobile Remote handoff while correlating composer submission, local pending state, server acknowledgement, thread identity, rendered history, assistant context, reconnect behavior, and restart effects. Done means identifying the affected synchronization or state path and verifying consistent delivery, status, and recovery without requiring a restart.