Queued messages lose causal ordering and can be misinterpreted as replies to later assistant output

What version of Codex CLI is running?

codex-cli 0.144.5

What subscription do you have?

ChatGPT Pro 20x

Which model were you using?

GPT-5.6-Sol Ultra

What platform is your computer?

Codex CLI in a Linux terminal

What issue are you seeing?

Codex CLI allows users to queue messages while an agent is working. However, queued messages may be consumed incrementally across multiple later turns rather than consuming the complete pending queue at one point.

Messages also lack submission timestamps and causal metadata indicating what was visible in the CLI when the user wrote them. This can produce a timeline like:

T1 User queues message A
T2 User queues message B
T3 Assistant posts update X
T4 Codex consumes message A
T5 Assistant posts response Y
T6 Codex consumes message B

At T6, message B appears after response Y in the agent’s context, so it can be interpreted as a reply to Y—even though the user wrote it before either X or Y existed.

The delivery order may technically remain FIFO, but the causal ordering has been lost. The transcript implicitly claims that the user had seen messages which had not yet been displayed when their queued message was written.

This commonly causes short follow-ups such as “do that,” “also check this,” corrections, approvals, or changes of direction to be applied to the wrong assistant message. It makes queueing unreliable and strongly encourages users to wait for every turn to finish instead.

What steps can reproduce the bug?

1. Start a task long enough for Codex to produce intermediate updates.
2. While Codex is working, queue two or more messages at different points.
3. Ensure at least one message is queued before a later assistant update appears.
4. Let Codex process the queued messages.
5. Observe that it may consume only part of the pending queue, produce another assistant response, and consume the remaining messages afterward.
6. Observe that a later-consumed message can be interpreted as responding to assistant output that was posted only after the user had already queued it.

The exact outcome is timing-dependent, but it occurs frequently enough to make the queue unsafe to rely on.

What is the expected behavior?

Codex should preserve both delivery order and causal order.

For every queued message, the agent should be able to determine:

• When the user queued it.
• What assistant messages and visible CLI events existed at that time.
• Which assistant events appeared only afterward.
• When the message was eventually delivered to the agent.
• That an earlier queued message cannot be a response to later assistant output.

Additional information

Adding host-generated timestamps and relative deltas to user messages, assistant messages, and other user-visible CLI events would be a useful minimum fix. These timestamps must be included in the agent’s context, not only displayed in the UI.

A more robust solution would attach structured causal metadata to every queued message:

• queued_at
• delivered_at
• queue_sequence
• last_visible_event_id

last_visible_event_id is more reliable than timestamps alone: it directly identifies the newest event the user could have seen when composing the message.

When delivering an older queued message, Codex could explicitly annotate it as:

“This message was queued before assistant events X–Y were displayed. It must not be interpreted as a response to those later events.”

Draining all messages that are already pending as one ordered batch would reduce the problem by preventing new assistant responses from being inserted between them. However, that alone is not a complete fix: the entire batch could still have been written before assistant output that appears earlier in delivery order. The batch should therefore retain message boundaries and causal metadata rather than being concatenated into one undifferentiated prompt.

This metadata should also survive transcript persistence, compaction, and session resume.

The behavior appears independent of subscription, model, and terminal environment; those details are included for completeness.