Expose pending queued-input state to the active agent #40268

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:

• Feature request: group queued user messages and make them visually distinct #35356 requests grouping queued messages and showing their count in the UI.
• Queued messages lose causal ordering and can be misinterpreted as replies to later assistant output #33835 requests causal metadata and reliable ordering when queued messages are delivered.
• Side conversations should expose main-thread goals, attachments, and pending messages read-only #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.