Main turn can complete before collecting required subagent results; results surface only after the next user prompt #40932

Activity

1. liuyang0508

   added

   bugSomething isn't workingSomething isn't working

   on Aug 26, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   subagentIssues involving subagents or multi-agent featuresIssues involving subagents or multi-agent features

   on Aug 26, 2026
3. github-actions commented on Aug 26, 2026

   

   github-actionsBot

   on Aug 26, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Agents are not managing subagents reliably #40299

   Powered by Codex Action
4. Dexatron-LLC commented on Oct 4, 2026

   

   Dexatron-LLC

   on Oct 4, 2026

   More actions

   Additional recurring observation from 2026-10-04: required child results stayed unprocessed until another user message, despite explicit instructions to keep the parent active and poll every 60 seconds.

   Environment: Windows-hosted workspace with a Linux/WSL shell, zsh, Default collaboration mode, automatic execution with approval policy never. The locally installed CLI reports codex-cli 0.159.3 (measured after resuming; the exact active frontend/runtime build has not been independently established).

   Observed workflow:

   1. The parent coordinates one required child executor and an external manager. The child completes a short, authorized Git/worktree operation and must return its sealed result before the parent can verify it and release the next test run.
   2. The parent explicitly keeps the task open, uses commentary rather than a final response, and repeatedly calls collaboration.wait_agent with a 30-second timeout between direct inbox checks.
   3. A separate local worker sends a 60-second check-in heartbeat. It records the parent's last known status and clearly marks stale status; it does not perform the parent's result verification or start another model turn.
   4. The child finishes and sends progress plus a final result. The parent does not process them or continue the direct polling loop.
   5. The user sends another message saying polling stopped. The pending child messages become available, the parent verifies the already-finished result, and work resumes.

   Timeline, all America/Chicago (UTC-05:00), 2026-10-04:

   Time	Observed event
   09:49:33	Manager confirms the narrow operation window. No further approval is needed to perform those operations.
   09:50:23	Parent acknowledges the confirmation and releases the child.
   09:51:29	Last recorded direct parent inbox/status check. A 30-second wait_agent call follows in the visible transcript.
   09:52:52.453431	Child finishes; all 25 native commands exit 0. It seals its result, reports completion, then stands down awaiting parent verification.
   10:24:18	Manager reports that the parent status has been stale for over 30 minutes and requests a wake-up.
   11:12:12	Independent heartbeat still runs. Its recorded parent-status age is 4,843 seconds, with the last update still 09:51:29.
   11:12:37	After the user's new message, the parent checks the inbox. The queued child completion/progress/final messages surface.
   11:14:46	Parent finishes verification, closes the completed operation window and releases the next test run.

   The completed child result therefore waited about 79 minutes 45 seconds before the parent's resumed inbox check. The parent required user intervention even though the worker and the independent heartbeat remained alive. The user reports that this has happened repeatedly; this comment provides one instrumented recurrence, not a quantified count of prior incidents.

   Important distinction from the original report: in the visible transcript for this recurrence, the parent had issued an active timed wait and had not emitted a normal final response before the stall. I have not inspected a complete runtime lifecycle trace, so I cannot establish whether the host ended/paused the turn, a tool continuation was lost, or another scheduling condition prevented the next activation. The timing and delayed processing are observations; a scheduler or wake-up defect is a hypothesis requiring investigation.

   Expected behavior: while an authorized task has a required uncollected child result, resume the parent on the wait timeout or the child's completion, or visibly disclose that the turn has stopped. A continuing background heartbeat must not be mistaken for a parent that is processing replies. The parent should consume the completed result and continue without another user prompt.

   Related: #46120 and #45206. Private repository contents, credentials, business identifiers, filesystem paths and full session logs are intentionally omitted from this public report.
5. post1917a commented on Oct 12, 2026

   

   post1917a

   on Oct 12, 2026

   More actions

   Additional reproduction on Windows Codex Desktop, 12 October 2026: a required parent/subagent review workflow remained idle for about 3 hours 27 minutes and resumed only after a user message.

   Sanitized parent-rollout timeline (UTC):

   • 2026-10-11 23:53:43.642: collaboration.wait_agent returned timed_out:false; a reviewer message was delivered.
   • 23:54:12.996: the parent emitted task_complete. Its final response explicitly said the independent review was still ongoing and promised to pass the findings on afterward.
   • No subsequent parent task_started appeared until 2026-10-12 03:21:05.943, when the user asked why work had stopped.
   • 03:21:13.593: list_agents exposed completed reviewers. Five queued inter-agent messages materialized immediately afterward, each preceded by inter_agent_communication_metadata { trigger_turn: false }.

   The results were retained, but the dependent next step was not scheduled. The elapsed time between parent turns was 3:26:52.947. Exact child-completion times were not established in this parent-only trace; the late delivery metadata alone does not prove when the original notification was queued.

   Environment: Windows desktop, PowerShell, native MultiAgentV2 tools, Default collaboration mode. Exact active desktop/runtime build was not collected, so this is not attributed to a particular release.

   This matches this issue's finalization gap and the event-driven continuation request in #46120 / #15723. Please clarify the supported contract when required native children outlive a parent turn. A reliable runtime-owned completion-to-continuation path is needed; adding permanent user instructions to keep calling wait_agent would only mask the lifecycle gap.

   No private prompts, project paths, session IDs, credentials or raw logs are included.
