cozempic v1.8.29 — guard no longer reload-loops on an unprunable session
RCA of a real incident: the guard daemon reload-looped on a session that was 77% of the context window but couldn't be pruned below threshold — it was dense real conversation (not tool-output bloat), so each prune freed ~0%, stayed over threshold, and re-fired. Hundreds of cycles, no give-up, no back-off — which could hang a resume.
Root cause: a read-only prune of a live session was always treated as a benign "busy, will prune later" skip and never counted toward the circuit-breaker's K-exit — even when the computed prune freed nothing (the session is genuinely unprunable, busy or not).
Fix: the breaker now distinguishes a busy-but-prunable live session (stays benign — a long agent run can't trip the K-exit) from a live session that's also unprunable (computed prune frees < 10% of bytes → counts toward K-exit). So the daemon K-exits and backs off instead of looping forever on a session it's powerless against. The read-only path now always exposes the computed prune's byte reduction so the breaker can tell the two apart.
Verified offline against the actual incident transcript; the futile-loop K-exit, agents-active defer, and clean pidfile/watcher teardown all confirmed by a 2-agent adversarial QA pass. Full suite: 1320 passed.
brew upgrade cozempic # or: pip install -U cozempic / npm i -g cozempic / uv tool upgrade cozempic