Codex native subagents: keep parent runs attached until child completion
Codex native subagents work only when the parent run remains able to receive and reconcile each child’s result. OpenClaw v2026.6.34 fixes that ownership boundary by retaining the parent app-server subscription and recognizing multi-agent V2 child activity until a yielded child completion reaches its requester. The practical outcome is less mysterious than it sounds: a completed child should not look like a vanished task just because the parent stream changed state first.
Contents
- What changed for Codex native subagents
- Why completion ownership matters
- The parent-child lifecycle to preserve
- A test plan for multi-agent runs
- Where OpenClaw fits
- FAQ
What changed for Codex native subagents
The OpenClaw v2026.6.34 release notes describe a focused repair for Codex native subagents: retain the parent app-server subscription and recognize multi-agent V2 child activity until a yielded child completion reaches its requester. It is a reliability fix, not a new workflow syntax or a promise that every task should use parallel agents.
The distinction matters. OpenAI’s Codex documentation describes subagent workflows as delegated threads that run focused work in parallel while the main thread collects results into a final response. That arrangement has two jobs:
| Layer | Job | Failure if it disconnects too early |
|---|---|---|
| Parent run | Owns the user request, progress view, and final synthesis | The caller sees an incomplete run or a false finish |
| Child run | Performs one bounded task and returns its result | Work can complete without a visible destination |
| App-server subscription | Carries lifecycle events between the runtime and the parent | A valid child result can be mistaken for lost activity |
| Completion requester | Receives the yielded result and decides what happens next | The system cannot reconcile the child with the original task |
A yielded child is not necessarily a failed child. It may have done exactly what it was assigned and reached a completion state that still needs to travel back through the parent. If the subscription disappears before that handoff, the runtime loses the link between “the worker finished” and “the request has a result.”
Why completion ownership matters
The visible symptom of a broken parent-child boundary is usually confusing: a user sees progress from several workers, then the main run ends without one of the summaries, or a child appears to have stopped even though it completed later. Retrying the whole task can create duplicate writes, duplicate tests, or two agents editing the same file.
A sound multi-agent system needs a clear answer to four questions:
- Which parent request owns this child?
- Which event proves the child started, yielded, or completed?
- Which component remains subscribed long enough to receive that event?
- Which requester is responsible for presenting or acting on the final result?
This is an ownership problem, not merely a streaming problem. Streaming status is useful for people watching a run, but the parent must also preserve enough state to reconcile a late or yielded child result. The OpenClaw repair targets that exact edge: child activity remains recognized until its yielded completion has somewhere to go.
OpenAI makes the same architectural split explicit in its multi-agent guidance. A root agent delegates bounded work, can wait for results, and synthesizes the final answer. The root agent does not need every raw intermediate log in its context, but it does need the result of the delegated work. That is why completion routing is part of correctness, not just UI polish.
The parent-child lifecycle to preserve
A robust Codex native subagent workflow should preserve the relationship below even when progress events arrive out of order or a child yields after the parent has stopped producing visible text.
| State | What the system should retain | What an operator should be able to verify |
|---|---|---|
| Delegated | Parent request ID and the child’s task scope | The child belongs to the intended run |
| Active | The parent subscription and child activity state | Progress remains attributable to the right task |
| Yielded | A pending completion relationship | The child result still has a requester |
| Completed | Result, error, or cancellation outcome linked to the parent | The parent can summarize, retry, or surface the result |
| Reconciled | One final outcome for the original request | The user is not left with ambiguous partial work |
This does not mean the parent should keep an unlimited stream alive forever. A stuck child still needs a timeout, cancellation route, and clear failure state. The point is narrower: do not discard the parent subscription while a valid child completion still depends on it.
The same discipline helps with human review. When a multi-agent coding run changes files, record which child investigated, which child edited, what the parent accepted, and what was tested. Our guide to connected coding agents uses the same principle for session handoffs: scoped context, an explicit workspace, and a completion record make later review possible.
A test plan for multi-agent runs
Test this behavior with harmless, independent tasks before you let multiple workers change shared code or send external messages. Start with a parent that delegates two read-only checks, such as a documentation lookup and a test inventory.
- Confirm delegation. Verify that each child appears under the intended parent request and has a clear task boundary.
- Let one child finish first. Confirm that the parent stays able to collect the first result while the other child is still active.
- Create a delayed completion. Use a controlled slow task, then check that a child which yields after a quiet period still reaches its requester.
- Cancel one child. The parent should distinguish a deliberate cancellation from a successful completion or an unknown disappearance.
- Review the final synthesis. The parent result should state which child outputs were used, which failed, and whether any retry is safe.
For write-heavy work, reduce concurrency rather than hoping the parent can untangle conflicting changes. OpenAI’s guidance recommends more caution when parallel agents share mutable state because coordination overhead and merge conflicts rise quickly. A clean worktree per writer is often safer than several agents editing one checkout. The OpenClaw Control UI guide for parallel agent work and the multi-agent planning guide cover the operational side of separating tasks before they collide.
A useful completion record can stay short:
| Record | Example value |
|---|---|
| Parent task | ”Review the retry regression” |
| Child scopes | ”Trace stream lifecycle” and “run targeted tests” |
| Outcomes | ”One summary returned; one cancelled by operator” |
| Shared-state changes | ”None” or a named branch and commit |
| Next decision | ”Safe to retry only the cancelled read-only check” |
That record is enough to avoid the worst retry mistake: treating an unknown completion state as proof that nothing happened.
Where OpenClaw fits
OpenClaw sits at the coordination boundary between a user-facing request and tool-backed agent runs. The v2026.6.34 Codex repair improves that boundary by keeping the parent app-server subscription and child activity relationship intact until a yielded completion reaches the requester. It does not remove the need to split work well, bound permissions, or review side effects.
Start with how OpenClaw works if you need the broader Gateway model. For decisions that can change files, credentials, or external systems, pair multi-agent orchestration with the same approval discipline covered in Codex agent tool approvals. A child completing successfully is still not authorization to merge, deploy, or send something irreversible.
The safest default is simple: use subagents for independent, bounded work; keep the parent responsible for the final outcome; and leave a traceable result when a child yields, completes, fails, or is cancelled.
FAQ
What are Codex native subagents?
Codex native subagents are delegated agent threads that perform focused work in parallel with a main Codex thread. The main thread collects their results and produces the final response. They are useful for independent research, codebase exploration, testing, and other tasks that do not require agents to edit the same state at once.
What did OpenClaw v2026.6.34 change for Codex native subagents?
OpenClaw v2026.6.34 retains the parent app-server subscription and recognizes multi-agent V2 child activity until a yielded child completion reaches its requester. The release notes present this as a reliability repair for the parent-child completion path.
Should every coding task use subagents?
No. Use them when the work divides into independent, bounded streams. A short sequential task or a change that requires frequent edits to the same files often works better with one agent because parallel writers add coordination and merge risk.
How should a team handle an ambiguous child result?
Treat it as an unknown state until the parent can reconcile it. Check the child scope, logs, changed files, tests, and external side effects before retrying. Retrying a read-only lookup is different from retrying a task that may already have edited code or sent a message.