Workflow tool: full script re-executions discard completed agent() results; resumeFromRunId never hits the journal cache (severe token waste)

Workflow tool: repeated full script re-executions discard completed agent results; resumeFromRunId cache never hits — ~50% of session usage consumed redundantly

Environment

• Claude Code 2.1.211, macOS (darwin 25.1.0), background session launched from claude.ai/code
• Session: session_018jZgHw8xztWCsA3EUKDUqZ
• Workflow run ID: wf_3efc2ffe-95c

Summary

A Workflow run (7 parallel agent() finders feeding later phases) was silently re-executed from the top three times by the harness. Each re-execution spawned all 7 finder agents again from scratch, including finders whose results were already recorded in the run's journal.jsonl. An explicit stop + resumeFromRunId relaunch — done exactly as the tool documentation prescribes — also re-ran all 7 agents live with zero cache hits, despite the journal containing completed results for 5 of the 7 keys.

Net effect: 28 agent spawns (74 MB of transcripts) to obtain what 7 agents should have produced. The finder agents each read multi-hundred-page spec PDFs, so every redundant wave is expensive. The user lost roughly half of their session usage allowance to work that had already completed.

Timeline (all times 2026-07-16, CEST, from file mtimes and journal order)

• 19:17 — wave 1: 7 finders spawn. 2 complete and journal result entries.
• ~19:30 — full script re-execution (wave 2): all 7 keys re-spawn with fresh agentIds — including the 2 already-completed keys. 5 keys total now have result entries in the journal.
• 19:52 — full script re-execution (wave 3): all 7 keys re-spawn again. The 5 completed results in the journal are ignored; no cached returns are journaled.
• ~20:03 — operator intervention: TaskStop on the run, then Workflow({scriptPath, resumeFromRunId: "wf_3efc2ffe-95c"}). Journal shows 7 fresh started entries; all 7 transcripts grow to 90–240 KB within 2 minutes with no cached result entries for the 5 completed keys. Run stopped again to halt the waste.

Issue 1 — harness-level script re-execution ignores the run's own journal

Whatever triggers the internal full-script retry (the earliest wave showed simultaneous first-attempt failures across all 7 agents, consistent with a transient API error wave), the re-execution does not consult the run's own journal, so every completed agent() result is discarded and recomputed. For fan-out workflows this multiplies cost by the number of restarts.

Issue 2 — resumeFromRunId prefix semantics defeat the documented purpose

The tool docs state: "Completed agent() calls with unchanged (prompt, opts) return their cached results instantly." In practice the cache appears to be matched as a positional prefix: because the first agent() call in the parallel() batch had no completed result, the entire batch — including 5 keys whose v2:<hash> content-addressed results sit in the journal — re-ran live. For any parallel fan-out where an early-indexed item is the one that failed, resume recovers nothing while spending a full wave.

Evidence available on request

• journal.jsonl for wf_3efc2ffe-95c: 36 entries — 28 started (4 × 7 keys) vs 8 result entries covering only 5 distinct keys.
• 28 agent transcript files (74 MB) timestamped in four distinct waves (19:17, 19:30, 19:52, 20:03).

Expected behavior

1. Internal script re-execution should replay completed agent() calls from the run journal instead of re-spawning them.
2. resumeFromRunId should return cached results for every completed (prompt, opts) key regardless of position, exactly as documented.

Request

• Fix both behaviors (or document the prefix limitation prominently and make internal retries journal-aware).
• The consumed usage was overwhelmingly redundant re-computation caused by the harness, not by user-requested work; requesting usage restitution for the affected session.