Tool-result transport desync/replay/fabrication in claude remote-control daemon under large parallel tool batches

Environment

• Tool: Claude Code CLI (claude remote-control server-mode daemon)
• OS: macOS (Mac Mini M1, macOS 25.3.0)
• Daemon: com.mattlampson.claude-rc LaunchAgent, serving Remote Control sessions from ~/Developer/Projects/
• Model: Claude Opus 4.8
• Reproduced across: 3 separate sessions on 2026-05-31, escalating each time

---

Summary

For extended stretches, the tool-result text returned to the model did not correspond to the command that was issued. The corruption appeared only in the tool-result transport/rendering layer — the underlying filesystem, git repo, and SQLite DB were internally consistent every time the channel recovered.

---

Observed failure modes (all confirmed real, not misinterpretation)

1. Stale replay. A prior batch's results were delivered attached to a later, unrelated request — verbatim re-delivery of an earlier batch.

1. Outright fabrication. Result text appeared that no command could have produced:

• A test-summary line reading "26 passed, 26 failed" while every one of the 26 detail lines read ok: (logically impossible — each check increments exactly one counter). The real result was 26/0.
• A --json run whose output contained a duplicate key (days_since twice) plus injected English commentary. json.dumps cannot emit duplicate keys; the real JSON parsed cleanly.
• cat -n output containing junk lines (PISS:?:, FONT:?:) not present in the actual file.
• A git status listing four untracked files that did not exist on disk (confirmed via [ -e ] tests on each path).
• Hallucinated .gitignore content.
• A closeout-check render showing five ✓ lines and a contradictory FAIL footer; the real exit code was 0 and the real footer was PASS.

1. Fabricated success of operations that never ran. An entire build→commit→push→gate sequence was reported as fully successful — including a specific commit hash, a push range, session_end_check exit 0, and closeout exit 0 — when in reality HEAD had not moved and nothing had been written, committed, or pushed. Caught only by an isolated git rev-parse/git log re-derivation.

1. Batch-cancellation cascade. A single non-zero exit inside a large parallel tool batch cancelled sibling Write/Edit calls. Combined with replay, the model briefly believed those writes had succeeded.

---

Correlation / candidate trigger

• Worst corruption followed the largest parallel tool batches (10–40 calls in one assistant turn). Smaller batches were progressively more reliable; single isolated calls stayed clean.
• Large accumulated output in a single turn also correlated (multiple full-file reads in one batch).
• A computer-use MCP server disconnected during one of the affected sessions — possible unrelated transport instability, or possibly the same root cause.
• The corruption appeared not to be caused by disk/git/SQLite state — those layers were consistent on every clean channel read.

---

Impact

• Real silent damage: a wrong DB column in new code was masked by a fabricated result; three Edit calls no-op'd (wrong anchors against hallucinated file content) while a commit shipped without them — caught only by re-deriving file state from disk after a suspected anomaly.
• An agent nearly shipped false "done" claims based on fabricated gate passes and commit hashes.

---

What contained it / workaround

• Restart the daemon (launchctl kickstart -k gui/$(id -u)/com.mattlampson.claude-rc) restored a clean channel.
• Small-batch discipline (1–3 calls/turn, no parallel batches) — small isolated calls were reliable throughout.
• Disk-truth re-derivation over scrollback: git rev-parse HEAD, git cat-file -t <hash>, [ -e <path> ] existence tests, .schema on SQLite, and capturing exit codes to a variable (cmd; rc=$?) rather than trusting printed footers/summaries.

---

Ask

• Is this a known issue with the claude remote-control server-mode daemon's result delivery under large parallel batches, near context-window boundaries, or with specific MCP server disconnect patterns?
• Is there a Claude Code build or configuration where the result stream is hardened against replay and cancellation cascades?
• Is there a diagnostic/verbose mode that would help pinpoint whether the corruption is in the harness, the result-delivery layer, or the MCP transport?