claude-code - 💡(How to fix) Fix [Bug] Auto-compaction fires despite autocompact being explicitly disabled in /config

Title

[Bug] Auto-compaction fires despite autocompact being explicitly disabled in /config

Body

Summary

Auto-compaction executed silently between two consecutive turns in a session where autocompact was explicitly disabled via /config. The /context output immediately before AND after both state "Autocompact is disabled", yet ~370k tokens of message history were compacted away between two turns.

This is a stronger variant of #50015 (silent compaction without warning). In this case, the user took the explicit action of disabling autocompact — presumably to retain full context for a critical handoff operation — and the system compacted anyway.

Reproduction steps

1. Start a session in Claude Code (Opus 4.6, 1M context)
2. Disable autocompact via /config (confirm it shows "Autocompact is disabled" in /context output)
3. Work until context reaches ~95% (948.7k / 1m tokens)
4. Run /branch <name> to create a conversation branch
5. In the new branch, immediately run /context — observe it still shows 95% with "Autocompact is disabled"
6. Send a message that triggers a tool call (in my case: writing a file via Bash heredoc)
7. After the response, run /context again — observe context has dropped to ~58% (577k / 1m)

Between steps 5 and 7, no /compact was run. The "Autocompact is disabled" text appears in BOTH /context outputs. Yet ~370k tokens of messages were lost.

Expected behavior

With autocompact disabled, context should NOT be automatically compacted. If the system hits a hard ceiling that prevents further API calls, it should:

1. Error or warn — "Context full, cannot proceed. Run /compact or start a new session."
2. NOT silently compact — the user disabled autocompact specifically to prevent lossy compression at a critical moment.

Actual behavior

Context was silently compacted despite the setting being disabled. No warning, no error, no user-visible indication that compaction occurred. The only signal was the /context output dropping from 95% to 58% between turns.

Destructive behavior concerns

This is a data-loss bug, not a cosmetic one. The compacted context represents ~370k tokens of conversation that the model can no longer reference accurately. In my specific case:

• I was in the middle of a multi-day session authoring 62 git commits with specific PII-scrubbing requirements
• The session involved nuanced decisions about what content is safe to ship publicly vs what must remain private (sensitive data, proprietary logic, etc.)
• After compaction, the model cannot reliably recall which files were scrubbed, which decisions were made about specific UUIDs, or what the exact merge-path workflow requires

If the model hallucinates post-compaction (as documented in #50015 — "treating historical state as pending actions"), it could:

• Re-introduce scrubbed PII into files that were explicitly cleaned
• Re-execute destructive git operations that were already completed
• Misremember CR numbers or approval states, leading to duplicate actions on the code review platform

The user disabled autocompact precisely to prevent this class of problem. The system ignoring that setting defeats the purpose.

Privacy concern

If auto-compaction generates a "summary" of the compacted context, that summary is processed by the model on the next turn. If the original context contained sensitive information that the user intended to keep within a controlled session boundary (e.g., PII that was being actively scrubbed, credentials discussed in passing, private URLs), the compaction summary might inadvertently persist a lossy version of that sensitive content in a form the user didn't consent to.

With autocompact disabled, the user's mental model is: "my context stays exactly as-is until I explicitly compact it." Silent compaction violates that contract.

Environment

• Claude Code version: latest as of 2026-05-08 (Opus 4.6, 1M context, us.anthropic.claude-opus-4-6-v1[1m])
• Platform: macOS (Darwin 25.3.0)
• Shell: zsh
• Autocompact: explicitly disabled via /config
• Context at time of bug: 948.7k / 1m (95%) → 577k / 1m (58%) after one turn

Relationship to other issues

• #50015 — "Auto-compaction fires without pre-compaction warning" — same class of bug but that issue doesn't address the "disabled in settings" case
• #46663 — "Compaction silently deactivates plan mode" — similar "compaction does something the user didn't consent to" pattern
• #34925 — "Configurable auto-compaction threshold" — if the threshold is configurable, "disabled" should mean "infinite threshold" (never fires)

Suggested fix

If autocompact = disabled in user config:

1. Never auto-compact. Period. Even at 99%.
2. If the API call would exceed the context window, return a user-visible error: "Context full. Run /compact manually or start a new session." Do not silently compact.
3. If there's a hard system ceiling (e.g., the API literally cannot accept a request above N tokens), truncate the OUTGOING request rather than compacting the stored history. Or refuse the turn entirely.

The current behavior — "we'll compact anyway if we need to, regardless of your setting" — makes the setting meaningless and untrustworthy.

Drafted by Claude Code using claude-opus-4-6 (1M context).