Auto-compact cannot be disabled — consolidated report with measurements

Summary

This is a consolidated report covering the full auto-compact disable problem. It unifies 7+ existing issues with new measurements and reproduction data that none of the individual issues provide.

Core problem: There is no working method to prevent automatic context compaction. Every documented approach fails silently. This makes long sessions fundamentally unreliable.

---

What doesn't work (tested on v2.1.90, Opus 4.6 1M context)

| Method | Result |
|--------|--------|
| /config → Auto-compact → false | Ignored — compaction still triggers |
| claude config set -g autoCompactEnabled false | Writes to ~/.claude.json, no effect |
| "autoCompactEnabled": false in settings.json | Key not in schema, silently ignored |
| DISABLE_AUTO_COMPACT=true env var | No confirmed effect |
| CLAUDE_AUTOCOMPACT_PCT_OVERRIDE=95 | Silently capped by Math.min(userThreshold, defaultThreshold) — can only lower threshold, never raise it above ~83% |

New data: compaction triggers at ~35% context usage

I built a PostToolUse hook (context-watchdog.sh) that estimates cumulative token usage per session. Measurements from a real session (Apr 2, 2026):

• Session: omniquant-v2, Opus 4.6, 1M context window
• Estimated tokens at compaction: ~346K (~35% of 1M)
• Expected compaction: never (auto-compact disabled) or at ~95% (emergency)
• Actual: compacted mid-task, unprompted, at ~35%

This is not an emergency compaction near the context limit. The system is actively compacting at a third of capacity despite every available "disable" setting being off.

Impact

1. Context loss mid-task: Compaction discards decisions, file paths, variable names, and reasoning that cannot be recovered from code alone
2. Silent failure: No warning, no event, no hook fires before it happens (PreCompact hook exists but the compaction itself is the problem — it shouldn't happen at all)
3. Workarounds don't work: Users build elaborate hook systems (I have 3 hooks + snapshot persistence) but they're mitigating a problem that shouldn't exist
4. Trust erosion: Users cannot rely on Claude Code for any session longer than ~30 minutes of active tool use

What this issue is NOT

This is not a duplicate of any single existing issue. Each prior issue reports one symptom. This issue documents:

• All disable methods tested and failed (table above)
• Measured trigger point (35%, not 83% or 95%)
• The CLAUDE_AUTOCOMPACT_PCT_OVERRIDE Math.min() bug that prevents raising the threshold
• The gap between "auto-compact: false in /config UI" and actual behavior

Related issues (all open or closed-not-planned)

• #38483 — autoCompactEnabled not in schema
• #18264 — autoCompact: false ignored, triggers at ~78%
• #24856 — Hard stop at ~85% with autoCompact: false
• #24589 — No documentation for disabling
• #31806 — CLAUDE_AUTOCOMPACT_PCT_OVERRIDE cannot raise threshold (Math.min bug)
• #6689 — Feature request: --no-auto-compact flag
• #10691 — Feature request: proper autoCompact settings

Proposed fix

In order of preference:

1. Respect the setting: When autoCompactEnabled is false (via any method), do not compact. Period. Let the user hit the context wall and decide.
2. Fix the Math.min bug: Allow CLAUDE_AUTOCOMPACT_PCT_OVERRIDE to raise the threshold above default, not just lower it.
3. Add a real CLI flag: --no-auto-compact that definitively prevents automatic compaction.
4. At minimum: Document honestly that auto-compact cannot be disabled, so users stop wasting time on settings that do nothing.

Reproduction

# 1. Disable auto-compact via all available methods
claude config set -g autoCompactEnabled false
# In settings.json env: "DISABLE_AUTO_COMPACT": "true"
# In /config UI: Auto-compact → false

# 2. Start a session with moderate tool use (~50 tool calls)
# 3. Monitor with a PostToolUse hook counting estimated tokens
# 4. Observe: compaction triggers at ~30-40% context usage

Environment

• Claude Code v2.1.90
• Model: Opus 4.6 (1M context)
• Platform: macOS Darwin 25.3.0
• Plan: Claude Max