Subagents (Agent tool, custom types) die silently at startup: no transcript, no error, no log; parent never notified

Status Open
Reported on v2.1.246
Maintainer reply None cached
Activity 0 comments · opened Sep 1, 2026

Summary

Subagents spawned via the Agent tool (custom agent types from .claude/agents/*.md) died silently at startup: the Agent tool returned "Spawned successfully", but the child process exited within seconds-to-minutes, wrote no transcript file, produced no output, sent no failure signal to the orchestrating session, and left no log artifact anywhere. The orchestrator (and the user) only discovered the deaths by noticing the absence of results and checking ps.

Happened 4 out of 4 times over ~5 hours in one session; earlier spawns of the same agent types in the same session had worked normally.

Environment

  • Claude Code 2.1.246, Linux (Pop!_OS 22.04 derivative, kernel 7.0.11-76070011-generic)
  • Long-running interactive session (several days old, compacted once, very large context)
  • Agents involved: two custom types (beads-change-reviewer, write-safety-reviewer, both defined in the project's .claude/agents/, model override opus), spawned as named background subagents

Timeline (all times ET, 2026-09-01)

  1. ~10:19 — two reviewer agents spawned in one message (parallel tool calls). Both report spawned. ListAgents shows them as teammates.
  2. Over the next ~4.5 h: no output, no idle notification, no verdict files. SendMessage status demands are accepted ("Message sent to inbox") but never drain.
  3. ~14:51 — ps shows no process for either agent (a third agent spawned at ~10:14 in the same session is still alive at 5h+). No transcript files for either agent exist under ~/.claude/projects/<project>/ — only the main session's .jsonl.
  4. Both stopped via TaskStop, respawned with fresh prompts → same outcome, faster to confirm this time: processes gone within ~10 min of spawn, no files ever created (the retry prompts required creating an output file as the very first action; it never appeared).

Ruled out

  • Memory / OOM: 101 GiB available at the time; no OOM-killer lines in kernel logs; load ~1.4 on a 32-core host.
  • The agent definitions: identical types + prompts of similar shape ran successfully earlier in the same session (one pair ran 55 min and delivered a full report).
  • Crash artifacts: no *.log under ~/.claude, ~/.cache, or ~/.local/share/claude from the window; nothing in journalctl --user; no core dumps.

Expected

Either the subagent runs, or the orchestrator is told it died. A spawn whose child exits before its first turn should surface as an error (tool result, task notification, or at minimum a log file with the child's stderr).

Actual

"Spawned successfully", then permanent silence. ListAgents continued to list the dead agents as teammates. Messages to them queue forever. Nothing distinguishes a dead agent from a busy one without shelling out to ps.

Impact

The orchestrating session waited hours on reviews that would never arrive (this repeated an earlier incident in the same project where reviewer agents produced no verdicts). Workarounds now in place: require agents to create their output file as their first action, watch for it with a liveness monitor, and fall back to in-session work — but the underlying failure is invisible by design.

Ask

  1. Persist subagent stderr/exit status somewhere inspectable when the child dies before its first API turn.
  2. Surface child death to the parent session (task notification or error), instead of leaving the teammate listed as alive.
  3. If there is an existing log location for this failure mode, document it.

View original on GitHub ↗