Fork-style subagents that inherit parent context for long-running coding sessions

What variant of Codex are you using?

App+CLI

What feature would you like to see?

Problem

Current subagents behave more like CreateProcess() than fork().

When a subagent is spawned, it often has to:

• Re-read the repository structure
• Reconstruct the current hypotheses
• Rediscover already-established assumptions
• Infer task boundaries and constraints from the prompt alone

This frequently causes subagents to:

• Duplicate exploration already performed by the parent
• Miss implicit assumptions that exist in the parent context
• Investigate the wrong files or hypotheses
• Produce results that are inconsistent with the parent's current mental model

The issue becomes especially noticeable when the parent agent is acting primarily as an orchestrator and delegates implementation details to subagents.

Example

Suppose the parent agent has already established:

• The bug only reproduces on the D3D11 backend.
• The public API cannot be modified.
• Several hypotheses have already been ruled out.
• Certain files are legacy and intentionally out of scope.

A newly spawned subagent typically does not inherit these assumptions reliably and may spend significant effort rediscovering or contradicting them.

Proposed Solution

Introduce a new type of subagent that behaves more like fork():

Parent Context
       │
       ├── Forked Worker A
       ├── Forked Worker B
       └── Forked Worker C

A forked worker would inherit:

• Repository mental map
• Current hypotheses
• Ruled-out paths
• Task boundaries
• Relevant file context
• Previously established assumptions

while maintaining:

• Isolated future context
• Independent reasoning trace
• Independent compaction/summarization

The parent would only receive structured findings/results rather than the entire reasoning history.

Possible API

Pseudo-code:

fork_worker(
    task="Investigate UAV hazard hypothesis",
    inherit_context=True
)

or

fork_worker(
    task="Implement alternative allocator",
    inherit="all"
)

Why this matters

The value of a long-running coding session is often not the raw token history, but the accumulated world model:

• which hypotheses were rejected,
• which files matter,
• which constraints are non-negotiable.

Losing this state on every subagent invocation makes delegation significantly less effective.

This feature would make subagents substantially more useful for:

• large repositories,
• debugging sessions,
• multi-step refactors,
• orchestrator-style workflows,
• hypothesis exploration and parallel implementation strategies.

In practice, this would feel much closer to fork()+return than CreateProcess()+args

Additional information

Motivating use case

This becomes especially useful in very large repositories.

For example, when cleaning up several hundred commits in a repository with millions of lines of code, the parent agent needs to preserve a high-level understanding of:

• the intended final patch series,
• which commits are being rewritten or squashed,
• which conflicts are expected,
• which test failures are historical vs newly introduced,
• which areas of the codebase should not be touched,
• and what cleanup decisions have already been made.

Without subagents, the main context quickly fills with implementation details and has to be compacted repeatedly.

With current subagents, each worker tends to cold-start: it rereads the repo, reconstructs context imperfectly, and may miss assumptions that the parent has already internalized.

What would help is a forked worker model: inherit the parent’s current context/world model, work in an isolated continuation, compact locally if needed, then report back only structured findings or patches.