Only the **direct child** is reaped (Linux). `PR_SET_PDEATHSIG` — armed via the `setpriv --pdeathsig` helper — delivers `SIGKILL` to the immediate child when its parent dies, but the parent-death signal is **not inherited** across a `fork`: a grandchild the child forks has its own (unset) parent-death signal, so once the child's parent is gone nothing reaps the grandchildren's cgroup/pgroup. A parent that dies before the signal is armed is covered by the child's own captured-spawner check instead, which terminates it rather than letting it run. See `Command.KillOnParentDeath` for the further caveats (the set-uid/set-gid `execve` reset, and the spawning-thread lifetime note).

**Nothing** is reaped on sudden parent death (macOS/BSD). There is no `PR_SET_PDEATHSIG` analog, so `Command.KillOnParentDeath()` is refused with a typed `ProcessError.Unsupported` on the POSIX spawn path rather than silently pretending the cleanup will happen.

The **whole process tree** is reaped on sudden parent death (Windows). Every child ProcessKit starts lives inside a Job Object created with `KILL_ON_JOB_CLOSE`, and the parent process owns the only handle to that Job. When the parent terminates for *any* reason, the kernel closes its handles as part of process rundown; closing the last Job handle terminates every process in the Job. So the guarantee already holds tree-wide and unconditionally — `KillOnParentDeath()` needs no extra action on Windows.