›_ Codex Issues
Codex Issues / #32017

Support parent/child task workflows with summarized handoffs

Open 💬 3 comments Opened Jul 10, 2026 by fyydnz53
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What problem are you trying to solve?

For long-running engineering projects, a single Codex task can become too large even when the work is conceptually one project. In practice, the project often has one stable main thread that owns the overall direction, decisions, and final outputs, plus multiple complex subtasks that each require their own multi-turn discussion and iteration.

Today, there are a few partial workarounds:

  • Keep everything in one task, which preserves continuity but eventually creates a very large session with lots of stale detail.
  • Start separate tasks manually, which keeps each subtask cleaner but loses an explicit parent/child relationship and requires the user to manually summarize results back into the main task.
  • Use subagents, which are helpful for bounded parallel work, but feel closer to delegated one-off work than a durable child task where the user can have a rich multi-turn conversation.

Proposed solution

Add first-class support for a parent/child task workflow in Codex:

  1. A parent task can create or link child tasks for specific subprojects or experiments.
  2. Each child task has its own transcript, workspace state, and possibly worktree, so it can support a full multi-turn discussion without polluting the parent context.
  3. When a child task reaches a checkpoint or completion, Codex generates a structured handoff summary back to the parent task.
  4. The parent task can see child task status, key decisions, changed files, outputs, risks, and next actions without ingesting the entire child transcript.
  5. The user can reopen a child task for further iteration, while the parent continues to hold the project-level state.

Why this matters

This would fit workflows like:

  • A large data-mining or evaluation pipeline where each filter experiment needs several rounds of discussion and review.
  • Product/engineering planning where the main task owns the roadmap, while child tasks explore implementation, prompt design, evaluation, or data quality.
  • Larger refactors where independent modules can be investigated separately, then summarized back into an architecture-level thread.

The key distinction is that these subtasks are not always one-shot agent delegations. They may require real user-agent collaboration over multiple turns, but the parent task should not have to carry every exploratory detail forever.

Suggested handoff shape

A child-to-parent handoff could include:

  • Objective and final status.
  • Decisions made.
  • Important assumptions.
  • Files changed or artifacts produced.
  • Verification performed.
  • Known risks or open questions.
  • Recommended next step.

Alternatives considered

Manual context files and summaries can work, but they rely on user discipline and are easy to forget during active investigation. Subagents are useful for parallel bounded tasks, but they do not fully replace a durable child conversation that can be reviewed, resumed, and summarized into the main project thread.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

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

  • #30966
  • #31106

Powered by Codex Action

fyydnz53 · 1 month ago

Thanks for pointing to spawn_agent. I agree it covers an important part of this workflow, especially for bounded delegation where the parent task can send a focused prompt and get a summarized result back.

The gap I am trying to describe is slightly different: some subtasks are not one-shot delegations. They need their own user-agent multi-turn discussion, review, and iteration, while still remaining attached to a parent project task.

A concrete distinction:

  • spawn_agent works well as an execution primitive: isolated context in, summarized result out.
  • The requested workflow is a product/task-management layer around that primitive: child tasks that are visible, resumable, linkable from the parent, and able to hand back structured summaries without the parent ingesting the full transcript.

So I think spawn_agent could be the right underlying mechanism, but the missing piece is first-class parent/child task orchestration:

  1. Create or link a child task from a parent task.
  2. Let the child task support normal multi-turn user collaboration.
  3. Keep the child transcript isolated from the parent context.
  4. On checkpoint/completion, generate a structured handoff back to the parent.
  5. Show child task status/artifacts/decisions from the parent task.

If this is already possible through spawn_agent options or existing Codex UI/CLI affordances, a short example would be very helpful. The key need is not just parallel execution, but durable, reviewable subtask conversations with summarized parent handoff.

alchemistklk · 1 month ago

I have been exercising this parent/child-task workflow in Codex Desktop and
published a small, runnable reference implementation:

https://github.com/alchemistklk/caprika-agent-lab/tree/main/skills/issue-to-thread

It uses a two-stage model:

  1. to-issues turns an approved plan into reviewed vertical-slice issues.
  2. issue-to-thread assigns exactly one approved issue to a clean child task

with a bounded execution brief and a structured closeout callback.

The skill is intentionally not a replacement for native Codex task tooling.
It leaves task creation, messaging, naming, and archiving to Codex. Its small
local script only validates deterministic parts of the contract. Building it
made the product gaps in this issue concrete.

The recurring failure modes are:

  • Parent identity is not a durable contract. A child can receive a

delegation source ID, but the parent handle is not an explicit field that a
workflow can reliably validate and target for its closeout callback.

  • Callback delivery is prompt-dependent. The child needs a native,

acknowledged structured callback rather than an instruction that it may
forget to follow.

  • Execution and delivery get conflated. A child can change files and pass

all required validation while its sandbox makes .git read-only. It should
report execution=done, validation=passed, and
delivery=parent-action-required, not incorrectly report blocked.

  • Task titles are not stable. A requested child title can be overwritten by

later automatic naming, which weakens both routing and lifecycle visibility.

One possible native shape would be an issue-backed child-task creation flow
with explicit fields such as:

parent_thread_id
issue_ref
title
execution_brief
callback_schema
delivery_contract { commit_owner, git_capability }

At closeout, the app could expose a typed result instead of only prose:

execution: done | blocked | scope-change
validation: passed | partial | failed | not-run
delivery: committed | parent-action-required | user-action-required | not-required
archive: ready-to-archive | keep-active | archive-after-parent-action

The parent would then receive an acknowledged callback, see the child's actual
sandbox capability (including .git), and decide any remaining commit, review,
merge, or archive action. That preserves the isolation and durable task model
proposed here while removing the fragile parts that currently have to live in
prompts and local conventions.

The public skill includes the brief template and a zero-dependency validator:
https://github.com/alchemistklk/caprika-agent-lab/blob/main/skills/issue-to-thread/SKILL.md