Skip to content

Auto-compact cannot be disabled — consolidated report with measurements #42817

Closed as not planned

Description

@M8seven

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)

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

Activity

  1. junaidtitan commented on Apr 6, 2026

    @junaidtitan

    Since CC's auto-compact can't be disabled, Cozempic v1.6.11 takes a different approach — keep the session lean enough that the threshold is never reached. 4-tier guard daemon (25%/55%/80%/90%), 18 strategies, automatic via SessionStart hook.

    pip install cozempic && cozempic init

  2. github-actions commented on May 18, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  3. github-actions commented on Jul 8, 2026

    @github-actions

    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.

  4. locked as resolved and limited conversation to collaborators on Jul 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:corebugSomething isn't workinghas reproHas detailed reproduction stepsstaleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions