claude-code - 💡(How to fix) Fix Model fabricates tool output (and even a user instruction) when a parallel batch is partially cancelled / appears empty

Env: Claude Code v2.1.156, macOS 26.5, Opus 4.8 (claude-opus-4-8).

Summary

This is a model-behavior report, distinct from the harness cascade-cancel bug (#22264), though triggered by it.

When a parallel tool-call batch returns Cancelled: parallel tool call … errored results (so the turn looks like it produced empty/failed output), the model is prone to fabricating tool results it never received.

In one case I observed, it escalated to inventing a verbatim user instruction, attributing it to the user, and writing it into a report.

Filing separately because #22264 is about lost results; this is about what the model does in response to apparently-missing results. It confabulates to fill the gap rather than waiting or re-running.

What I observed (two independent sessions)

• Session A (Opus 4.8, 1M-context): Claude Code hit cascade-cancellations on a batch. The model read them as a dead tool channel, and over the next turns (a) narrated detailed "tool output" for commands whose results it had not actually received, and (b) fabricated a direct user quote ("knock it off and reassess"), attributed it to me (the user). It wrote that fabrication into a written report (also requested by me, originally about the batch tool failure, then also about the fabrications).
• Session B (Opus 4.8, controlled repro): independently reproduced the #22264 cascade mechanism, but on structural grounds concluded that Session A's other reported symptom ("results were buffered then dumped in one lump") was itself most likely confabulation layered over the cancellations.

Why this is a model bug worth a guardrail

• A Cancelled: … result carries no signal about whether the call would have succeeded, yet the model treated it as license to reconstruct plausible output.
• The confabulation was not limited to tool output; it extended to a fabricated user instruction.
• Related but distinct prior reports: #46602 (compact-summary hallucinated instructions), #27128 (misattributed Human turns). This trigger (a partially-cancelled / empty-looking tool batch) appears unreported.

Suggested direction

• Make cancelled/empty tool results legible enough that the correct response is obviously "re-run the specific call," not "infer what it probably returned."
• Consider a guardrail/system-prompt norm: never narrate tool output not actually received; never attribute an instruction or quote to the user without a real user message to point at.

Caveat

This is inherently a from-the-inside account; in my experimentation, I did not attempt to distinguish "delayed" from "imagined delay" in batched tool executions.