claude-code - 💡(How to fix) Fix [BUG] ccd-cli does not terminate prior --resume <uuid> child when same session is resumed

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When a Claude Code session is resumed via ccd-cli --resume <uuid>, the ccd server spawns a fresh ccd-cli child but does not signal the prior child for the same UUID to exit. Multiple concurrent ccd-cli processes accumulate per session UUID, each holding ~250 MB RSS. On a host where sessions get resumed over multiple days, this silently accumulates into significant memory pressure with no visible cause from inside any single session — the leaked processes are siblings of whichever session you currently have open.

Observed on a host with 14 concurrent ccd-cli processes; grouping by --resume <uuid> showed:

UUID <uuid-a>: 3 processes (ages ~29h, ~26h, ~21h)  combined ~750 MB RSS
UUID <uuid-b>: 2 processes (ages ~29h, ~26h)        combined ~360 MB RSS

All three duplicates of <uuid-a> share the same parent PID (the ccd server process), so they aren't orphans — the server is actively parenting all three. Pattern is consistent with each --resume invocation spawning a fresh child without terminating the prior one.

What Should Happen?

When ccd-cli --resume <uuid> is invoked and a prior ccd-cli is already running with the same UUID, the server should either:

• Refuse to start a new child and re-attach to the existing one, or
• SIGTERM the prior child (with reasonable grace), then start the new one.

Error Messages/Logs

No error message — silent. The leak is only visible by external inspection (`ps`/`/proc`); the active session UI gives no indication that older sibling processes for the same UUID still exist.

Steps to Reproduce

Suspected, not yet conclusively reproduced from a clean state:

1. ccd-cli --resume <uuid> to open a session.
2. Exit the terminal (close the window/tab) without an explicit /exit — i.e. the way most people close terminals.
3. Some hours later, run ccd-cli --resume <uuid> again with the same UUID.
4. ps aux | grep ccd-cli | grep <uuid> now shows two live processes for that UUID.
5. Repeat over days; per-UUID counts climb.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

ccd-cli 2.1.138 (also 2.1.121 and 2.1.128 installed and in use across the leaked processes).

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Workaround currently in place: a small local janitor (Python script + systemd timer firing twice daily) groups ccd-cli processes by --resume <uuid> and SIGTERMs all but the youngest of each UUID group. Reaped ~770 MB on first live fire (3 duplicates across 2 session UUIDs). Caveat for anyone copying this approach: in the deployed install layout the executable path is ~/.claude/remote/ccd-cli/<version> (the version is the basename and ccd-cli is the parent directory), so a basename-anchored check misses every real process; the match has to treat ccd-cli as a path segment in argv[0].

The reason this leak is hard to notice from inside Claude Code: each ccd-cli process appears self-contained, so a user looking at one active session has no signal that older sibling processes exist. The only visible symptom is gradual host RAM pressure with no specific culprit. Combined with normal "I open lots of sessions" usage patterns, the dominant explanation a user reaches for is "Claude Code uses a lot of memory" — not "Claude Code is leaking my closed sessions." This bug report exists so the harness can close the loop rather than every long-lived user discovering it independently.