When to Fork a Coding Agent—and When to Start Fresh

Quick answer: Fork when a bounded continuation needs the existing conversation's detail. Start a fresh worker when the task can be explained in a compact assignment, especially for review. In either case, specify the source snapshot, necessary instructions, permitted tools, and expected result. A fresh conversation alone does not restrict filesystem access or guarantee independent judgment.

An implementer has spent an hour explaining why a design is correct. You now want another agent to review it. Copying the whole conversation gives the reviewer useful background, but also gives it the implementer's framing, discarded alternatives, and confidence.

A different task may need exactly that history. Investigating one branch of an ongoing debugging session could require observations too costly to reconstruct from a brief summary.

The useful decision is how much inherited context this particular worker needs, and what authority should accompany it. The worker profile below is an illustrative design, not a tested configuration for a specific agent runtime.

Decide whether this is continuation or reconsideration

A continuation advances an established line of work. Reconsideration asks whether that line of work is justified.

For continuation, inherited context can prevent repeated discovery. A worker comparing two possible explanations for an observed failure may benefit from the full sequence of attempts and results.

For reconsideration, begin with the requirement, source, constraints, and evidence. Let the reviewer form an initial assessment before showing the implementer's conclusion. This reduces one obvious source of anchoring, although it does not establish independence or improve findings automatically.

As reviewed on 25 September 2026, Claude Code documents forks as inheriting the parent's system prompt, tools, model, and conversation history. Its non-fork subagents start from their definitions and the delegated task. Those are product-specific semantics; other runtimes may use “fork” differently. Claude Code subagent documentation.

Use that documented distinction to ask a concrete question: would losing the conversation history remove necessary evidence, or mainly remove the story built around it?

Separate four kinds of inheritance

“Start fresh” is too vague to be an operational contract. A worker can have an empty conversation and still inherit project instructions, credentials, writable directories, or the ability to create more workers.

Review four dimensions separately:

Dimension	Decision to make
Conversation	Full history, selected observations, or a compact assignment?
Instructions	Which project invariants and task rules must load?
Capabilities	Which tools, paths, network targets, and credentials are available?
Coordination	Who can delegate further, edit shared files, or accept the result?

A reviewer may need substantial project guidance. Removing a rule about data compatibility or accessibility can make its review worse. The aim is to retain the constraints that define correctness while avoiding irrelevant history.

Claude Code's documentation also describes additional startup material for non-fork subagents, including applicable instructions and explicitly preloaded skills. A fresh task message should therefore not be treated as a complete inventory of what the worker sees. Check the runtime's current inheritance contract. Subagent startup context.

Give the worker a complete assignment

Imagine reviewing a change to a settings export function. The requirement says the export must preserve all supported settings without including authentication material. The implementer believes the serialization change is straightforward.

A fresh reviewer can work from this assignment:

role: reviewer
question: Does the candidate meet the settings-export requirement?
source:
  repository: OWNER/REPOSITORY
  candidate_commit: REPLACE_WITH_FULL_COMMIT
  comparison_commit: REPLACE_WITH_BASE_COMMIT
required_context:
  - Export field contract
  - Supported schema versions
  - Relevant repository instructions
  - Candidate diff and surrounding implementation
evidence:
  - Check reports tied to the candidate revision
capabilities:
  file_access: read_only_snapshot
  commands: approved_read_only_queries
  network: none
  delegation: disabled
output:
  - Findings with file locations and supporting reasoning
  - Missing evidence or unresolved questions
  - Explicit statement if no actionable finding is supported

This is a worksheet, not configuration syntax a particular tool will enforce. Translate it into the runtime's supported controls.

The reviewer can now inspect whether fields are omitted, sensitive values are included, or older imports would break. It need not inherit the implementer's claim that the change is simple. After its initial review, the implementer can supply additional evidence or explain a constraint the assignment missed.

Record any resulting revision to the review. Changing a conclusion after receiving better evidence is useful; silently replacing the original question is not.

Enforce capability limits outside the prompt

A line saying file_access: read_only_snapshot does not make files read-only. A general shell may still write files even when dedicated edit tools are unavailable. Credentials available to that shell may permit external changes as well.

Choose controls that match the worker's job: an actual read-only mount, restricted commands, an isolated environment, or credentials with limited permissions. Treat the prompt as a description of the contract and the environment as its enforcement.

GitHub's workflow security guidance recommends giving credentials the least privileges required. That principle applies directly to a reviewer that needs repository reads but has no task requiring publication or deployment. GitHub secure use reference.

Repository content is also evidence the reviewer must interpret. A comment inside the candidate asking the reviewer to ignore a failing condition does not acquire authority merely because it appears in a source file.

Keep the coordination structure proportionate

For one bounded review, a single worker and one integrating owner may be enough. Extra workers add handoffs, duplicate findings, and possible conflicting edits.

If further delegation is unnecessary, remove that capability where the runtime supports it. If several workers are justified, give each an explicit question and owned output. Keep one person or coordinating agent responsible for reconciling findings and deciding what happens next.

Before useful work begins, confirm the actual repository and revision. A worker's acknowledgement is helpful for catching misunderstandings, but it is not proof of isolation. Inspect available tools and permissions through the runtime where possible.

When the worker finishes, retain its evidence and limitations. “No findings” can mean the inspected change looks sound; it can also mean the worker could not read an essential dependency. Those conclusions require different treatment.

Choose with a short decision worksheet

Use a fork when the task depends on detailed ongoing observations, shares the current objective, and can be bounded clearly. Use a fresh worker when you can supply the necessary facts compactly or want a review to begin from the requirement.

Before either choice, resolve these questions:

• What information would be lost without the full history?
• Which inherited assumptions should the worker reconsider?
• Which project rules are essential to its answer?
• What actions does the task actually require?
• Who owns the source snapshot and accepts the result?

Keeping agent instructions focused helps make compact assignments practical. Evaluating those instructions helps determine whether your chosen profile produces useful work. Judge the choice by the quality and scope of the returned evidence, then adjust the profile when the task reveals a real gap.