Mobile “Send now” interrupts Desktop work amid overlapping turn lifecycles and queue desync
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:
- the previously active execution had been interrupted; and
- 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
- A Codex task was actively executing.
- Additional follow-up tasks/instructions were already queued behind that active execution.
- From the phone app, the user opened the same conversation.
- The user sent one new clarification.
- The user immediately selected Send now for that clarification.
- Later, the user opened or inspected the same conversation in Codex Desktop.
- The execution that had been running before the mobile action was no longer continuing; it had been interrupted.
- The pre-existing queued tasks were no longer preserved as separate queued items.
- 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
- Start turn A and keep it in flight.
- Queue items B and C.
- Connect a phone client to the same conversation.
- Add clarification D from the phone.
- Select Send now only for D.
- Assert the documented intended behavior for A and D.
- Independently assert that B and C remain separate, ordered queue entries and are neither merged into D nor silently submitted.
- 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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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)
interrupted.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
Duplicate review
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.
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.