[BUG] Subagent report truncated at ~2.5k chars when flagged 'instruction-shaped pattern'; the suggested SendMessage resend re-runs the agent at full cost and truncates again

Independent reproduction on a different platform, with measurements that I think refine the diagnosis in a useful way.

Environment: macOS (Darwin 25.6.0), Claude Code 2.1.259, Agent Teams with backendType: in-process teammates spawned from an interactive lead session. Original report was WSL2 / 2.1.251, so this is not platform- or version-specific.

The cap is 4,064 characters, and it is not the flagged path

I swept every idle_notification in three affected session transcripts: 21 results total, 8 truncated. Every truncated one is exactly 4,064 characters, and the split by harness prefix is the interesting part:

| | Count | Length |
|---|---|---|
| Truncated, with [harness: ...instruction-shaped pattern] prefix | 2 | 4064 |
| Truncated, no harness prefix at all | 6 | 4064 |
| Not truncated | 13 | max 3369, median 2163 |

So the report's hypothesis that "the cap appears to be on the neutralized/flagged path ... not a general result-size limit" does not hold — three-quarters of my truncations were never flagged. It's a flat cap on idle_notification.result regardless of content.

I suspect the original ~2,500 figure and my 4,064 are the same ceiling measured differently: the harness prefix is ~330 characters, and the < → <\ neutralization inflates stored length relative to visible length, so ~2.5k of visible report can plausibly occupy the full 4,064 of stored result. That's inference, not something I verified. The unflagged 6 give a clean read of the cap.

The non-truncated control in the original report was very likely just short rather than exempt — my own untruncated max is 3,369, comfortably under the cap with nothing to cut.

Raising the cap would not fix this

Three reasons, in increasing order of how much they matter:

1. Doubling it demonstrably wouldn't have helped. Three of my five agents truncated twice — the initial result and the tail they sent when the lead asked for it. Both hits landed at 4,064. Their full results therefore exceed 8,128 characters; that's a measured floor, not an estimate.

2. There's a second ceiling behind the first. The 2.1.259 binary carries applyAggregateIdleResultBudget and per_frame_truncated alongside the per-frame path, implying an aggregate pool shared across idle results in addition to the per-frame cap. My failure pattern is three research agents returning near-simultaneously, which is exactly what an aggregate budget would throttle. I have the symbol names, not the values.

3. The structural reason. These were summaries of research documents the agents had written to disk — 42KB, 50KB, and 56KB. When an agent is told completeness matters more than brevity, its summary length is unbounded relative to any fixed cap. A larger cap makes truncation rarer and therefore more surprising when it hits, which is worse for the operator: at a 100% failure rate on long-form agents you at least learn to expect it.

There also appears to be no operator-visible knob — I enumerated the CLAUDE_CODE_* env vars in the binary and checked the settings reference. The internal name is maxResultSizeChars, a parameter rather than a configuration key. So "just raise it" isn't available downstream even as a stopgap.

The spill mechanism already exists in the same session

This is the part I'd most like to add to the original report. Claude Code already spills oversized payloads to disk and hands back a path — it just doesn't do it on this code path. From a session that also suffered the truncation:

Output too large (56.7KB). Full output saved to: <session>/tool-results/toolu_01Hx….txt

I count 66 such tool-results/*.txt spills on this machine. So a large tool result takes the lossless path and a large teammate result takes the lossy one, in the same harness, in the same session, sometimes minutes apart. That reframes the fix from "please build a spill mechanism" to "please point the mailbox at the one you shipped": write idle_notification.result to tool-results/ when it exceeds the cap and put the path in the notification, exactly as <persisted-output> already does.

The recovery path is worse than the report states

Two compounding costs on the suggested SendMessage re-ask:

• Per #80489, messaging a running subagent re-injects its full frontmatter and skills: bodies.
• The re-ask resumes the agent on its full transcript.

So each tail request pays re-injection plus a full agent resume — to retrieve text that, in my case, was already sitting in a 56KB file on disk that the agent had been instructed to write. One of my lead sessions burned six SendMessage round-trips recovering content it could have cat'd, and the operator's report to me was simply "I have no idea what was truncated." The truncation notice actively steers toward the most expensive possible recovery while the cheapest one (read the artifact) goes unmentioned.

Suggested priority

Even ahead of the spill fix, the notice text is a cheap win. [result truncated — ask the agent for the rest via SendMessage] recommends the one action that costs the most and, per this report and mine, doesn't work. Stating the actual byte limit, or saying nothing at all, would leave operators better off than the current recommendation does.

Reproduced on 2.1.259 (Linux), with one addition to the numbers: the cap is on the idle_notification.result field itself and is exactly 4000 characters. The "instruction-shaped pattern" prefix is not what
triggers it — the prefix just spends part of the same 4000-char budget, which is why a flagged report looks cut at ~2.5k.

Controlled repro (no tools, no flagged content):

1. Spawn two general-purpose agents (model haiku) with the identical prompt: "reply with 120 lines, each LINE-NNN + 60 letters, nothing else" (~8.4k chars).
2. Give one of them a name; leave the other unnamed.
3. The named agent's result arrives as a teammate idle_notification and ends after 57 full lines + 10 characters = 4000 chars, followed by [result truncated — ask the agent for the rest via SendMessage].
4. The unnamed agent runs as a plain background task and its full 8.4k result arrives intact in the task-notification.

So the limit lives in the teammate/mailbox delivery channel (the one 2.1.251's "teammate's final answer now arrives in the idle notification" fix introduced), not in the model output or the agent prompt. Same
session, same model, same prompt — only name differs.

Also confirming the cost problem from the report: asking a named agent for "the rest" via SendMessage resumes it on its full transcript, and the resend is cut at the same 4000 chars. Recovering one ~9k-char
research report took three round trips, and the second resend was truncated again.

Workaround that works reliably: don't pass name unless you actually need to message the agent later, and have every agent write its full report to a file and return only a short summary plus the path.

Thank you @DRON4eg and @bdmorin for further checks and context!