Claude Code Idle Compaction: What to Preserve

Claude Code idle compaction means a conversation is summarized while the session is inactive, so the next turn continues with a smaller working context. Check the session notice and current context before assuming everything you discussed remains available. Tools like fenbs keep a reviewed record of decisions and progress outside that session summary.

The practical question is what the next action depends on. A compacted summary may be enough to continue routine work, but an omitted restriction or an unclear test result can send an assistant in the wrong direction. A short verification before resuming is usually more useful than asking it to repeat the entire conversation.

What does idle compaction actually change?

Compaction changes the conversation available to the model; it does not mean your repository files were deleted. Anthropic documents automatic compaction and specifically points to idle compaction in its context window guide↗ (opens in a new tab). A context window is the working material an AI can consider for its next answer.

Think of a long meeting followed by a shorter handoff note. The note can retain the goal and the next action without retaining every abandoned idea. That is useful, provided nobody mistakes a summary of the discussion for the complete discussion or for evidence that work passed review.

A context summary, a saved session, and a file recovery checkpoint serve different purposes. For a basic orientation, see what Claude Code is; use the separate checkpoint guide for recovering edits rather than reconstructing task knowledge.

How can you tell whether a pause caused compaction?

1. Read the session notices around the pause. The documented notice starts with “Compacted while idle, before the prompt cache expired.” Do not infer compaction from a weaker answer alone.
2. Run /context to inspect the current working context. Compare it with an earlier reading if you have one, while remembering that new reads can change the totals.
3. Ask Claude to state the current objective, restrictions, completed checks, and next action before it edits anything.
4. Compare that account with your task record and actual files. Correct missing facts before resuming the work.

A smaller context reading is a clue, not proof of the cause. You might have switched sessions, cleared the conversation, or continued from a different starting point. Record what you observed and which session you were using; avoid turning a guess about the trigger into an explanation everyone later treats as confirmed.

Anthropic’s idle compaction settings reference↗ (opens in a new tab) documents idleCompaction: false to disable this behavior. It also explains the qualifying terminal, cache, feature-flag, size, and idle-time conditions; a pause alone does not guarantee compaction. Check supported settings for your installed version before making a change.

If the behavior began after an installation change, the Claude Code update guide covers that separate investigation. Keep the settings question separate from the continuity routine: a saved checkpoint remains useful whether compaction runs or you resume in a different session.

Which information needs its own checkpoint?

Save information whose loss would change the next safe action. That includes what a person approved, what remains forbidden, the exact condition a fix must satisfy, and what the assistant has actually verified. Save source locations so the next session can inspect evidence instead of relying on another summary.

• Objective: the behavior you are trying to change and the boundaries of the request.
• Decisions: the approved approach and the reason it was chosen, with unresolved choices clearly marked.
• Progress: changed files and remaining work, including uncommitted changes belonging to someone else.
• Verification: which checks finished, their results, and which checks have not run.
• Continuation: the first next action, any running process, and anything waiting on a person.

For example, “form validation updated; unit checks passed; browser behavior untested; do not deploy” is a usable checkpoint. “Validation fixed” removes the distinctions the next assistant needs. The checkpoint should be short enough to review, with detail available through file paths or task references.

This is the continuity problem fenbs handoffs address: preserve the work state independently of whichever conversation summary the coding app produces.

What should you check when the session resumes?

Begin with a read-only comparison. Ask the assistant to identify the working directory, inspect the relevant changes, and explain the proposed next step. Review whether it has kept the boundary between observed facts, assumptions, and unfinished work. It should be able to name the evidence for a claim that something passed.

Anthropic explains that Claude Code can lose detailed early instructions during summarization and supports focused /compact instructions in its architecture guide↗ (opens in a new tab). That makes an explicit check worthwhile even when the summary sounds confident.

Use a small question with a definite answer. If the task forbids a schema change, ask whether one is allowed and where that restriction is recorded. If the answer is wrong, restore the instruction and inspect the plan before approving more actions. A successful recall check supports that particular fact; it does not prove every detail survived.

Keep a stopped command distinct from a successful one. When a test was still running at the break, inspect the process or its saved result before starting another copy. When the result cannot be established, record it as unknown and run the appropriate check again.

Can you make the next summary more useful?

Before a natural break, ask for a proposed checkpoint and review it. Preserve exact names, meaningful file paths, and the conditions for completion. Remove lengthy tool output that can be read again. A good checkpoint tells someone what to inspect next without trying to reproduce the entire session.

Stable repository conventions belong with the repository. Changing progress belongs in an updated work record. Mixing them makes every future session read a growing diary and leaves old “next steps” competing with the current one. Our context engineering hub covers the broader practice of choosing what an assistant should read.

Agree on a consistent stopping routine with teammates: save the task state, name the remaining check, and identify the first action for the next session. Consistency makes omissions easier to spot. It also means an unexpected pause creates less reconstruction work, even when you cannot control when a session is summarized.

How to do this with fenbs

1. Create a free account, add the project, and create a task for the work you want to resume.
2. Record the person’s approved constraints in Decisions and rules. Keep proposals and open questions separate from decisions.
3. Update the task with the remaining plan and the checks completed. Save Where we left off with the first next action and anything still running.
4. Connect Claude Code through the integration guide and ask it to read the project context when the session resumes, then compare that record with the files.

fenbs does not control Claude Code compaction or recover omitted chat messages. It is useful when you need an explicit work record across breaks, teammates, or AI apps; a small disposable coding question may need only the session itself. One person can use fenbs free, with no credit card.