Summary
A queued message in Codex Mobile can disappear after the app is backgrounded and the thread is reloaded. This is user-authored input loss: the message was accepted by the UI as Queue rather than Steer, but after returning to the app there was no visible way to resend, recover, or inspect the queued draft.
Observed
Observed on Android on 2026-05-30 while a goal was active.
- A Codex Mobile thread was in the middle of an active goal / long-running turn.
- I typed a follow-up message and tapped Queue, not Steer.
- I left/backgrounded the app before the active work consumed that queued message.
- I came back later.
- The thread took a while to load.
- Once it loaded, the queued message was gone.
- There was no visible resend/retrieve/recover affordance.
Expected
Queued messages should either be durable or explicitly recoverable:
- remain visible across background/resume and thread reload until sent or canceled
- survive while a goal/turn is active
- show whether the queued message is local-only, server-synced, sent, canceled, or failed
- provide a retry/recover path if the app could not submit or restore the queued message
Actual
The queued message disappeared silently after reload.
Related issues I found
These look adjacent, but I did not find an exact duplicate for mobile queued input disappearing after app background/thread reload:
App-server/API note
I am not sure whether the app-server is intended to own queued messages. From a quick scan of the public v2 app-server surface, I see turn/start for adding user input and beginning a turn, and turn/steer for adding input to an already in-flight regular turn. I did not see a public durable queued-message or queued-draft primitive.
If mobile queue state is currently client-only, mobile should persist it locally and reconcile/replay it on reconnect. A stronger cross-client fix might be an app-server-backed queued prompt/draft API, for example:
thread/queuedMessages/listthread/queuedMessages/addthread/queuedMessages/updatethread/queuedMessages/delete- notifications for queued-message state changes
Stable client IDs / idempotency would let mobile safely retry after reconnect without duplicating queued user input.
Why this matters
Queued messages are often written while Codex is doing long-running work. Losing them silently on mobile makes it unsafe to queue important follow-up instructions before switching apps or waiting for a goal to continue.
Summary
A queued message in Codex Mobile can disappear after the app is backgrounded and the thread is reloaded. This is user-authored input loss: the message was accepted by the UI as Queue rather than Steer, but after returning to the app there was no visible way to resend, recover, or inspect the queued draft.
Observed
Observed on Android on 2026-05-30 while a goal was active.
Expected
Queued messages should either be durable or explicitly recoverable:
Actual
The queued message disappeared silently after reload.
Related issues I found
These look adjacent, but I did not find an exact duplicate for mobile queued input disappearing after app background/thread reload:
/newgetting dropped in CLI.App-server/API note
I am not sure whether the app-server is intended to own queued messages. From a quick scan of the public v2 app-server surface, I see
turn/startfor adding user input and beginning a turn, andturn/steerfor adding input to an already in-flight regular turn. I did not see a public durable queued-message or queued-draft primitive.If mobile queue state is currently client-only, mobile should persist it locally and reconcile/replay it on reconnect. A stronger cross-client fix might be an app-server-backed queued prompt/draft API, for example:
thread/queuedMessages/listthread/queuedMessages/addthread/queuedMessages/updatethread/queuedMessages/deleteStable client IDs / idempotency would let mobile safely retry after reconnect without duplicating queued user input.
Why this matters
Queued messages are often written while Codex is doing long-running work. Losing them silently on mobile makes it unsafe to queue important follow-up instructions before switching apps or waiting for a goal to continue.