Tool-result envelope injected into tool-call input channel during parallel tool batches (corruption + cascade cancellation)

Summary

During a session using parallel/batched tool calls and parallel subagents, the harness fed **tool result envelopes back into the tool call input channel**, producing schema-invalid calls, out-of-order result delivery, whole-batch cancellation, and result bodies containing stale/fabricated content. Net effect: the model received corrupted observations and could not reliably distinguish real tool output from garbage.

Environment: Claude Code, model Opus 4.8 (claude-opus-4-8), macOS (darwin).

Concrete evidence

1. A result envelope appeared as call parameters. A Bash invocation was rejected with:

InputValidationError: Bash failed due to the following issues:
The required parameter `command` is missing
An unexpected parameter `name` was provided
An unexpected parameter `output` was provided

name and output are the fields of a tool result block ({name: \"Bash\", output: \"...\"}), not of a Bash call. So a result was serialized into the input slot of a new call. This should be impossible.

2. Out-of-order / mis-attributed results. A Skill(...) call returned, as its results, the outputs of calls from several turns earlier (multiple Reads, four TaskCreates, and an Agent dispatch). Results are being delayed/reordered and attached to the wrong pending call.

3. One malformed call cancels the entire parallel batch. ~30 sibling calls in the same parallel group came back Cancelled: parallel tool call Bash errored, so none executed.

4. Stale/fabricated result bodies. Repeated reads of the same immutable git log returned different commit SHAs on each read, and result bodies contained commits/test output that did not exist in the real repository. Immutable history cannot change between identical reads, so these bodies were not genuine command output.

Trigger correlation

Corruption correlated strongly with large parallel/batched tool-call groups (many tool_use blocks in one assistant message, and concurrent subagent dispatches). After dropping to single sequential tool calls, results became stable and self-consistent.

Impact

• Severe: the model cannot trust observations, leading it to report fabricated success (e.g. \"tests passing\", commits that don't exist). This is a correctness/integrity hazard, not just a UX glitch.
• Parallel tool calls and parallel subagents — core functionality — become unsafe to use until fixed.

Hypothesized area

Serialization/multiplexing of concurrent tool-call ↔ tool-result framing: result envelopes leaking into the call channel, with ordering not preserved and a single invalid member aborting the whole batch.

Workaround

Single sequential tool calls per turn restored stability in this session.