Mobile “Send now” interrupts Desktop work amid overlapping turn lifecycles and queue desync

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

Summary

While one Codex turn was actively running and additional follow-up tasks were already queued, a new clarification was sent to the same conversation from the phone app using Send now (Отправить сейчас).

When the conversation was then viewed in Codex Desktop:

  1. the previously active execution had been interrupted; and
  2. the older queued tasks had been inserted into the conversation together with the new clarification.

The result looked like an unintended cross-device queue flush/merge rather than a deterministic operation on only the newly selected message.

This is a bug report only. No attempt was made to reproduce, repair, or modify the application state after the incident.

Environment

  • Desktop client: Codex Desktop 26.721.3996.0
  • Desktop distribution: Microsoft Store / AppX
  • Desktop platform: Windows x64
  • Remote client: phone app; exact mobile OS and app build unavailable
  • Both clients were connected to the same account and the same existing Codex conversation/task
  • Conversation state before the incident:
  • one turn actively executing;
  • multiple additional instructions/tasks already waiting in the queue
  • Occurrence date: 2026-07-24

Observed sequence

  1. A Codex task was actively executing.
  2. Additional follow-up tasks/instructions were already queued behind that active execution.
  3. From the phone app, the user opened the same conversation.
  4. The user sent one new clarification.
  5. The user immediately selected Send now for that clarification.
  6. Later, the user opened or inspected the same conversation in Codex Desktop.
  7. The execution that had been running before the mobile action was no longer continuing; it had been interrupted.
  8. The pre-existing queued tasks were no longer preserved as separate queued items.
  9. Those queued tasks appeared in the conversation together with the newly sent clarification, as though the queue had been drained or coalesced into the same submission.

Actual behavior

  • Send now affected more than the newly selected clarification.
  • The active Desktop execution was interrupted without the user intentionally selecting each queued item for immediate delivery.
  • Previously queued tasks lost their separate queued state.
  • Older queued tasks and the new clarification were injected into the conversation together.
  • The ordering and lifecycle seen on Desktop did not match the user's intended sequence.

Expected behavior

Send now should have deterministic, item-scoped semantics across devices.

At minimum:

  • It should operate only on the newly selected clarification.
  • It must not silently drain, merge, or submit unrelated items that were already queued.
  • Existing queued items must retain their order and remain queued unless the user explicitly acts on them.
  • If Send now is designed to interrupt the active turn, the UI should clearly state that consequence before submission and still preserve unrelated queued items.
  • If it is designed as steering, the clarification should be appended to the one active turn without starting, merging, or losing other queue entries.
  • Mobile and Desktop should converge on one authoritative turn state and one authoritative ordered queue.

Impact

This can cause:

  • loss of an in-progress execution;
  • premature or out-of-order delivery of queued instructions;
  • unrelated tasks being combined into one turn;
  • changed agent behavior because instruction boundaries are lost;
  • uncertainty about which work completed, which work was cancelled, and which queued tasks remain;
  • elevated risk when queued items include external writes, deployment actions, or other state-changing work.

Frequency

Observed once. It was not deliberately reproduced because reproducing it could interrupt or reorder additional real work.

Areas to investigate

Please inspect the cross-device transition around the mobile Send now action:

  • whether the mobile client sends an item-scoped steer, an abort plus turn/start, or a queue-drain operation;
  • whether active-turn cancellation and queue mutation are committed atomically;
  • whether a stale mobile queue snapshot is written back over newer server/Desktop state;
  • whether all queued items are serialized into one follow-up payload when only one item is promoted;
  • whether reconnect/hydration on Desktop renders a server-side queue flush or only a client-side merged view;
  • whether queue item IDs and ordering survive the mobile-to-Desktop synchronization path.

Suggested regression scenario

  1. Start turn A and keep it in flight.
  2. Queue items B and C.
  3. Connect a phone client to the same conversation.
  4. Add clarification D from the phone.
  5. Select Send now only for D.
  6. Assert the documented intended behavior for A and D.
  7. Independently assert that B and C remain separate, ordered queue entries and are neither merged into D nor silently submitted.
  8. Reconnect or hydrate Desktop and confirm that both clients show the same active-turn and queue state.

Related reports reviewed — not exact duplicates

  • #34767 reports the opposite lifecycle failure: remote control created two simultaneously active turns in one thread. The present report concerns one active turn being interrupted and unrelated queued items being flushed/merged.
  • #34034 reports cross-device/thread desynchronization and duplicate work, but not the item-scoped Send now queue flush described here.
  • #4312 was a queue/steering enhancement request. This report concerns incorrect behavior in the currently exposed queue/send-now workflow.

No exact existing report was found for the combination of mobile Send now, active-turn interruption, and unrelated queued items being inserted together.

Privacy

Conversation contents, task names, project data, account details, local paths, message text, and full thread/turn identifiers are intentionally omitted. A narrowly filtered lifecycle trace or feedback identifier can be supplied through an approved private route if maintainers request it.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34767
  • #35174
  • #34933

Powered by Codex Action

cryptomasters · 1 month ago

Privacy-scrubbed forensic follow-up

Posted with the reporter's explicit authorization after a read-only inspection of the exact local session journal. Conversation contents, task names, project data, paths, account details, message text, client identifiers, and full thread/turn identifiers remain omitted.

The additional evidence changes the diagnosis slightly: the user-visible queue flush/coalescing remains the observed symptom, but the journal does not prove literal server-side concatenation of queued message text. What it does confirm is overlapping turn lifecycle state in the same persisted thread.

Lifecycle sequence (relative timing)

  • Turn A was already running and had no terminal event.
  • Turn B started in the same persisted thread while A still had no terminal event.
  • About 6m25s later, B aborted with reason interrupted.
  • About 30s later, Turn C started while A still had no terminal event.
  • About 21m51s later, the clarification sent from the phone with Send now was recorded.
  • About 1m24s after that mobile input, A terminated with an authorization-refresh failure.
  • About 33s later, Turn D started. In the inspected range, C had no terminal event before D began.
  • Tool/output activity continued around these lifecycle boundaries.

This is direct evidence that more than one turn lifecycle could coexist in one thread, despite the UI presenting one active task.

Message and queue attribution

  • The mobile user-message record contains no explicit turn ID, queue-item ID, transport source, or action type that would establish how Send now was applied.
  • The recent follow-up messages were not present as exact text copies in Turn D's initial user context.
  • Therefore, the local record does not establish that queued messages were literally serialized into D. The visible coalescing could be caused by UI hydration, queue reconciliation, continuation-context construction, or a server-side transformation not represented in this journal.

Duplicate review

  • #34767 is the closest match and appears to share the same underlying invariant violation: multiple turn lifecycles can overlap in one thread. It does not cover this report's phone Send now trigger or the visible loss of separate queue state.
  • #35174 concerns restart recovery promoting a queued follow-up ahead of an incomplete goal; no mobile Send now action or overlapping-turn evidence is involved.
  • #34933 concerns cross-task coordination injecting a follow-up into active work; it is not the cross-device mobile queue case reported here.

No exact duplicate was found. I am leaving #35207 open. Maintainers can consolidate it into #34767 if that issue is intended to cover this cross-device queue/desynchronization manifestation; the mobile Send now regression scenario from this report should be retained if they do.

Arpit-3000 · 17 days ago

Hi, I'd like to work on this issue. I can investigate the cross-device turn/queue lifecycle behavior and work on a fix. Please assign it to me if it's available.