How to control Claude Code context compaction

Why there is no off switch

The first thing most people try is the obvious one: open ~/.claude/settings.json, add "autoCompactEnabled": false, restart. It does nothing. The key is not in the settings schema, so it is parsed and silently discarded (issue #38483). A follow-up request to add a real autoCompact: false boolean was filed and closed as not planned (issue #42149).

Recent builds do expose an Auto-compact toggle inside the /config Settings panel. It works for the current session, but reports differ on whether it survives a restart, so treat it as a per-session switch rather than a permanent setting. The docs themselves are blunt about the design: Claude Code “manages context automatically as you approach the limit. It clears older tool outputs first, then summarizes the conversation if needed.” That automation is not something you configure away. So controlling compaction does not mean stopping it. It means steering it.

The control panel

Six things touch compaction. Five are real levers. One is the move that looks like a lever and is not. This is the whole panel:

Lever one: steer what survives

A compaction is a summary. Left alone, it writes a generic recap and flattens the specifics, the file path you set once, the constraint from turn four, the decision the model made and never restated. The docs give you two ways to aim it: “add a Compact Instructions section to CLAUDE.md or run /compact with a focus.”

# Blind: a generic recap, you do not choose what it keeps
/compact

# Steered: the summary is written around what you name
/compact focus on the auth refactor and the file paths we settled

# Standing: applied to every compaction, automatic ones included
# CLAUDE.md
## Compact Instructions
Always preserve: chosen file paths, the DB schema decisions,
and any constraint the user stated explicitly.

One subtlety worth knowing: skills are re-attached on a budget. After a summary, Claude Code re-attaches the most recent invocation of each skill and keeps the first 5,000 tokens of each, within a combined 25,000-token budget, filled most-recent-first. Invoke a lot of skills in one session and the oldest ones get dropped entirely at the boundary. The order you invoke skills quietly decides which ones survive.

Lever two: compact on purpose, before the wall

Automatic compaction fires when the session is already near the limit. By then the summarizer is squeezing a nearly full window into a paragraph, which is the worst possible moment to ask it to be selective. Running /compact yourself at a natural break, a task finished, a test suite green, gives the summarizer a cleaner cut and a smaller pile to compress. /clear is the same idea taken further: when the next task genuinely does not need the old context, drop all of it instead of carrying a summary you will not use.

There is also a failure mode worth recognizing. If a single file or tool output is so large that the context refills immediately after each summary, Claude Code stops auto-compacting after a few attempts and shows a thrashing error instead of looping forever. That is not a bug to fight, it is a signal: something oversized is in the window, and /context will show you what.

Lever three: fork instead of compact

The strongest control is structural. Compaction summarizes a session in place and keeps the same session ID. Forking, with claude --fork-session or the /branch command, copies the history into a new session ID and leaves the original untouched. The branch starts with the full prior context, not a paragraph about it.

That turns a long, doomed session into a chain of shorter ones. When a window approaches the limit, you fork at a clean point and continue on the branch. The parent never compacts, because you never run it into the wall. The work that mattered is carried forward as the model saw it, not as the summarizer rewrote it. The catch with the raw CLI: you have to know when to fork, and the terminal does not tell you the boundary is coming.

One-click fork: the boundary becomes a branch point

Once the boundary is visible, forking should not be a session-id dance. In the Fazm bridge it is one request. The handleForkSession handler in acp-bridge/src/index.ts (around line 3959) wraps the ACP session/fork RPC. An in-place fork swaps the current chat onto a new branch under the same window, while the parent session is left on disk and stays recoverable from the conversation history list. The branch carries the full prior context. No summary, no paragraph, no retyping.

That is the honest shape of controlling compaction. Nothing built on Claude Code can delete the boundary, because the SDK owns when it fires, and Fazm does not pretend otherwise. What changes is that the boundary stops being a wall you discover and becomes a branch point you choose. You compact deliberately, with a focus, or you fork before you ever need to. The terminal gives you the levers. A host that surfaces the event gives you the timing.