6. interconnectedMe commented on Oct 15, 2026

   

   interconnectedMe

   on Oct 15, 2026

   More actions

   Additional Linux / VS Code extension evidence, with two related but distinct failure modes.

   1. Parent finalises while required monitoring/work remains

   The coordinator can emit a final response while saying delegated work is still running, ending the active monitoring turn. The user must prompt it again to obtain inspection/continuation. Instructions to keep monitoring have not reliably prevented this.

   All following times are UTC on 2026-10-15, from the native parent rollout:

   Occurrence	Observed evidence
   A: unattended coordination interval	Parent task_complete at 16:55:55.794, after dispatching a required request to another Codex thread and reporting its response pending. No next parent task_started until a user prompt at 17:48:12.684: 52m16.890s. The relevant earlier one-off timer had been explicitly stopped at 16:37:01; no replacement was armed. This establishes premature finalisation/absent monitoring, not a dropped armed timer. The other thread was separately created, not a native child.
   B: native children explicitly left running	Parent spawned three native agents at 17:56:52.958, 17:57:06.098, 17:57:18.295. It emitted task_complete at 17:57:22.918, explicitly reporting that all three were running and promising parent verification. Next parent task_started was triggered by another user message at 17:57:54.748. This is a separate premature-finalisation occurrence; the short interval reflects prompt user intervention, not a claimed long stall.
   C: additional delegated work	Parent spawned another required agent at 18:00:36.997, then emitted task_complete at 18:00:50.418 while the audit/rectification work remained running. Next user-triggered parent turn started 18:01:30.953. Again, no long-stall claim is made.

   Relevant native identifiers, supplied intentionally for OpenAI diagnostics:

   • Parent thread/session: 01a13e57-8ccf-7930-bc11-6e06313fe55f.
   • Separate recipient thread for A: 01a13e44-44ad-7613-9de1-6e58e0afe650.
   • A's request turn in recipient: 01a1407d-c2dc-7e20-8bcd-d342eafa4a32.
   • B's parent turn: 01a140b5-6c20-7743-b43e-df658e6c21f2.
   • C's parent turn: 01a140b8-dabc-7472-8366-f1ff5c465af0.

   The user reports repeated occurrences over approximately the last week (8–15 October). The table above contains the instrumented occurrences recovered for this comment, all on 15 October; it is not an independently verified cross-day frequency count. Earlier dated reports without exact source timelines are not being presented as additional proven incidents.

   2. Persistent watchdog does not reliably produce parent inspection

   The user also reports a subtler recurring case: a persistent watchdog is configured to counter premature parent finalisation, but it does not always wake the parent into inspecting agents. Operationally it can still depend on the parent remembering to check/wait on the timer.

   Our local mechanism uses a dedicated functions.exec cell with notify / yield_control, a separate ten-second health receipt, recurring 300-second emissions, and functions.wait on that exact cell. Timer process existence, health, a scheduled emission, delivery to a transcript, a resumed model turn, and an actual inspection are distinct conditions.

   Evidence boundary: the recovered occurrence A does not reproduce failure mode 2: its timer was stopped and not replaced. This comment does not establish that a registered durable wake was dropped, nor whether a completed parent is contractually expected to resume on these notifications. The watchdog-wake problem is user-reported recurrence pending a separately instrumented reproduction.

   Recovery in this same session: cell316 started18:01:44.799, health18:01:54.799. Five scheduled emissions at18:06:54.800,18:11:54.801,18:16:54.803,18:21:54.804,18:26:54.807 were observed with parent inspections while the coordinating turn remained active. This demonstrates the active-turn workaround, not reliable wake-up after a completed turn. The cell was explicitly terminated at the bounded checkpoint.

   Environment and version attribution

   Measured on the reporting workstation on 15 October:

   Component	Evidence
   Frontend provenance	Native session metadata: originator=codex_vscode, source=vscode. This report is a VS Code extension occurrence, not a claim of a standalone Linux Desktop reproduction.
   Session-reported runtime	Native session_meta.cli_version: 0.162.0-alpha.17.2.
   VS Code	1.142.0, commit 6d62b1d5dace93a33b3a6d3eca1317bd5e15bcb1, x64.
   Installed Codex extension	openai.chatgpt 26.5901.22334.
   Installed standalone CLI	codex-cli 0.160.0; inventory only, not proof it hosted this session.
   Extension-bundled executable queried now	codex-cli 0.153.0; differs from session metadata. Exact active executable/build attribution therefore remains unresolved; please do not conflate these three version values.
   Parent model / mode	Native turn context: gpt-6.1-sol, reasoning low, Default collaboration mode; native agents also used explicit separate model/effort assignments.
   OS / kernel	Ubuntu 26.04.1 LTS, Linux 7.0.0-38-generic, x86_64.
   CPU / memory	AMD Ryzen9 7900X,12cores/24threads; free reports122GiB total RAM and63GiB swap.
   GPUs	AMD Radeon AI PRO R9700; Radeon Pro W7500; integrated AMD Raphael graphics. No evidence implicates GPU hardware in this orchestration failure.

   No credentials, repository contents, business identifiers or raw private transcripts are included.

   Expected contract / request

   Please distinguish prevention of premature parent finalisation from guaranteed event/timer-to-parent continuation. When required child work or an explicitly registered monitoring obligation remains, either keep the parent runnable, resume it on the supported completion/deadline event, or visibly disclose that monitoring has stopped. A heartbeat alone must not be represented as continuing parent inspection.

   It would help to document which native completion/timer mechanism actually starts a new parent turn after task_complete, including persistence across compaction/reconnect, cancellation and deduplication. Local instructions to keep calling a wait tool mitigate the issue but still depend on the same agent whose monitoring failed.

   Related: #15723, #46120, #32188. This is evidence for the finalisation gap plus a separately qualified watchdog-wake report, not a claim of a proven shared scheduler root cause.