Context compaction must never interrupt a commit sequence
Status Fixed / completed
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 6 comments · opened Apr 5, 2026 · closed Apr 14, 2026
When context compacts or exhausts mid-session, any pending git commit is lost. The model frequently defers commits to the end of long tasks, and when context runs out before that step, all work is orphaned as uncommitted changes with no record.
The commit is the most critical step. Context should never compact or run out in the middle of one.
What happens
- Long session (audit, refactor, multi-file edit) uses most of the context
- Model reaches commit step at the end
- Context compacts or exhausts mid-commit
- User finds uncommitted changes, no context, broken state
- Next session starts from a lossy summary and can't reconstruct what happened
Expected behavior
- Never compact during a commit sequence (stage → commit → verify)
- Warn with enough headroom to complete a commit before compaction
- Or treat commit as an atomic protected operation that always completes
Impact
Recurring problem across multiple projects. The work is done — files are edited correctly — but without the commit it's as if nothing happened.
6 Comments
Adding context: This issue caused a terrible user experience in practice. During a multi-file audit session, context ran out right before the commit step. All code changes were made correctly but never committed. The next session started from a lossy summary and couldn't reconstruct what happened. User had to manually piece together what was done vs what wasn't.
On top of that, the model then spent the follow-up session going in circles — claiming tools weren't installed when they were, filing duplicate issues, and generally making things worse instead of just doing what was asked.
This needs to be treated as a critical UX issue. Context compaction should never interrupt a commit sequence, and the model should commit incrementally during long tasks rather than deferring to the end.
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate. The linked issues (#34674, #21925, #42935) are about general context limits. This issue is specifically about commits being an atomic operation that must never be interrupted by compaction. Different problem, different fix.
We solved this in dotforge with a PostCompact + SessionStart hook pair:
git status+ active constraints to.claude/session/last-compact.mdsource == "compact") re-injects that file as contextAfter compaction the model knows what was in progress and can resume — including pending commits.
Template hooks available at template/hooks/.
That said, this is a workaround. The real fix should be at the platform level — compaction should detect uncommitted changes and either defer or force a commit before compacting.
Cozempic takes a different approach — proactive pruning so compaction fires less often. The guard daemon auto-prunes at 4 thresholds (25/55/80/90%) with 18 lossless strategies. Team state is checkpointed and recovered automatically via hooks.
pip install cozempic && cozempic initFeedback welcome.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.