Subagent assistant message content replaced with ~145KB eval fixture (Alice in Wonderland) despite output_tokens: 5

Open 💬 0 comments Opened Jul 14, 2026 by evansrichards

Environment

  • Claude Code version: 2.1.209 (VS Code extension entrypoint, claude-vscode)
  • Platform: macOS (Darwin 25.5.0)
  • Model: claude-opus-4-8[1m] (parent session and subagent)

What happened

I dispatched a background general-purpose subagent via the Agent tool (one of three parallel subagents in an orchestration). This subagent's transcript shows it made zero tool calls. After a 12.5-minute silent gap following its bootstrap, a single assistant record was persisted — and its content is not model output: it is a ~145KB long-context eval fixture (the full text of Alice in Wonderland, wrapped in the harness's large-attachment preamble "The following is data for you to use across the entire chat session…" plus a <system-reminder> block saying "This block of content is the entire book Alice in Wonderland"). That text was then returned to the parent session as the subagent's result via the task-notification.

The core anomaly

The persisted assistant message's own usage accounting contradicts its content:

"usage": {
  "input_tokens": 2,
  "cache_creation_input_tokens": 27862,
  "cache_read_input_tokens": 0,
  "output_tokens": 5,
  "service_tier": "standard",
  "inference_geo": "global"
}

A 5-output-token completion cannot produce ~145KB (~35K tokens) of text. The content field appears to have been populated with foreign document/attachment content rather than the model's actual completion — i.e. response-path corruption or cross-request contamination, possibly related to whatever caused the 12.5-minute hang (retries?).

Ruled out locally

  • The fixture text exists nowhere on the machine outside the two transcripts (subagent JSONL + parent session JSONL via the relayed notification) — no file, plugin, skill, or hook contains it.
  • Both SubagentStart hook attachments in the transcript are benign and verified (a small local style hook).
  • With zero tool calls there was no ingestion vector: the subagent never read a file, ticket, or URL.
  • stop_reason: null, no diagnostics, no error records persisted.

Trace identifiers

  • requestId: req_011Cd2d1iRWATRdhqCpnm3DC
  • message id: msg_011Cd2d1jbTKkhGk42iJ1fSN
  • timestamp: 2026-07-14T21:11:55.166Z (request initiated ~20:59:20Z)

Impact

  • The subagent did none of its assigned work (the orchestrator correctly marked it failed), costing a ~13-minute slot in a parallel batch.
  • Trust/safety concern: the substituted content carried instruction-like framing ("data for you to use across the entire chat session", fake <system-reminder>), which a less defensive parent agent could have ingested as context.

Reproduction

Single occurrence; not reproducible on demand. Two sibling subagents dispatched in the same batch with near-identical prompts worked normally.

View original on GitHub ↗