Codex Mobile remote prompt stuck in Status Sending after steer blocks further input

Start by tracing the Codex Mobile remote-control queue and steer submission paths, then follow how pending items are restored during thread reload or reconnect. Reproduce the stuck Status Sending... state and verify that accepted, failed, canceled, or stale items reconcile correctly without blocking the composer.

Summary

A Codex Mobile remote-control thread can get into a state where a user prompt has apparently been accepted as a steer, but the mobile UI still shows it as a pending queued/sending item. The item cannot be opened or deleted, and the thread stops accepting new remote input from mobile.

This is user-input/control-surface loss rather than only a cosmetic status problem: the mobile client shows a stuck Status Sending... pill at the bottom of the thread, while the prompt composer is effectively unusable for new messages in that same thread.

Observed

Observed on 2026-08-04 from the ChatGPT mobile Codex remote-control surface connected to a host shown in the UI as mac-mini.lan.

1. A Codex thread was active on the remote host.
2. A prompt was entered from mobile while the thread was active.
3. The prompt was steered rather than sent as a normal next turn.
4. After that, the bottom of the mobile thread showed Status Sending... for that prompt.
5. The prompt remained stuck in that state.
6. The pending/stuck item could not be opened for inspection or editing.
7. The pending/stuck item could not be deleted/canceled.
8. New messages could not be entered into the thread from remote/mobile while this stuck state remained.

A screenshot of the failing state shows the mobile thread with a Status Sending... pill near the composer and the remote host context mac-mini.lan visible in the header.

Expected behavior

One of these should happen reliably:

• If the mobile prompt is accepted as a steer, it should leave the sending/queued UI state and become visible as a delivered steer or reflected in the active turn.
• If the steer cannot be delivered, the UI should show a failed/retryable state.
• If the message is still pending, it should be inspectable and cancelable.
• The mobile composer should not be permanently blocked by a stale pending item.
• Queue/steer state should reconcile across mobile reload/reconnect and the remote execution host.

Actual behavior

The prompt appears stuck in Status Sending... indefinitely. It is not inspectable, editable, deletable, or recoverable from the mobile UI, and no new remote messages can be input into that thread from mobile.

Why this matters

Mobile remote control is often used to steer or queue work while away from the host machine. If a pending steer can become an undeletable, unopenable blocker, the user loses the ability to control or recover that active thread remotely. It also creates ambiguity about whether the host received the instruction, whether the instruction is still pending, or whether the thread is simply wedged in the client UI.

Related but not exact duplicates

• #15842: TUI pending-steer state can get stuck after sending during active output. This issue appears similar conceptually, but the observed surface here is Codex Mobile remote control and the visible state is Status Sending....
• #25268: Codex Mobile queued message disappears after background/thread reload. This issue is also about mobile queued input recoverability, but here the message remains visible as a stuck sending item and blocks further input.
• #26294: Request for mobile Queue/Steer controls, including edit/delete. This issue is a concrete failure mode showing why cancel/delete/recover controls are needed.
• #34021: New message queue request is ignored in some remote threads. Adjacent remote queue reliability issue, but this report is specifically about an undeletable stuck sending/steer item.
• #33416: Remote follow-up queue dispatch can depend on the controlling desktop client. Adjacent queue ownership/synchronization problem.

Suggested fix direction

• Treat mobile steer/queue submissions as durable records with stable client IDs and explicit states: local pending, server accepted, delivered, failed, canceled.
• Give every pending mobile queue/steer item an inspect/cancel affordance.
• On reconnect/thread hydration, reconcile pending mobile items against host/app-server state instead of leaving them in an indefinite sending state.
• Ensure a stale pending item cannot block the composer forever; expose retry/cancel or automatically clear it after a known terminal failure.