[BUG] Remote Control (Linux CLI daemon): finished --print child sessions are never reaped, causing unbounded RAM growth

Environment

• Claude Code 2.1.204 (CLI), running as a persistent claude remote-control --name <redacted> daemon via ttyd+tmux
• Debian 12 (bookworm) container on a Linux 6.12 host (TrueNAS), x86_64
• Not via Desktop App; long-running headless CLI daemon on a home server

Problem

The remote-control daemon spawns one claude --print --sdk-url ... --session-id ... child process per task/turn. These are meant to run once and exit, but a growing number never terminate — they idle forever as live (not zombie) direct children of the still-running daemon (confirmed same PPID via ps -ef --forest, i.e. never reparented to init, so not classic orphans — they're leaked live children the daemon lost track of).

Diagnosed 2026-07-17 after a monitoring tool flagged Claude Code consuming RAM while "idle": found 26 such stuck --print children, some up to a week old, ~5.2GB RSS combined. This fully exhausted 8GB of swap on the host and degraded unrelated services.

Root cause (suspected)

Bug in the remote-control daemon's child-process reaping — it isn't waiting on/terminating --print children after their task completes.

Reproduction

1. Run claude remote-control --name X as a long-lived daemon (days, not hours).
2. Drive many tasks/turns through it over that period (mobile app or claude.ai/code client).
3. Periodically inspect ps -ef --forest | grep -- '--print.*--sdk-url' under the daemon's PID.
4. Observe the count of --print children grows and does not shrink even long after their corresponding tasks/turns have visibly completed in the client.

Impact

Unbounded RAM/swap growth on the host over days, eventually degrading or starving unrelated processes on the same machine. No user-facing indication that this is happening — it's only visible via OS-level process inspection.

Workaround (ours, not a fix)

A cron-based watchdog that only kills --print children that are (a) 24h+ old AND (b) show zero CPU-time growth across 2 consecutive hourly samples, always excluding the single newest matching PID. This is conservative because a genuinely-stuck orphan and a legitimately-idle-between-turns live session are indistinguishable in a single process snapshot.

Requested behavior

The remote-control daemon should reap (wait on/terminate) --print children once their task/turn has actually completed, rather than leaving them running indefinitely.