Summary

When a subagent session dies mid-run (OOM kill, SIGUSR1 restart, or abrupt failed exit), its active child sub-subagent sessions receive no termination signal. Children sit in `stale_running` indefinitely — the gateway marks them "running" but no agent polls them and they never complete. Only manual cancellation or `openclaw maintenance --apply` cleans them up.

Steps to Reproduce

1. Spawn a depth-1 subagent via `sessions_spawn`
2. From the depth-1 session, spawn a depth-2 sub-subagent via `sessions_spawn`
3. Kill the depth-1 parent session abruptly (e.g., `SIGUSR1` to gateway, OOM kill, or `openclaw sessions kill`)
4. Observe: the depth-2 child remains in `stale_running` forever

Expected Behavior

When a parent session dies, all its descendant sessions should either:

• Receive a termination signal and clean up gracefully, OR
• Be listed as orphaned and eligible for automatic cleanup

Actual Behavior

Depth-2 children become orphaned with no lineage connection to a living agent. Gateway shows them as `running` but they are never polled again. `openclaw tasks audit` reports `stale_running` indefinitely.

Version

```
OpenClaw 2026.5.3-1 (2eae30e)
```

OS: Linux 6.8.0-110-generic (x64)

Evidence

Live task IDs from a production instance (anonymized session keys):

`openclaw tasks audit` output:

Task  error  stale_running  109245ed-...  running  1d17h
Task  error  stale_running  6737bbde-...  running  1d17h
[...4 more...]

Impact

• Orphaned tasks accumulate in gateway task registry
• `stale_running` errors trigger automated alerting noise
• Manual cleanup required to recover
• Makes depth-2 subagent spawning unsafe in production

Severity

High — reliability/usability of multi-agent orchestration.

Proposed Fix (direction, not prescriptive)

Option A: Gateway tracks parent→child registry; on parent death, iterate children and send termination signal or mark them `orphaned`.

Option B: Subagent children monitor parent session heartbeat; if parent goes dark for N consecutive heartbeats, child self-terminates with a defined exit state.

Either approach closes the lifecycle management gap without changing the spawn permission model.

Related Issues

See also:

• Feature: First-class session/task chain tracking (parent/root/trace/depth) #11040 (Feature: First-class session/task chain tracking) — related to lineage tracking, does not address death-signal propagation
• Normal sessions can inherit stale subagent lineage and incorrectly hit sessions_spawn depth limits #67943 (Normal sessions can inherit stale subagent lineage) — lineage staleness, different root cause