[Feature] Subagent's TaskOutput should return final result text, not full JSONL log

Ah are subagents getting the ENTIRE jsonl log?!? That would explain the issue!!

What makes this... Interesting... Is that I can kinda see how they may have accidentally gotten to this with a design choice and then a bug in the implementation. I've been quite impressed with how well opus understands the progress of subagents, before today's update I was watching my consolidation subagent examine the progress of background subagents and doing a kind of round robbin polling by seeing how far along each was.

What makes it doubly interesting is watching it awkwardly, but successfully, workaround the bug immediately:

!Image

Same here. Now the sub-agent's outputs exceed normal token limits, which seems... less than ideal? 😂

<img width="959" height="189" alt="Image" src="https://github.com/user-attachments/assets/a652a95e-b8da-4949-a2ac-aa5f6af21080" />

@kylesnowschwartz:

Same here. Now the sub-agent's outputs exceed normal token limits, which seems... less than ideal? 😂

Yeah, this actually completely breaks several workflows for me. They're mostly custom workflows that I built to work around the limitations of claude code itself. For additional context:

The typical problem I'd face is that launching a swarm of subagents to complete a task might result in as many as 10k+ tokens of response per subagent, and with 18 parallel code review agents, that is larger than the free context window leftover for autocompact. Careful context directives can get it down to a few thousand tokens of responses per subagent, but if you repeat this a few times (I run a review loop of haiku subagents to catch issues probabilistically) you will quickly still fill the context window... when I'd instead rather spend those finite context window tokens on delegating to a fix subagent and also executing the rest of the overall workflow.

Especially with 18 parallel review subagents, they can often find overlapping issues, or ignore instructions to be concise. It takes a TON of directing to get claude to NOT read the outputs of the agents itself as an orchestrator, but I was eventually able to cajole it into ONLY reading the outputs INSIDE my subagent-response-consolidator by using background subagents and really careful structuring of the workflow.

The difference when this is broken is that claude effectively regresses several months on long horizon task completion...

Honestly I'm still to this day surprised that anthropic didn't build subagent response consolidation into claude code directly, this is awfully forseeable!

This issue has been resolved in v2.1.7:

Added inline display of agent's final response in task notifications, making it easier to see results without reading the full transcript file

Now when a background agent completes, the final result is displayed inline in the <result> tag within the task notification, eliminating the need to read the full JSONL transcript or use tail -1 | jq workaround.

Tested and confirmed working. Thanks\!

This issue has been resolved in v2.1.7: > Added inline display of agent's final response in task notifications, making it easier to see results without reading the full transcript file Now when a background agent completes, the final result is displayed inline in the <result> tag within the task notification, eliminating the need to read the full JSONL transcript or use tail -1 | jq workaround. Tested and confirmed working. Thanks!

@Weizhena do you mind elaborating what was resolved and how you tested it? I'm still running into similar problems in v2.1.22. In my case the TaskOutput tool result still contains raw subagent jsonl, flooding the main agent's context (reproduction steps here). It seems to me that the problem is mitigated in that the main agent gets a summary if it waits for the completion notification, but if the main agent decides to monitor the background subagent or block for its completion using TaskOutput the jsonl still leaks.

> This issue has been resolved in v2.1.7: > > Added inline display of agent's final response in task notifications, making it easier to see results without reading the full transcript file > > > Now when a background agent completes, the final result is displayed inline in the <result> tag within the task notification, eliminating the need to read the full JSONL transcript or use tail -1 | jq workaround. > Tested and confirmed working. Thanks! @Weizhena do you mind elaborating what was resolved and how you tested it? I'm still running into similar problems in v2.1.22. In my case the TaskOutput tool result still contains raw subagent jsonl, flooding the main agent's context (reproduction steps here). It seems to me that the problem is mitigated in that the main agent gets a summary if it waits for the completion notification, but if the main agent decides to monitor the background subagent or block for its completion using TaskOutput the jsonl still leaks.

@peterjrichens You're right — I just tested this again on v2.1.25 and can confirm the issue
still exists on the TaskOutput path. Here's what I found:
┌──────────────────────────────────┬─────────────────────────────────────┐
│ Method │ Result │
├──────────────────────────────────┼─────────────────────────────────────┤
│ Wait for completion notification │ Clean <result> tag, no leak │
├──────────────────────────────────┼─────────────────────────────────────┤
│ Use TaskOutput to block/poll │ Raw JSONL transcript floods context │
└──────────────────────────────────┴─────────────────────────────────────┘
Why I didn't encounter this myself:

