Subagent workflows feel serial because parent-thread follow-ups are queued and interrupted subagent results are not surfaced

What variant of Codex are you using?

Codex desktop app, with subagent workflows enabled.

Problem

Subagents are described and presented as a way to run work in parallel, but the parent-thread UX currently makes the workflow feel effectively serial.

When a parent thread starts subagents, the parent turn remains busy while it orchestrates/waits. If the user sends another message in the main composer, that message is queued for the next turn rather than being sent once the subagents have started running. From the user's perspective, this means the main thread is blocked even though the delegated work is supposedly happening in parallel.

The interrupt behavior makes this worse. If the user interrupts the parent turn while a subagent is still running, and the subagent completes later, there does not appear to be a reliable main-thread update or synthesized result. The work can feel detached/lost unless the user knows to inspect the subagent separately or explicitly ask the parent to collect results later.

Why this is a big usability issue

This undermines the point of subagents for interactive work:

• The user cannot naturally keep chatting with the main agent while subagents run.
• Follow-up messages look like they should steer the active workflow, but instead wait behind the parent turn.
• Interrupting the parent can leave completed subagent work without an obvious main-thread summary.
• The model of "parallel agents" becomes hard to trust because the visible parent-thread interaction behaves like a serial queue.

In practice, this makes subagents much less useful than expected. The user has to understand internal concepts like parent turns, queued next-turn messages, /agent, and manual result collection. That is too much hidden machinery for a feature whose core promise is parallel delegation.

Reproduction

1. In the Codex desktop app, ask the main thread to spawn one or more subagents for a longer-running task.
2. Wait until the subagent activity has started.
3. Send a normal follow-up message in the main thread composer.
4. Observe that the message is queued behind the current parent turn instead of being processed while subagents continue.
5. Interrupt the parent turn while a subagent is still running.
6. Let the subagent finish later.
7. Observe that the main thread does not clearly wake up with a synthesized update/result from the completed subagent.

Expected behavior

Once subagents have been spawned and are running independently, the main-thread UX should make that concurrency real and legible.

Possible acceptable designs:

• Allow main-thread follow-up messages to steer the active parent workflow while subagents run, instead of queuing them strictly for the next turn.
• Provide an explicit "detach subagents and continue" mode where the parent thread becomes interactive again while children run.
• If the parent turn is interrupted, keep completed child-agent results visible and provide an automatic or one-click way to summarize them back into the parent thread.
• Surface late subagent completion as a clear main-thread event/status update, not something the user has to discover manually.
• Make the composer state explicit: "queued for next parent turn" vs "sent to active workflow" vs "sent to subagent".

Actual behavior

The parent thread remains effectively blocked during ordinary subagent orchestration. Queued messages wait for the next parent turn, and interrupted subagent completions do not appear to reliably produce a main-thread summary.

Additional context

The docs explain that Codex waits for subagent results and returns a consolidated response, and that queued messages/slash commands run on the next turn. That may be internally coherent, but the product experience conflicts with the mental model of parallel subagents.

This is not mainly a request for more agent intelligence. It is a request for the UI/runtime contract to make parallel delegation usable interactively: if subagents are running in parallel, the user needs a clear way to keep working with the main thread and recover/collect child results after interruption.