The launcher reuses a PERSISTENT container (container_joinable + join), but spawn_init_process forked+execv'd the daemon with no stdio redirect -- so the persistent daemon (and the shellspawn init it spawns) inherited and PINNED the caller's fd-0/1/2. A one-shot `darling <cmd>` therefore printed its output but never returned: the caller's stdout pipe stayed open (held by the persistent daemon) and daemons accumulated (leaked). In the async-signal-safe child, redirect fd-0 <- /dev/null and fd-1/2 -> $prefix/ darlingserver.log before execv (CStrings pre-built before fork). Per-command guest output flows via explicit shellspawn fd-passing, not inheritance, so this is safe; the daemon's readiness sync uses its own high fd (pipefd[1]). Validated against the green .#default install in a CLEAN runtime: `darling shell sh -c 'uname -sm'` prints BOOT=Darwin x86_64 in ~2s, the launcher EXITS CLEANLY (no hang), darlingserver.log is created, and the persistent container is preserved for reuse. (An earlier test appeared to fail only because a stale leaked container from prior testing was being joined instead of spawning fresh.) Fixes the teardown-gap half of #66; the concurrent-output flake (lost stdout + SIGPIPE under CONCURRENT fork/exec load, blocks heavy builds/M1) is separate and still open. Signed-off-by: Niclas Overby <niclas@overby.me>