The reason I said it was "resolved" is that my setup effectively avoids the
TaskOutput path entirely. I use two hooks that force all agents to run in
background and prevent the main agent from polling:

pre-task-run-background.sh (PreToolUse hook on Task) — forces
run_in_background: true on all Task calls (except specific sync agents like
code-reviewer):

#!/bin/bash
INPUT=$(cat)
SUBAGENT_TYPE=$(echo "$INPUT" | jq -r '.tool_input.subagent_type // ""')
SYNC_AGENTS="code-reviewer"

if echo "$SUBAGENT_TYPE" | grep -qE "^($SYNC_AGENTS)$"; then
echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDec
ision":"allow"}}'
else
UPDATED=$(echo "$INPUT" | jq -c '{
hookSpecificOutput: {
hookEventName: "PreToolUse",
permissionDecision: "allow",
updatedInput: (.tool_input + {run_in_background: true})
}
}')
echo "$UPDATED"
fi
exit 0

post-task-usage-tips.sh (PostToolUse hook on Task) — reminds the agent to
wait for the notification instead of polling:

#!/bin/bash
cat << 'EOF'
{
"hookSpecificOutput": {
"hookEventName": "PostToolUse",
"additionalContext": "[Task Tool Post-Reminder] 1. Wait for completion
notification, NO polling/checking! FORBIDDEN before notification:
Bash(tail/cat /tmp/...), TaskOutput. 2. After notification: IF <result> tag
contains complete answer THEN use directly; ELSE tail -1 {output_file} | jq
-r '.message.content[0].text'. 3. resume: use agentId to resume ONLY when
needed to continue same agent."
}
}
EOF
exit 0

With this setup, the flow becomes:

1. All tasks forced to background → agent waits for completion notification

→ gets clean <result> → no JSONL leak

So in my case, the notification path fix from v2.1.7 was sufficient because
I never hit the TaskOutput path. But you're correct that the TaskOutput path
itself is still broken — this is a workaround, not a proper fix. The root
issue (TaskOutput returning raw JSONL instead of a summary) should still be
fixed upstream.

---
Apologies for the premature "resolved" — my hooks masked the underlying
issue.

---

I ran into this issue today and the workaround that Opus suggested was to provide explicit instructions to the orchestrator agent NOT to use the TaskOutput tool and instead to wait patiently for the subagents to return for the block starting with <task-notification>. This made a big difference! When you are problem solving this in your own workflow you can ask Claude Code to find the transcripts for the session in question and determine where the high volume snippets are coming from, then ask Claude to find the patterns, then adjust your prompts/skills accordingly.

Here's the instruction I added that fixed the issue for me:

**CRITICAL - Context preservation:** Background tasks return completion notifications with `<result>` tags containing only the final message. Do NOT call `TaskOutput` to check results. `TaskOutput` returns the full conversation transcript (every tool call, file read, and intermediate message), which wastes massive amounts of context. Wait for each task's completion notification and use the `<result>` tag content directly.

I hit it harder:

- **CRITICAL - Context preservation:** Background tasks return completion
  notifications with `<result>` tags containing only the final message.
  Do NOT call `TaskOutput` to check results. `TaskOutput` returns the full
  conversation transcript (every tool call, file read, and intermediate
  message), which wastes massive amounts of context. After launching a
  background task, **stop and do not make any tool calls to check on it**.
  A `<task-notification>` will arrive automatically when it completes ?
  use that to report the result.

I hit it harder: `` - **CRITICAL - Context preservation:** Background tasks return completion notifications with <result> tags containing only the final message. Do NOT call TaskOutput to check results. TaskOutput returns the full conversation transcript (every tool call, file read, and intermediate message), which wastes massive amounts of context. After launching a background task, **stop and do not make any tool calls to check on it**. A <task-notification> will arrive automatically when it completes ? use that to report the result. ``

The issue with these approaches is that Claude is still Claude, it's gonna ignore it at least 10% of the time.

I found it easier AND more effective to rewrite my workflows to use only foreground subagents and then to return only the briefest summaries in their responses, instead writing their full responses to new files on disk. This pattern turns out to work way better with everything else as it is, since the output files survive compaction, and the orchestrating agent can chain them quite easily.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.