Environment: Claude Code 2.1.220, WSL2 Ubuntu (systemd enabled), host 32GB RAM / 16 logical CPUs, WSL2 memory ceiling ~16GB (default 50% allocation).
Kernel log shows the daemon process (comm name matches the daemon version string, 2.1.220) OOM-killed three times within ~5 minutes:
00:56:31 Killed process (2.1.220) total-vm:17062176kB anon-rss:10941952kB
00:59:13 Killed process (2.1.220) total-vm:17062176kB anon-rss:10941952kB
01:01:53 Killed process (2.1.220) total-vm:17062176kB anon-rss:10941952kB
Identical footprint each time (~10.9GB anon-rss), respawning and re-leaking to the same size within ~2-3 minutes each cycle.
Because the daemon runs in init.scope rather than its own cgroup/slice, the OOM event cascades: systemd kills the entire init.scope, including unrelated processes (init, SessionLeader, Relay, bun, claude, other user processes) rather than just the offending daemon. This takes down the whole WSL2 session, which then needs a full VM restart (next boot's journal shows "uncleanly shut down" as a result).
Already on latest CLI version (2.1.220 matches npm registry latest), so this isn't fixed by upgrading.
Question: is this a known daemon memory leak (bg spawned/spare worker accumulation per daemon.log)? Possible mitigations worth considering: giving the daemon its own cgroup/slice so an OOM kill doesn't cascade, or a lower oom_score_adj so it's targeted before other session processes.
Environment: Claude Code 2.1.220, WSL2 Ubuntu (systemd enabled), host 32GB RAM / 16 logical CPUs, WSL2 memory ceiling ~16GB (default 50% allocation).
Kernel log shows the daemon process (comm name matches the daemon version string,
2.1.220) OOM-killed three times within ~5 minutes:Identical footprint each time (~10.9GB anon-rss), respawning and re-leaking to the same size within ~2-3 minutes each cycle.
Because the daemon runs in
init.scoperather than its own cgroup/slice, the OOM event cascades: systemd kills the entire init.scope, including unrelated processes (init,SessionLeader,Relay,bun,claude, other user processes) rather than just the offending daemon. This takes down the whole WSL2 session, which then needs a full VM restart (next boot's journal shows "uncleanly shut down" as a result).Already on latest CLI version (2.1.220 matches npm registry latest), so this isn't fixed by upgrading.
Question: is this a known daemon memory leak (
bg spawned/spare worker accumulation perdaemon.log)? Possible mitigations worth considering: giving the daemon its own cgroup/slice so an OOM kill doesn't cascade, or a loweroom_score_adjso it's targeted before other session processes.