Expose pending queued-input state to the active agent

What variant of Codex are you using?

Codex App on macOS. The underlying capability would also be useful in the CLI, IDE extension, and Remote.

What feature would you like to see?

Expose pending queued-input state to the active agent so it can tell when additional user-submitted messages or annotations are still waiting.

Today, the client can display and manage queued follow-ups, but the active agent does not receive a queue count or a signal that more submitted input remains. It sees each message or annotation only when the host dispatches it. This means the agent can answer, declare a task complete, run tests, or trigger CI after the first queued item without knowing that additional corrections, constraints, or annotations are already waiting behind it.

At minimum, include read-only queue metadata with delivered user input, such as:

{
  "queued_user_input": {
    "current_index": 1,
    "total_submitted": 3,
    "remaining": 2,
    "types_remaining": ["message", "annotation"]
  }
}

Equivalent implementations would also work, for example:

• A system notice such as: "Two additional user-submitted inputs remain queued."
• A read-only read_pending_user_input capability that returns a count and, if appropriate under the product's privacy model, the submitted input contents.
• Dispatching all input already pending at a stable boundary as one ordered batch while preserving individual message and annotation boundaries.

This should cover only messages or annotations the user has actually submitted, never unsent composer drafts. The state should update when queued items are edited, canceled, reordered, or delivered, and it should remain scoped to the correct thread across reconnect or resume.

Example acceptance cases:

1. A task is running.
2. The user queues messages A, B, and C.
3. When A is delivered, the agent can determine that two additional submitted messages remain.
4. The agent can avoid presenting a final conclusion before B and C are incorporated.
5. If C is canceled before delivery, the visible count updates accordingly.

A second important case is phase gating:

1. The user instructs Codex: "Postpone tests and CI until all of my queued messages and annotations have been handled."
2. The user submits several follow-ups while Codex continues editing.
3. While the pending count is greater than zero, Codex can continue incorporating feedback but defer tests, builds, pushes, or CI runs.
4. When the queue reaches zero, Codex runs the validation phase once against the complete requested change.

Without queue awareness, Codex cannot reliably satisfy that instruction. It may repeatedly test intermediate states, trigger CI for obsolete changes, spend unnecessary time and compute, or report validation before all known user feedback has been incorporated.

Additional information

This is different from general queue management in the UI. The requested capability is specifically agent awareness of pending user intent. It would remove the need for conventions such as "I am sending four notes; wait until I say done," prevent premature final answers, and let users deliberately gate expensive or externally visible workflow phases until their submitted feedback is complete.

Related issues address adjacent concerns but not this exact capability:

• #35356 requests grouping queued messages and showing their count in the UI.
• #33835 requests causal metadata and reliable ordering when queued messages are delivered.
• #28106 requests read-only pending-message visibility from side conversations.

Those improvements are complementary. This request is for the active agent itself to receive a reliable indication that more submitted user input remains pending in its own thread.

Begin by tracing how queued follow-ups are dispatched to the active agent in Codex App on macOS, then compare the CLI, IDE extension, and Remote paths. Done means the agent receives accurate pending-input state for submitted messages and annotations, including edits, cancellations, ordering, reconnects, and thread scope, and can use it to defer validation until the queue is empty.