Skip to content

Agents are not managing subagents reliably #40299

Open
Open
Agents are not managing subagents reliably#40299
Labels
bugSomething isn't workingsubagentIssues involving subagents or multi-agent features

Description

@rafaself
rafaself
opened on Aug 24, 2026

What issue are you seeing?

The main agent does not handle subagents reliably.

When a subagent task takes a little longer, the main agent often stops or closes the subagent prematurely and continues the task on its own, instead of waiting for the subagent to finish.

When explicitly instructed to wait for the subagent's response and only close it when appropriate, for example, when the task is completed or an error occurs, the opposite problem happens: the main agent starts polling the subagent repeatedly at very short intervals.

While waiting, it also tends to perform unnecessary actions instead of remaining idle. It seems unable to simply wait for the subagent when no other work is required.

What steps can reproduce the bug?

  • Start a new thread;
  • Ask main agent to spawn a subagent to proceed with some task.

What is the expected behavior?

The main agent should manage subagents according to their actual state:

If a subagent is still working, the main agent should not terminate or close it prematurely.
If there is nothing useful to do while waiting, the main agent should become idle instead of repeatedly polling or performing unnecessary work.

The main agent should resume execution when it receives a completion/error signal from the subagent, ideally through an event, hook, or similar mechanism.

A subagent should only be closed when its work is complete, it has failed, or cancellation is explicitly required.

Ideally, waiting for a subagent should be event-driven rather than implemented through aggressive polling.

Additional information

I would say that in general, subagents are not being managed reliably, not only in these previous points.

