[Liveness / Wake-up Semantics] Codex Desktop peer-agent coordination stalls without polling, even with a dedicated coordinator #45206

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.4834.0

What subscription do you have?

prolite

What platform is your computer?

No response

What issue are you seeing?

Summary

I have repeatedly encountered a workflow liveness problem when coordinating multiple peer/main agents in the same Codex Desktop project. These are separate top-level tasks, not a parent waiting for its spawned children.

When one agent finishes work needed by another, the dependent agent does not reliably continue without additional intervention. Adding a dedicated coordinator agent did not resolve this: the coordinator itself needed repeated status checks to keep the workflow moving.

This report requests a reliable, opt-in completion/dependency continuation contract for peer tasks. It does not establish a transport-level IPC defect or claim that every messaging API is unable to start a turn.

Environment and evidence limits

• Surface: Codex Desktop, multiple main-agent tasks in one project.
• Exact affected app/runtime version and model: not recorded in the original observation.
• The steps below describe the observed workflow, not an independently instrumented minimal reproduction. Exact messaging tool calls, delivery receipts, and runtime traces are not attached, so the point at which notification or continuation fails remains unverified.

Reproduction / observed workflow

1. Use separate main-agent tasks A and B in the same project, with B depending on A's result.
2. Ask them to coordinate and hand off the result when A finishes.
3. A completes its work and stops executing.
4. B does not resume to perform the dependent work.
5. Without further prompts or active status checking, the workflow becomes quiescent despite unfinished work.

The observed problem includes completion/status not being proactively surfaced to the agent that needs it. It should not be assumed, without traces, that a particular message was successfully enqueued and then ignored.

Dedicated coordinator-agent experiment

I also created a separate main-agent task S whose sole responsibility was coordinating the other agents' status, dependencies, and handoffs.

The intended flow was:

A completes -> S observes completion -> S dispatches B -> B continues

In practice, S did not reliably react to completion once it had no active turn. It only maintained progress by repeatedly checking other tasks. Moving orchestration instructions into a dedicated agent therefore did not remove the need for polling.

Actual behavior

Unfinished peer-task workflows can stall when no participant actively checks status or initiates another turn. A dedicated model-level coordinator encounters the same difficulty.

Expected behavior

Provide or document an opt-in mechanism that registers interest in a peer task's completion and schedules a bounded continuation when its dependency is ready, even after the waiting task has become idle.

The mechanism should preserve explicit user stops and task scope, coalesce duplicate events, and distinguish completion, failure, cancellation, and timeout. It need not wake every recipient on every informational message.

Why polling is insufficient

Polling partially mitigated the stall but caused repeated model activity and substantial perceived token consumption. I do not have a quantified benchmark to attach. Longer blocking waits can reduce checking frequency, but a coordinator that has ended its turn still needs a defined continuation trigger.

Runtime-level interpretation and questions

The desired contract is conceptually:

registered completion/dependency event
  -> recipient becomes runnable
  -> continuation is scheduled
  -> agent consumes the result and decides the next action

This is a hypothesis about the missing workflow guarantee, not a verified diagnosis of the implementation. A model-level coordinator can decide what to dispatch only after it obtains an execution turn.

Explicit follow-up APIs may already start a recipient turn; the remaining question is how completion reliably reaches an idle interested peer/coordinator without an active model having to detect it and send that follow-up. Is there an existing supported contract for this across top-level Desktop tasks?

Related issues and scope

• MultiAgentV2: send_message at a sampling boundary can leave a live subagent running but unscheduled #32756 describes a live subagent left reported as running after queue-only messaging near a sampling boundary. This report does not establish that timing race or involve a spawned child.
• [MultiAgentV2] Idle parent does not resume after child batch completion without polling #37238 describes continuation after a parent-owned child batch. The liveness concern overlaps, but this workflow involves separate main-agent tasks and a peer coordinator, without that parent-owned batch relationship.

The distinct request is reliable event-driven continuation for explicitly coordinated peer tasks, including a coordinator that is itself idle. If an existing issue already owns that exact scope, please link it and clarify the intended workflow.

What steps can reproduce the bug?

1. Open multiple separate main-agent tasks in the same Codex Desktop project (A and B). These are peer tasks, not a parent and its spawned subagent.

2. Give A a task that produces a result needed by B. Instruct the agents to coordinate so that B continues after A finishes.

3. Let B finish its current turn while waiting for A’s result.

4. Let A complete its work. In the observed workflow, B does not automatically continue with the dependent work. Further user intervention or active status checking is needed.

5. Repeat with a separate main-agent task S acting as a dedicated coordinator. Instruct S to track task completion, manage dependencies, and dispatch B when A finishes.

6. Let S become idle while A is working. After A finishes, S does not reliably resume to process the completion and dispatch B. The workflow can remain stalled.

7. Instruct S to repeatedly check the other tasks’ status. This partially mitigates the stall, but introduces repeated model activity and noticeable token consumption.

These steps describe my observed workflow, not an instrumented minimal reproduction. I have not verified the exact notification/delivery path, so I cannot yet distinguish a missing completion notification from a failure to schedule the recipient’s continuation.

What is the expected behavior?

No response

Additional information

No response