[BUG] Post-crash `--resume` sessions dead-ACK new Agent/Task spawns — "now running" but nothing runs and no failure signal ever arrives

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

After a host-machine crash followed by claude --resume, brand-new Agent/Task spawns in the resumed session are accepted and acknowledged ("Spawned successfully… now running") but the executor behind them is dead: nothing actually runs, and no failure signal ever arrives.

Concretely, for every spawn made after the crash-resume:

• No transcript file is ever created under <session>/subagents/ (no agent-*.jsonl).
• No process exists (ps shows no claude child with the agent's --agent-id; a live background agent from a sibling session does show its --agent-id, so the check is sound).
• The per-session tasks directory (~/.claude/tasks/session-<id>/) is empty.
• Each agent's inbox file (~/.claude/teams/session-<id>/inboxes/<name>.json) is created but holds the original spawn prompt, unconsumed — the executor never reads it.
• No idle notification, no completion notification, no error ever fires. The tool result is a false positive: it claims "now running" while the executor is dead.
• SendMessage nudges to the agent's inbox append to the same file and are likewise never consumed.

The orchestrator therefore believes work is parallelized when nothing is running. Recovery required manual filesystem forensics (comparing transcript mtimes against spawn times) and redoing all the work inline.

Two independent, reproducible occurrences — one where the spawns were 2 sonnet researchers + 2 opus fixers + 1 sonnet liveness probe, another where 8 parallel general-purpose agents were spawned. Both sessions were confirmed running under --resume via ps.

The documented liveness-probe workaround does not help, because the probe spawn is subject to the identical failure: a trivial haiku probe spawn also ACKed "now running" and produced no process/transcript within 20s, its inbox file created and never consumed.

What Should Happen?

An Agent/Task spawn should either genuinely start or fail loudly. Specifically:

• The spawn should verify the executor actually started — e.g. a first heartbeat / transcript-open within N seconds — and return an error to the caller if it doesn't, rather than a success ACK.
• After a crash-resume, if the spawn executor / teammate substrate cannot be reconstituted, spawns should be rejected with an actionable error instead of silently accepted into a dead executor.
• At minimum, a cheap, reliable liveness-probe API (one not subject to the same dead-ACK) so a caller can detect the dead-executor state programmatically.

Error Messages/Logs

No error is ever emitted — that is the core of the bug.

Spawn tool result (false positive):
  "Spawned successfully. Agent <name> is now running…"

Post-hoc evidence that nothing ran:
  $ find <session>/subagents -name 'agent-*.jsonl' -newermt '<spawn time>'
  (empty — no transcript created)

  $ ps ...                # no claude process carrying the agent's --agent-id
  $ ls ~/.claude/tasks/session-<id>/          # empty
  $ cat ~/.claude/teams/session-<id>/inboxes/<name>.json
  (still contains the original, unconsumed spawn prompt)

Steps to Reproduce

1. Start a Claude Code session in a directory. Spawn one or more background agents via the Agent/Task tool and confirm they run normally (transcripts created, notifications fire).
2. Crash the host machine (hard power loss / OS crash) while the session is live.
3. Reboot and claude --resume <session-id> to continue the session.
4. From the resumed session, spawn one or more agents via the Agent/Task tool (any model; run_in_background true or false). Each ACKs "Spawned successfully… now running".
5. Wait. Observe that: no agent-*.jsonl transcript is created, no process appears in ps, ~/.claude/tasks/session-<id>/ stays empty, and each agent's ~/.claude/teams/session-<id>/inboxes/<name>.json retains the unconsumed spawn prompt. No idle/completion/error notification ever arrives.
6. Confirm a fresh cheap probe spawn (e.g. a trivial haiku agent) exhibits the same dead-ACK — so the "spawn a cheap probe to check liveness" workaround does not detect the state.

Contrast: spawns made before the crash in the same session behaved correctly — transcripts were created and, when an agent died (e.g. to a quota limit), an idle notification fired. Only post-crash-resume spawns are phantom.

Claude Model

Multiple models — reproduced with sonnet, opus, and haiku agents, and with general-purpose agents.

Is this a regression?

I don't know

Last Working Version

Not established — within a single session, pre-crash spawns work and post-crash-resume spawns do not, so it is not clearly a version regression.

Claude Code Version

2.1.217 (Claude Code); also observed on 2.1.214.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Non-interactive / headless (claude -p and interactive resume both affected)

Additional Information

Reliable post-hoc phantom detector: the pair "inbox files created but unconsumed" + "empty per-session tasks directory" (~/.claude/tasks/session-<id>/) is a cheaper and more reliable signal of the dead-executor state than transcript-mtime forensics. A programmatic check on those two conditions could power the "verify the executor actually started" behavior requested above.

Workaround in use: bypass the spawn substrate entirely for the remainder of the resumed session — drive headless claude -p subprocesses via the shell instead of Agent/Task spawns.

Related (resume + background-subagent substrate cluster, but distinct root causes) — these all concern resumed/completed agents' status, visibility, or wake-on-completion, whereas this report is about brand-new spawns in a crash-resumed session dead-ACKing with no failure signal:

• #77510 — resumed background subagent stays marked Completed (display/state only; the agent does run).
• #73095 — SendMessage-resumed background subagent never appears in the background-tasks UI (visibility only; the agent does run).
• #78782 — background Bash task completion never re-invokes an in-process subagent (a wake-on-completion gap, different mechanism).
• #70170 — --resume refuses a session held as a background agent (opposite symptom: an explicit refusal, not a false success ACK).

The unifying theme with those is that the teammate/background-agent substrate does not survive resume cleanly; the unique and most dangerous facet here is that a new spawn returns success while silently doing nothing, violating fail-loud and giving the orchestrator false confidence that parallel work is underway.