Fixing Roo Code Subtasks (new_task) That Silently Lose Context When Returning Results to the Parent Task

The Problem

A parent task delegates a chunk of work to a subtask using Roo Code's new_task tool — something like "investigate why the build is failing and report back what you find." The subtask runs, correctly reads several files, identifies the actual root cause, and even explains its reasoning clearly in its own chat transcript before finishing. The parent task resumes afterward, but acts as though almost none of that investigation happened — it might ask a question the subtask already answered, re-read a file the subtask already examined, or proceed with a plan that ignores a constraint the subtask explicitly flagged. Nothing crashed and no error appeared; the parent simply doesn't know what the subtask discovered.

Why It Happens

A subtask is a genuinely separate task with its own isolated context — it doesn't share the parent's conversation at all

Spawning a subtask with new_task doesn't fork the parent's existing context or give the subtask read access to the parent's conversation history; it starts an entirely new task with only the instructions explicitly written into the new_task call as its starting context. Everything the subtask subsequently reads, reasons about, or discovers exists only within that subtask's own isolated run.

The parent only receives whatever the subtask places in its final result — not a transcript or summary of everything it did along the way

When a subtask completes, it returns a single result back to the parent — effectively whatever the subtask chose to write as its concluding message. The parent never sees the subtask's intermediate tool calls, the files it opened, or the reasoning it worked through to get there; if the subtask's final message doesn't explicitly restate a finding, that finding is gone from the parent's perspective the instant the subtask closes, even though it was clearly present somewhere in the subtask's own run.

Vague delegation instructions produce vague final reports, because the subtask has no way to know what detail level the parent actually needs back

An instruction like "investigate the failing build" doesn't tell the subtask what form a useful answer should take — whether the parent needs the exact error message, the specific file and line, a proposed fix, or all three. Left to infer this, a subtask tends to summarize its own work the way a person would summarize a task for themselves, which is often far less structured and far less complete than what the parent actually needs to act on.

The Fix

1. Specify exactly what the subtask must include in its final result when writing the new_task instruction

new_task(
  mode: "debug",
  message: "Investigate why `npm run build` fails. When you finish,
  your final result MUST include, explicitly: (1) the exact error
  message and the file/line it occurs at, (2) the root cause in one
  sentence, (3) the specific fix you'd apply, with a code snippet.
  Do not just describe what you did — state these three things
  directly in your last message."
)

Treating the subtask's final message as a structured deliverable rather than a free-form report — by spelling out precisely which pieces of information the parent needs back, in what form — closes the gap between "the subtask knows the answer" and "the parent receives the answer," since the subtask can only act on an expectation it was actually given.

2. For multi-step investigations, have the subtask build its findings incrementally into a running summary rather than one final recap

new_task(
  mode: "debug",
  message: "... As you investigate, maintain a running 'Findings so far'
  list in your own messages, and copy that full list verbatim into your
  final result before finishing — don't just reference that you found things earlier."
)

A subtask that only reconstructs a summary from memory at the very end tends to lose earlier details to the same kind of context pressure any long task faces; explicitly maintaining and then verbatim-copying a running list avoids relying on an end-of-task recollection that may already have compressed away specifics that mattered.

3. For results the parent must act on precisely, have the subtask write findings to a file instead of relying purely on the returned message

new_task(
  mode: "debug",
  message: "... Write your full findings, including exact error text,
  file paths, and line numbers, to `debug-findings.md` in the project
  root, in addition to summarizing them in your final result."
)

A file on disk is visible to the parent task directly — it can read it with its own read_file call rather than depending entirely on how faithfully the subtask's final message captured everything, giving a durable, independently verifiable record of the investigation that survives even if the returned summary turns out to be incomplete.

4. After a subtask returns, have the parent explicitly restate what it learned before proceeding, as a check on whether the handoff actually worked

Before continuing, summarize in one or two sentences what the subtask
found and how it changes the plan — if nothing meaningful can be
summarized, the subtask's result was likely too thin, and it's worth
re-running it with a more specific final-result requirement.

This acts as a deliberate checkpoint rather than an automatic one: if the parent genuinely can't restate anything concrete the subtask found, that's the signal the delegation instructions need to be more explicit about the final-result format, rather than assuming the handoff worked and proceeding on an incomplete picture.

Why This Works

The subtask was never actually missing the information — it's isolated by design, and the parent only ever receives the one message the subtask hands back at the end. Specifying exactly what that final message must contain, having the subtask track findings incrementally instead of reconstructing them from memory, and backing the handoff with a file when the stakes justify it all address the same root cause: the parent can only know what was explicitly written down for it, not what the subtask merely knew.

Conclusion

A subtask that "loses" its own findings on the way back to the parent task isn't a bug in how new_task passes results — it's the natural consequence of a genuinely isolated subtask summarizing an investigation into a single message, with nothing beyond that message ever reaching the parent. Writing delegation instructions that specify exactly what the final result must include, keeping a running findings list instead of a last-minute recap, and writing to a file for anything the parent must act on precisely turns a vague handoff into one that reliably carries the information across.