Codex Mobile: queued message disappears after app background/thread reload

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.

1. A Codex Mobile thread was in the middle of an active goal / long-running turn.
2. I typed a follow-up message and tapped Queue, not Steer.
3. I left/backgrounded the app before the active work consumed that queued message.
4. I came back later.
5. The thread took a while to load.
6. Once it loaded, the queued message was gone.
7. 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:

• openai/codex#22746 reports Codex Mobile not supporting steer/queue messages. This issue is about the newer mobile Queue UI accepting the message and then losing it after reload.
• openai/codex#23100 reports queued messages only processing when the project is in focus. This issue is about mobile state loss after backgrounding/reloading.
• openai/codex#19151 reports queued prompts after a queued /new getting dropped in CLI.
• openai/codex#23615 proposes Queue/Steer/Stash recoverability concepts.
• openai/codex#22895 and openai/codex#14213 cover queued-message editing / queue position behavior in Desktop/TUI.
• openai/codex#13892 covers TUI confusion between queued follow-ups and steer state.

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/list
• thread/queuedMessages/add
• thread/queuedMessages/update
• thread/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.