Multi-agent V2 regression: resumed root sessions cannot resume existing subagents

Open 💬 2 comments Opened Jul 14, 2026 by hoganfan

Codex version

codex-cli 0.144.3

Variant

Codex CLI with Multi-agent V2

Platform

macOS, arm64

Summary

After a root session is resumed in a new CLI process, Multi-agent V2 cannot resume or route a follow-up to a subagent created by the previous process.

The root conversation history is restored, including the recorded child identifier, but the live agent tree is not. V2 has no equivalent of the V1 resume_agent(id) operation, and followup_task cannot resolve the historical child by either its UUID or canonical task path.

This is a behavioral regression from Multi-agent V1, where a resumed root can explicitly resume a completed child by ID and continue that same child conversation.

Minimal reproduction

With Multi-agent V2 enabled:

  1. Start root process A.
  2. Spawn one child and ask it to remember a distinctive sentinel.
  3. Wait for the child to complete and record its UUID and canonical task path.
  4. Exit process A completely.
  5. Start process B with codex exec resume <root-session-id>.
  6. Ask the resumed root to continue the historical child using followup_task.

Observed results:

  • targeting the UUID returns an agent with id ... not found error;
  • targeting the canonical task path returns a live agent path ... not found error;
  • the root history resumes, but the child cannot be resumed;
  • the only practical fallback is spawning a new child and losing the previous child context.

V1 control experiment

I repeated the same cross-process experiment with codex-cli 0.142.5 and Multi-agent V1:

  1. Process A spawned one child with fork_context=false.
  2. The child memorized a sentinel, returned it, and completed.
  3. Process A exited without closing the child.
  4. Process B resumed the same root session.
  5. The resumed root called resume_agent(child_id), which returned pending_init.
  6. It then called send_input(child_id) with a message that did not contain the sentinel.
  7. The same child returned the sentinel from its first-turn context.
  8. The resumed root made zero spawn_agent calls.

The child rollout retained the same session ID and contained both turns, confirming actual child-session reuse rather than reconstruction by the root.

Expected behavior

Resuming a root session should preserve the ability to continue its existing subagents. Multi-agent V2 could satisfy this by either:

  • rehydrating the persisted agent tree when the root resumes; or
  • providing an explicit resume_agent-style operation that accepts a persisted child thread ID and reconnects it before send_message / followup_task.

If persistent child resumption is intentionally unsupported in V2, this should be documented as an incompatibility and exposed through a deterministic capability/status result so orchestrators can safely fall back.

Why this matters

Long-running orchestrators commonly resume the root session across phases or process restarts. Without child resumption, they cannot continue a specialized review or implementation worker with its accumulated context, even when they persist the exact child ID. This causes avoidable context loss, repeated work, and additional token usage.

Related issues

  • #32753 tracks a separate Multi-agent V2 regression in operator observability caused by encrypted inter-agent messages.
  • #26718 concerns V1 resume_agent restoring history without the original model/reasoning settings; it demonstrates the earlier persistent-resume surface but is not this V2 failure.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