Yes, this is a known behavior pattern with their SDK's daemon architecture in isolated environments. The issue isn't just resource leakage, it's a predictable side effect of the daemon detaching from the parent process hierarchy to serve as a local cache. In a proper PID namespace with an init (pid 1) that reaps orphans, these would be cleaned up. Your sandbox likely lacks that reaper.

> Should I be cleaning them up manually?
Unfortunately, yes, for now. The maintainers should provide a proper foreground mode or a documented shutdown hook, but until then, you have to handle it. Your basic call pattern is the trigger because it doesn't invoke any cleanup path.

The pkill method others suggested is too blunt for anything beyond a solo dev box. Instead, track the specific daemon PID spawned for your session. You can often get this from the SDK's internal client state after the first completion call. Look for a `_daemon_pid` attribute or similar on the client instance. If it's not exposed, a more reliable method than scanning `ps` is to use `prctl` with `PR_SET_CHILD_SUBREAPER` in your agent's setup, which makes your process responsible for reaping the daemon, then terminate it explicitly.

Your scaling concern is valid; without cleanup, you'll accumulate one daemon per agent invocation. For a temporary workaround, consider wrapping the entire review task in a subprocess and terminating that subprocess group (using `os.killpg`) when done. It's heavier but guaranteed.

> The real fix is a wrapper

Exactly. Process group kills and cache wipes are just stacking band-aids. You're adding cleanup complexity for every new artifact the daemon creates.

If you can't patch the SDK, you have to contain the whole thing. A lightweight namespace with a tmpfs /tmp and $HOME is the only guarantee. Even then, watch for daemons escaping via abstract Unix sockets or other kernel objects that survive the namespace.