Possible sub-process spawn memory leak when pruning during guard ?

[milankubin]

This is now the second time this has happened, and actually the second time pruning was needed (a /compact was done in between).
The first time I wasn't entirely sure if it was cozempic, but now the second time with the same pre-conditions (a session with a /compact and then subsequentially a prune) I can safely say it's a cozempic thread.

The pruning seems to have completed, but my user-slice gets evicted, everything gets killed off and lightdm2 restarts.
Which is normally typical for memory + swap being fully consumed.

Unfortunately, the sys journal is not being very helpful:

It starts with:

pr 12 11:29:33  systemd[3427]: Activating special unit exit.target...
apr 12 11:29:33  systemd[3427]: Stopping app-com.google.Chrome-3999.scope...
apr 12 11:29:33  systemd[3427]: Stopping app-org.chromium.Chromium-119519.scope...
apr 12 11:29:33  systemd[3427]: Stopping app-org.chromium.Chromium-120282.scope...
apr 12 11:29:33  systemd[3427]: Stopped vte-spawn-154f6592-8ab9-49dc-8b29-d033addab4ae.scope - VTE child process 122909 launched by mate-terminal proc>
apr 12 11:29:33  systemd[3427]: vte-spawn-154f6592-8ab9-49dc-8b29-d033addab4ae.scope: Consumed 1.150s CPU time, 34.1M memory peak, 1.3M memory swap pe>
apr 12 11:29:33  systemd[3427]: Stopped vte-spawn-5a3b1aa0-d970-479a-b609-5720a55f4023.scope - VTE child process 183133 launched by mate-terminal proc>
apr 12 11:29:33  systemd[3427]: vte-spawn-5a3b1aa0-d970-479a-b609-5720a55f4023.scope: Consumed 22min 17.762s CPU time, 2.7G memory peak, 571.8M memory>
apr 12 11:29:33  systemd[3427]: Stopped vte-spawn-89a01fd1-3333-49ac-b085-9356791b10b3.scope - VTE child process 140247 launched by mate-terminal proc>
apr 12 11:29:33  systemd[3427]: vte-spawn-89a01fd1-3333-49ac-b085-9356791b10b3.scope: Consumed 6.716s CPU time, 242.5M memory peak, 3.5M memory swap p>
apr 12 11:29:33  systemd[3427]: Stopped vte-spawn-93668a6c-2bd9-4794-920b-89f9bb44d56f.scope - VTE child process 284978 launched by mate-terminal proc>
apr 12 11:29:33  systemd[3427]: Stopped vte-spawn-caa9578d-7f92-4f00-96e4-4608c39827bb.scope - VTE child process 134674 launched by mate-terminal proc>
apr 12 11:29:33  systemd[3427]: vte-spawn-caa9578d-7f92-4f00-96e4-4608c39827bb.scope: Consumed 2min 3.000s CPU time, 1.5G memory peak, 562.6M memory s>

(................  stopping d-bus  services etc ----------)

apr 12 11:29:33  systemd[3427]: Stopped target default.target - Main User Target.
apr 12 11:29:34  systemd[3427]: Finished systemd-exit.service - Exit the Session.
apr 12 11:29:34  systemd[3427]: Reached target exit.target - Exit the Session.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 233964 (claude) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 234350 (sh) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 234351 (python) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 268723 (python) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 268736 (python) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 140142 (sh) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 140143 (python) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 316869 (HeapHelper) with signal SIGKILL.
apr 12 11:29:34  systemd-logind[1835]: Removed session 3.
apr 12 11:29:34  systemd[1]: user@1000.service: Deactivated successfully.
apr 12 11:29:34  systemd[1]: user@1000.service: Consumed 14h 39min 16.196s CPU time, 12.7G memory peak, 6G memory swap peak.
apr 12 11:29:34  lightdm[3368]: Failed to write utmpx: No such file or directory
apr 12 11:29:34  lightdm[3368]: pam_unix(lightdm:session): session closed for user milan
apr 12 11:29:34  systemd-logind[1835]: Session 2 logged out. Waiting for processes to exit.

apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 234350 (sh) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 234351 (python) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 268723 (python) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 268736 (python) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 140142 (sh) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 140143 (python) with signal SIGKILL.
apr 12 11:29:34  systemd[1]: user@1000.service: Killing process 316869 (HeapHelper) with signal SIGKILL.
apr 12 11:29:34  systemd-logind[1835]: Removed session 3.
apr 12 11:29:34  systemd[1]: user@1000.service: Deactivated successfully.
apr 12 11:29:34  systemd[1]: user@1000.service: Consumed 14h 39min 16.196s CPU time, 12.7G memory peak, 6G memory swap peak.
apr 12 11:29:34  lightdm[3368]: Failed to write utmpx: No such file or directory
apr 12 11:29:34  lightdm[3368]: pam_unix(lightdm:session): session closed for user milan
apr 12 11:29:34  systemd-logind[1835]: Session 2 logged out. Waiting for processes to exit.

 [Cozempic Guard: Context was pruned to prevent compaction. 
Confirm the        
  current agent team state below.]                                              
                                                                                
  Active agent team: unnamed                                                    
                                                                                
  Shared task list:                                                             
  (............)
● Confirmed — I have an active agent team. Active agent team: unnamed

  Shared task list:
(........)
  A team state checkpoint was also written to .claude/team-checkpoint.md.

  Continuing with team coordination.

OS: Debian trixie based distro (MATE desktop)
System has 16gb RAM.

Granted, a lot of it is consumed, but there's enough overhead to be running Windsurf+Codex+Claude + Chrome browser and heavy builds, with many tabs open simultaneously without any issues (except for some occasional dip into SWAP with some builds).

[junaidtitan]

Thanks for the report @milankubin — this is serious. Investigating the memory footprint during prune cycles. Will look at whether load_messages on a post-compact session is holding the full JSONL in memory while building the pruned copy.

[junaidtitan]

Fixed in v1.6.19. Three changes reduce peak memory by ~40-60%:

1. Shallow copy instead of deepcopy for envelope-strip, tool-use-result-strip, metadata-strip
2. Team messages tagged as protected instead of splitting into separate lists (eliminates memory doubling)
3. Explicit del between strategy runs + size guard skips sessions >200MB

Thanks for the report @milankubin.

[milankubin]

Fixed in v1.6.19. Three changes reduce peak memory by ~40-60%:

1. Shallow copy instead of deepcopy for envelope-strip, tool-use-result-strip, metadata-strip
2. Team messages tagged as protected instead of splitting into separate lists (eliminates memory doubling)
3. Explicit del between strategy runs + size guard skips sessions >200MB

Thanks for the report @milankubin.

Thanks, and you're welcome.
However, one thing why I'm still a little bit cautious, while I haven't fully confirmed it yet (just avoid doing it) is that I saw a 20% of a 5h window (pro account) carry-over after "continue" after a 5h limit hit.
Now, this is obviously a big cache miss and re-inject of history, of which Claude has had its share.
I was participating in a gh issue on this, and Boris at one point replied that the issue was resolved in a new version.

I re-opened another issue, because I thought the issue was just not fully resolved:
anthropics/claude-code#53514

Later I noticed I didn't fully remove cozempic, as hooks were still active, and I can not rule out that if cozempic rewrites the history, this might lead to a cache miss in such cases.

I'm willing to donate 20% or 40% of a 5h to check if it's indeed a Claude bug, or does have to do with cozempic :)
I was in a hurry and just removed the hooks and moved on, and just avoided doing a session continue after a limit hit, as well since then.

There's probably not much you can do about such scenarios ... but maybe warrants some documentation if true that cozempic is the culprit or accelerator.