[BUG] Background Workflow dies at a session boundary regardless of the user's answer to the compaction prompt ("adopt scriptPath rejected"); the suggested resumeFromRunId then silently re-runs everything
Environment
- Claude Code 2.1.217 (interactive TUI, Max subscription)
- macOS (Darwin 25.5.0), bash
- Workflow launched by a plugin skill via the
Workflowtool as a background task (multi-agent orchestration run, expected duration measured in hours, ~20+ subagents)
Summary
A long-running background Workflow does not survive a session boundary (the process exit / new-session transition that accompanies the compaction prompt). The user's answer to the compaction prompt is irrelevant — in the incident below the user declined compaction with Escape and the workflow was already dead. An adoption mechanism apparently exists (the workflow is "checkpointed for the background fork") but fails ("adopt scriptPath rejected"). The follow-up notification then recommends relaunching with resumeFromRunId, but resume is same-session-only, so following that advice in the new session silently gets zero cache hits and re-runs the entire workflow from the beginning — in our case re-implementing and re-verifying GitHub issues whose work was already merged to the default branch, until we noticed and stopped it manually.
Timeline (2026-07-22, reproducible pattern)
- An interactive session launches a background Workflow (
run ID wf_f007a572-…). It runs fine, dispatching subagents. - The user presses arrow-left to look at the running agents in the agents view.
- The user leaves the agents view (arrow-right or Escape) — and the compaction prompt appears immediately upon exiting the view, every time this pattern has occurred. The user presses Escape (declines compaction).
- The workflow is already dead. Two task notifications arrive in the (new) session:
status: failed— Background workflow "…" was checkpointed for the background fork but could not be resumed (adopt scriptPath rejected).status: stopped— No completion record was found for background workflow "orchestrate" from the previous session. It may have been stopped …, or it may have been running when the previous Claude Code process exited. To pick up where it left off, relaunch withWorkflow({scriptPath, resumeFromRunId: "…"})— completed agent() calls return cached.
- The session ID has changed (the original session's transcript dir and the new one differ), confirming a session boundary.
- Following the notification's advice, the workflow is relaunched with the same
scriptPath, byte-identicalargs, andresumeFromRunId. Because resume is same-session-only, no cached results are found and no warning is emitted: the engine silently starts over, re-implementing from scratch work items that the first run had already completed, independently verified, and merged into the default branch. It was stopped manually mid-way through the second redundant work item.
A previous occurrence of the same pattern (a larger orchestration run, repeated interruption/restart) compounded into 50+ subagents and 50+ git branches, all wasted — the multi-hour, multi-million-token failure mode this report is really about.
Expected behavior
- A background Workflow survives the session boundary: the checkpoint/"background fork" adoption succeeds, or at minimum the workflow keeps running and its completion is delivered to the successor session. The workflow docs promise resumability ("agents that already completed return their cached results, and the rest run live"), which this defeats.
- If adoption cannot succeed, the failure notification must not recommend
resumeFromRunIdacross a session boundary — andresumeFromRunIdwith an unreachable journal should refuse loudly ("no journal for this run ID in this session") instead of silently degrading to a full re-run.
Actual behavior
- Exiting the agents view immediately raises the compaction prompt, and the workflow dies at the accompanying session boundary regardless of the user's compaction choice (declining with Escape does not save it).
adopt scriptPath rejected— the adoption mechanism exists but fails; no way to intervene.- The advertised resume path silently re-executes every agent, including ones whose results were already integrated, with real side effects (duplicate branches, redundant commits) and large token cost.
Related issues
- #65796 — Workflow resume restarts from the beginning after auto-compaction (same silent-re-run mechanism; this report adds that the death precedes the user's compaction answer, the immediate view-exit → compaction-prompt coupling, and the exact
adopt scriptPath rejectedphrase, which appears in no public issue we could find) - #29193 — Background task handles orphaned after context compaction
- #63023 — Background agents silently die on session pause/resume
- #72171 — Orphaned background tasks surface false "no completion record from previous session" events
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