Activity

  1. rafaself
    added
    bugSomething isn't working
    on Aug 24, 2026
  2. github-actions
    added
    subagentIssues involving subagents or multi-agent features
    on Aug 24, 2026

  3. github-actions commented on Aug 24, 2026

    @github-actions
    github-actionsbot
    on Aug 24, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  4. rafaself commented on Aug 24, 2026

    @rafaself
    rafaself
    on Aug 24, 2026
    Author

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    * [Abnormal token consumption: ~678M tokens used while editing 3 resume versions due to repeated multi-agent polling #39854](https://github.com/openai/codex/issues/39854)

* [Remote SSH: `codex_app.wait_threads` has no registered handler while list/read/send remain healthy #40105](https://github.com/openai/codex/issues/40105)

* [Codex Desktop: background turn reported completed/interrupted while JSONL continues without final_answer or task_complete #38972](https://github.com/openai/codex/issues/38972)

    Powered by Codex Action

    They don't look related.

  5. LuckyPro-X commented on Aug 31, 2026

    @LuckyPro-X
    LuckyPro-X
    on Aug 31, 2026

    Adding a macOS Codex Desktop reproduction with a closely related symptom.

    Environment:

    • Codex Desktop 26.825.51511 on macOS
    • Bundled Codex CLI 0.151.0-alpha.7.2
    • Model observed: gpt-5.6-luna
    • Local run window: 2026-08-31 08:57–09:36 UTC (16:57–17:36 Asia/Shanghai)

    The main-thread transcript contained repeated user-visible progress/commentary messages while a healthy subagent was still running. The messages were not limited to the Activity/Subagents panel. Examples from the local rollout (UTC):

    • 09:00:21 — “修复子代理仍在运行，尚未返回结果；我保持在工作流规定的等待状态，没有并行触碰代码或审核产物。首轮等待超时不代表失败，继续等待其完成。”
    • 09:01:28 — “修复子代理仍未完成，第二次有效等待也只是超时快照；按工作流约束继续等待，不做主代理重复实现。”
    • 09:03:35 — “代理正在执行多项跨前后端修复及逐项验证，尚未进入最终返回；目前没有失败状态或需要用户介入的请求。我继续按 fix 工作流等待。”
    • 09:10:01 — “仍无完成或错误状态；等待窗口已覆盖约十分钟。”

    There was no Goal mode, no user-typed follow-up, and no explicit steer/stop action from the UI. The Desktop preference followUpQueueMode = “steer” was present, but it was not exercised by a user follow-up. At 09:30:32 UTC, the parent independently invoked the multi_agent_v1__send_input path and injected a “do not wait for further user input; complete and return” message into the still-running worker. This was coordinator intervention after a normal wait timeout, not a user action.

    Expected behavior: while a subagent is healthy, the parent should remain idle/event-driven, with no periodic main-transcript commentary and no send_input/steer intervention. It should resume only on completion, an explicit error/interruption/blocked state, or a user-input request. A timeout or unchanged status should be treated as normal.

    This macOS/Desktop reproduction seems to fit the reliability and unnecessary-action problem described here. It also appears related to the lower-level repeated parent-turn/wait behavior in #35108. A user-controlled silent-wait/non-intervention mode, or a runtime-managed event-driven wait that does not resample the parent for ordinary timeouts, would address the issue.

    No repository contents, credentials, email address, or local filesystem paths are included. Redacted logs can be provided privately if maintainers need them.

  6. rezzminator commented on Sep 5, 2026

    @rezzminator
    rezzminator
    on Sep 5, 2026

    Added a measured CLI 0.153.3 direct-v2 reproduction and source findings here: #35108 (comment). The default 60-second developer-level wait/commentary guidance defeated AGENTS.md instructions to use a long mailbox wait. A targeted developer exception plus v2 settings let one wait wake on completion after 187.005 seconds without parent status queries. Repeated parent inference creates excessive token consumption for unchanged status. Please track this as a runtime orchestration defect and test that a healthy child does not cause periodic parent-model calls or unsolicited steering. The linked report distinguishes this direct-v2 behavior from the nested-v1 wrapper path.

  7. tagorr commented on Sep 8, 2026

    @tagorr
    tagorr
    on Sep 8, 2026

    I have a Codex CLI reproduction that matches both failure modes described here: premature intervention in a healthy subagent and aggressive polling while waiting.

    Environment:

    • Codex CLI 0.153.1
    • Windows
    • Parent: gpt-6-astra / low
    • Worker: gpt-5.6-luna / xhigh

    In one bounded implementation task, the first Luna worker remained active and was making real progress, but the Astra parent interrupted it twice.

    After the second interruption, the parent discovered that the worker had already produced a substantial partial patch:

    2 files changed
127 insertions
6 deletions

    So the worker was not dead or stuck; the parent intervened while useful work was still in progress.

    The same run also showed the opposite behavior while waiting:

    • 47 × wait_agent
    • all 47/47 used timeout_ms = 30000
    • all 47/47 returned timed_out: true
    • the parent repeatedly resumed and polled again instead of remaining idle/event-driven

    This seems to reproduce both sides of the reliability problem described in this issue: the coordinator either interferes with a healthy worker too early, or repeatedly re-enters the model to poll unchanged status.

    I posted the full rollout telemetry and diagnostics here:
    #35259 (comment)

  8. rafaself commented on Sep 24, 2026

    @rafaself
    rafaself
    on Sep 24, 2026
    Author

    Recently, I noticed some improvements on how main agent manage the subagent. Now, agents is waiting for subagents tasks reliably when necessary and not going with "random actions" when it should just wait for the subagent to finish the task.

  9. rafaself commented on Sep 24, 2026

    @rafaself
    rafaself
    on Sep 24, 2026
    Author

    I have a Codex CLI reproduction that matches both failure modes described here: premature intervention in a healthy subagent and aggressive polling while waiting.

    Environment:

    * Codex CLI **0.153.1**

* Windows

* Parent: **gpt-6-astra / low**

* Worker: **gpt-5.6-luna / xhigh**

    In one bounded implementation task, the first Luna worker remained active and was making real progress, but the Astra parent interrupted it twice.

    After the second interruption, the parent discovered that the worker had already produced a substantial partial patch:

    2 files changed
127 insertions
6 deletions

    So the worker was not dead or stuck; the parent intervened while useful work was still in progress.

    The same run also showed the opposite behavior while waiting:

    * **47 × `wait_agent`**

* all **47/47** used `timeout_ms = 30000`

* all **47/47** returned `timed_out: true`

* the parent repeatedly resumed and polled again instead of remaining idle/event-driven

    This seems to reproduce both sides of the reliability problem described in this issue: the coordinator either interferes with a healthy worker too early, or repeatedly re-enters the model to poll unchanged status.

    I posted the full rollout telemetry and diagnostics here: #35259 (comment)

    They apparentely fixed/improved both issues you also found. You look for it now.

  10. rafaself commented on Sep 24, 2026

    @rafaself
    rafaself
    on Sep 24, 2026
    Author

    Added a measured CLI 0.153.3 direct-v2 reproduction and source findings here: #35108 (comment). The default 60-second developer-level wait/commentary guidance defeated AGENTS.md instructions to use a long mailbox wait. A targeted developer exception plus v2 settings let one wait wake on completion after 187.005 seconds without parent status queries. Repeated parent inference creates excessive token consumption for unchanged status. Please track this as a runtime orchestration defect and test that a healthy child does not cause periodic parent-model calls or unsolicited steering. The linked report distinguishes this direct-v2 behavior from the nested-v1 wrapper path.

    Interesting.

  11. rafaself commented on Sep 24, 2026

    @rafaself
    rafaself
    on Sep 24, 2026
    Author

    Adding a macOS Codex Desktop reproduction with a closely related symptom.

    Environment:

    * Codex Desktop 26.825.51511 on macOS

* Bundled Codex CLI 0.151.0-alpha.7.2

* Model observed: gpt-5.6-luna

* Local run window: 2026-08-31 08:57–09:36 UTC (16:57–17:36 Asia/Shanghai)

    The main-thread transcript contained repeated user-visible progress/commentary messages while a healthy subagent was still running. The messages were not limited to the Activity/Subagents panel. Examples from the local rollout (UTC):

    * 09:00:21 — “修复子代理仍在运行，尚未返回结果；我保持在工作流规定的等待状态，没有并行触碰代码或审核产物。首轮等待超时不代表失败，继续等待其完成。”

* 09:01:28 — “修复子代理仍未完成，第二次有效等待也只是超时快照；按工作流约束继续等待，不做主代理重复实现。”

* 09:03:35 — “代理正在执行多项跨前后端修复及逐项验证，尚未进入最终返回；目前没有失败状态或需要用户介入的请求。我继续按 fix 工作流等待。”

* 09:10:01 — “仍无完成或错误状态；等待窗口已覆盖约十分钟。”

    There was no Goal mode, no user-typed follow-up, and no explicit steer/stop action from the UI. The Desktop preference followUpQueueMode = “steer” was present, but it was not exercised by a user follow-up. At 09:30:32 UTC, the parent independently invoked the multi_agent_v1__send_input path and injected a “do not wait for further user input; complete and return” message into the still-running worker. This was coordinator intervention after a normal wait timeout, not a user action.

    Expected behavior: while a subagent is healthy, the parent should remain idle/event-driven, with no periodic main-transcript commentary and no send_input/steer intervention. It should resume only on completion, an explicit error/interruption/blocked state, or a user-input request. A timeout or unchanged status should be treated as normal.

    This macOS/Desktop reproduction seems to fit the reliability and unnecessary-action problem described here. It also appears related to the lower-level repeated parent-turn/wait behavior in #35108. A user-controlled silent-wait/non-intervention mode, or a runtime-managed event-driven wait that does not resample the parent for ordinary timeouts, would address the issue.

    No repository contents, credentials, email address, or local filesystem paths are included. Redacted logs can be provided privately if maintainers need them.

    Exactly, it got some improvements, but I am still testing more complexes orchestrations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingsubagentIssues involving subagents or multi-agent features

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions