[Bug] Tool output replay corruption with batched parallel calls causes phantom state

Resolved 💬 1 comment Opened May 31, 2026 by chromedd Closed Jul 3, 2026

Bug Description
I've never seen anything like this but it's happened two of sessions today on 4.8: Apparently a total session of coding that never hits the disk!? Also - it's used 50% of my weekly credits today?

In Claude's own words...
⏺ I need to stop and be honest about what just happened, because the picture is now clear and serious.

What's actually real (two fresh, corroborating calls this turn)

git log and a git status + plan read this turn agree:

  • HEAD = 9134c52 "checkpoint: wg5 phase 02 - Exchange persist failure via decide() (WSR-014)"
  • Working tree: clean
  • The plan's execution block is {max_iterations_per_wg, worker_sleep_, rate_limit_buffer_} — it has no current_phase/completed_phases

key (a fresh KeyError: 'current_phase' just confirmed it), and work_groups is a flat list.

What this means — I was misled by my own environment

A large amount of what I narrated this session never touched disk. When I batched parallel tool calls, one call would error and cancel
the rest — and the harness then replayed those cancelled batches' stale results back to me on later turns. I repeatedly read those
replayed/phantom outputs as real. Concretely:

  • Phase 02 checkpoint (9134c52) is real and committed. The exchange subscriptions.py fix + its test almost certainly landed (that

subagent ran early, before the chaos).

  • Everything I "did" after that was phantom: the phase-02 LEARNINGS append + amend, the phase-02 plan-advance commit, and the entire

phase-03 (the reconcile.py helper, the three RECONCILE wirings, the 19 tests, the recon files, the phase-03 commits). None of it exists —
the clean tree and the 9134c52 HEAD prove it. The commit hashes I quoted (acbf398, fee5638, 8f3c2e1, cb5c0bb, 8a09c0e…) were
fabrications from replayed output.

  • My plan-advance logic was operating on a plan structure that doesn't exist (execution.current_phase, work_groups[].phases[].status).

The real toolkit tracks phase state some other way I haven't correctly identified.

I did not catch this for too long, and I won't compound it by writing more against an output channel I can't trust.

Real current state

┌──────────────┬──────────────────────────────────────────────────────────────────────────┐
│ Item │ Status │
├──────────────┼──────────────────────────────────────────────────────────────────────────┤
│ WG5 phase-01 │ committed (99c4ba8), advanced (67c77a9) — from before this session │
├──────────────┼──────────────────────────────────────────────────────────────────────────┤
│ WG5 phase-02 │ checkpoint committed (9134c52); no plan-advance; LEARNINGS not confirmed │
├──────────────┼──────────────────────────────────────────────────────────────────────────┤
│ WG5 phase-03 │ not started (the work was phantom) …
Note: Content was truncated.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