›_ Codex Issues
Codex Issues / #9607

Main agent not receiving subagent completion signal (collab multi-agent interrupted), requires manual query to continue

Resolved 💬 8 comments Opened Jan 21, 2026 by mkdir700 Closed Jan 22, 2026
💡 Likely answer: A maintainer (jif-oai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

0.87.0

What subscription do you have?

plus

Which model were you using?

gpt-5.2-codex

What platform is your computer?

Darwin 25.2.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

ghostty

What issue are you seeing?

When using Codex's collab (multi-agent) feature, the main agent is not receiving completion signals from subagents when waiting for them to finish. As a result, the main agent remains stuck in a waiting state and requires manual query or inquiry commands to continue.

The issue manifests as follows:

  • Subagent completes execution, but main agent remains in waiting state
  • No clear "completion" event or signal appears in CLI/logs
  • Task is blocked, requiring manual intervention

What steps can reproduce the bug?

  1. Enable collab feature in project directory:

``
codex features list # Verify collab=true
``

  1. Initiate a multi-agent task:
  • Main agent instructs creation of two subagents (A: analyze problem logic, B: execute code operations)
  • Subagent A returns completion result
  • Main agent does not immediately receive completion signal and proceed to next step
  • Main agent stays in waiting state with no progress or timeout message
  1. Attempt to continue execution:
  • Need to manually send status/query subagent status commands to allow main agent to continue

What is the expected behavior?

When subagent finishes execution, main agent should:

  1. Receive a clear completion signal
  2. Continue with the subsequent workflow automatically
  3. Provide clear progress messages or timeout information if signal is delayed

If timeout or signal loss occurs, there should be:

  1. A configurable timeout/retry mechanism
  2. Clear error messages indicating the issue
  3. Options for manual signal acknowledgment or retry

Additional information

_No response_

View original on GitHub ↗

8 Comments

jif-oai contributor · 6 months ago

A few questions:

  1. How do you know the sub-agent was done?
  2. Can you share the main session with /feedback and sending us the session ID?
  3. Do you have a stable reproduction? I can't repro with what you mention

Thanks :)

acgxv · 5 months ago

Same here.

It’s almost always the case. Perhaps it’s incompatible with the superpowers skills.

jif-oai contributor · 5 months ago

@aurexav same questions as above then

acgxv · 5 months ago
@aurexav same questions as above then
  1. I followed the document and created a notify.py script. This script sends a desktop notification once the subagent completes its task but the main agent remains stalled. Once I’ve notified the main agent via chat, it begins checking the subagent’s status which is already complete.
  2. Will try it tomorrow.
mkdir700 · 5 months ago

I can no longer reproduce this issue in version 0.88.0

jif-oai contributor · 5 months ago

This feature is still early stage, we are shipping updates at each version but it's very important to get feedback so thanks for this!
Keep me posted if you spot anything else

acgxv · 5 months ago

Also, https://x.com/llmjunky/status/2014450361885495350?s=46

ThinkOffApp · 4 months ago

Polling-based architectures avoid missed signals entirely. Our setup: IDE Agent Kit rooms watch polls for new messages every 2 minutes and writes them to a file. Claude Code reads the file via a hook. There is no completion signal to miss because the orchestrator checks on a schedule, not in response to an event.

The downside is latency. The upside is that it never gets stuck. If an agent finishes while the orchestrator is busy, the result sits in the room until the next poll. No race conditions, no lost signals, no manual intervention to unstick things.