[BUG] Preventive auto-compact and blocking-limit warning silently disabled for most recent models; desktop-app resume disarms all 1M-context sessions

Preflight Checklist

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

What's Wrong?

Environment: macOS desktop app (bundled Claude Code 2.1.170) and standalone CLI 2.1.175 (latest at the time of writing). Reproduced on both. Max plan. Models tested: claude-fable-5 (1M window), claude-opus-4-8 (1M variant), claude-haiku-4-5, claude-sonnet-4-6.

The preventive, threshold-based auto-compact silently fails to arm for most recent models: in our CLI tests, claude-sonnet-4-6 armed by default while claude-haiku-4-5 never did. claude-fable-5 and claude-opus-4-8 (1M), both used on the desktop app, were protected only while something supplied the window size explicitly (env var, or the desktop app itself when it creates a new chat). When it is not armed:

• the threshold compaction never happens, at any threshold value (default or overridden);
• the blocking-limit warning (CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE) never surfaces either (observed on the desktop app);
• the status line still shows "left until auto-compact" percentages that will never fire;
• compaction does still happen in the end, but only as an emergency at the model's maximum context window (observed at 997,785 and 1,005,332 pre-compact tokens on 1M sessions). What never runs is the preventive, threshold-based auto-compact, so the session works at full context cost for hundreds of thousands of tokens before that point. We only made this visible by lowering the threshold with the test env var; at default thresholds the symptom is identical, just further out.

On the desktop app the worst case: new chats are protected (the app supplies the window), but any chat resumed after an app restart or update loses auto-compact permanently.

What the logs suggest: the debug log prints a thresholdSource field. The check only seems to run when an approved source exists: with claude-sonnet-4-6 the log shows thresholdSource=model-default; with claude-haiku-4-5 no "autocompact:" line is ever emitted, as if no source qualifies; adding the env var makes the same line appear with thresholdSource=env. 1M-context sessions never appear to get a model default (both 1M models we used behaved that way), which is why the desktop resume case, where the app stops supplying the window, turns them off entirely. The issue reproduces on both 2.1.170 (desktop app) and 2.1.175 (CLI).

Real-world impact: resumed sessions at 280k, 308k and 652k tokens never compacted, paying full context on every turn. Two Opus 4.8 (1M) sessions were saved only by the emergency compaction near the window limit. #36751 (March 2026, Opus 4.6 1M, Windows) reports the same symptom with no diagnosis, so this has been live for months across platforms.

What Should Happen?

The preventive auto-compact should protect the session based on the window size the client already knows, regardless of where that value came from. At minimum, the user should be warned when auto-compact is inactive.

Error Messages/Logs

# claude-sonnet-4-6, no env vars (allowlisted): the preventive check runs
[DEBUG] autocompact: tokens=[REDACTED] level=compact effectiveWindow=180000
[WARN] autocompact: fixed prefix ~58844 > threshold 9000 — compaction cannot help
[DEBUG] autocompact: routing through reactive (thresholdSource=model-default)
[DEBUG] [API REQUEST] /v1/messages ... source=compact

# claude-haiku-4-5, no env vars (not allowlisted): the debug file contains ZERO "autocompact:" lines

# claude-haiku-4-5 + CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000: the preventive check runs
[DEBUG] autocompact: tokens=[REDACTED] level=compact effectiveWindow=180000
[DEBUG] autocompact: routing through reactive (thresholdSource=env)

# clamp check: requesting CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000 on claude-haiku-4-5 still yields
[DEBUG] autocompact: tokens=[REDACTED] level=compact effectiveWindow=180000

Steps to Reproduce

Precondition: if CLAUDE_CODE_AUTO_COMPACT_WINDOW or CLAUDE_AUTOCOMPACT_PCT_OVERRIDE are set in your environment or in the env block of settings.json, remove them first (in CLI runs the settings env overrides inline values). The PCT override is an undocumented test knob that only lowers the threshold so the repro is fast; the bug reproduces at default thresholds too, it just needs more tokens. Two follow-ups are needed: the check compares the threshold against the real usage of the last completed turn, and the visible compaction can take one extra turn when the summarizer has little material to work with.

# ballast: ~60k tokens of random noise
python3 -c "import base64,os;print('Ballast test message: ignore the noise below and reply with just: ok');print(base64.b64encode(os.urandom(48000)).decode())" > /tmp/ballast.txt

# A. claude-haiku-4-5: the preventive check never runs
SID=$(CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=5 claude -p --model claude-haiku-4-5-20251001 --output-format json < /tmp/ballast.txt | python3 -c "import json,sys;print(json.load(sys.stdin)['session_id'])")
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=5 claude -p "hi again"   --resume $SID --debug-file=/tmp/a1.log
CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=5 claude -p "hi again 2" --resume $SID --debug-file=/tmp/a2.log
grep -c "autocompact:" /tmp/a1.log /tmp/a2.log
# ACTUAL: 0 lines in both logs; no compact_boundary in the session transcript;
#         context grew to 79,870 tokens on a 9,000 threshold

# B. claude-sonnet-4-6: same exact steps with --model claude-sonnet-4-6
# ACTUAL: logs show "autocompact: ... level=compact" (thresholdSource=model-default);
#         the transcript gets a compact_boundary, trigger "auto", at 79,034 tokens; context drops to ~22,700

# C. workaround check: haiku again, adding CLAUDE_CODE_AUTO_COMPACT_WINDOW=200000 to every command
# ACTUAL: the preventive check runs (thresholdSource=env); boundary "auto" at 80,115; context drops to ~23,300

Transcripts live in ~/.claude/projects/<cwd-slug>/<session-id>.jsonl; compaction shows up as a compact_boundary system entry. The quoted log lines are emitted by --debug-file.

Desktop app (claude-fable-5, 1M):

1. New chat, paste a large ballast message: auto-compact fires (boundary at 45,534 with a 5% test threshold).
2. Manual /compact, then ballast again: fires again (46,810). Manual compaction does not disarm anything.
3. Fully quit and reopen the app, resume the same chat, ballast again: the threshold compaction never fires again. Context observed up to 198,768 tokens on a ~49,000 threshold, zero boundaries; a blocking-limit override set below the current context never surfaces either.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

None known - observed from 2.1.160 through 2.1.175 (#36751 suggests 2.1.80 too)

Claude Code Version

2.1.175 (standalone CLI) and 2.1.170 (bundled in macOS desktop app)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Workaround (verified): set CLAUDE_CODE_AUTO_COMPACT_WINDOW=1000000 in the env block of ~/.claude/settings.json. It is read at runtime: two already-disarmed resumed chats compacted on their next message (boundaries at 156,781 and 200,248) with no restart needed. Safe with smaller-window models too: requesting 1,000,000 on claude-haiku-4-5 still yields effectiveWindow=180000 in the log, so the value is clamped to the model's real window.

Suggested fixes:

• arm the preventive auto-compact from the known window value regardless of its source;
• re-supply the window when the desktop app resumes a session;
• provide a built-in default for every model, including 1M windows;
• decouple the blocking-limit warning from the same condition.

Related: #36751 (same symptom on Opus 4.6 1M, no diagnosis).