claude-code - 💡(How to fix) Fix [BUG] Auto-compact on session start decreases available context % (Opus 1M / 4.7) [1 comments, 2 participants]

Preflight Checklist

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

What's Wrong?

When restarting a parent process (in my case, a tmux-based supervisor) that spawns multiple Claude Code sessions, each new session triggers an auto-compact on start without prompting, even though plenty of context room is available. After the on-start auto-compact, the context-left percentage decreases rather than increases — the auto-compact appears to be net-negative on the 1M extended-context model (Opus 4.7 1M).

Example: a session starts and immediately auto-compacts. Pre-compact, context-left would have been higher; post-compact, the statusline shows ~37% ctx left. Subsequent activity continues from that lower baseline rather than the higher one I'd have had without the auto-compact.

This appears to be a variant of #50732 (post-resume context accounting broken) but the on-start trigger and the net-negative outcome together don't precisely match any single existing issue I found.

What Should Happen?

Either:

1. Auto-compact should not trigger on session start when context room is plentiful (per #50204 the trigger appears to be miscalibrated for extended-context models — see #34332 for Opus 4.6 1M reporting the same early-firing pattern at ~76K with 924K headroom)
2. If auto-compact does trigger, the post-compact context-left % should be ≥ the pre-compact value (compaction should reclaim, not consume)
3. At minimum, a prompt before auto-compact runs so the developer can defer

Error Messages/Logs

No error output. Behavior is silent — no stderr, no warnings; the percentage just drops in the statusline.

Steps to Reproduce

1. On Opus 4.7 with 1M context, start a Claude Code session as a child of a long-running parent process (tmux supervisor in my case)
2. Engage in normal work until the session has accumulated some context (no specific threshold needed; happens even when well under any documented limit)
3. Restart the parent process so the child Claude Code session also restarts
4. Observe the statusline immediately after the new session is up — the context-left % shows lower than expected
5. Compare to where you were before restart — post-compact ctx-left is lower, not higher

The auto-compact appears to fire silently as part of session-start; there is no /compact command issued by the user.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown precisely — observed "recently started happening" by the developer; suspect within the last ~30 days based on the May 2026 changelog mentioning Better handling of 1M-context model sessions with smaller autocompact windows.

Claude Code Version

2.1.128 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

(Ghostty terminal hosting tmux; TERM=tmux-256color, TERM_PROGRAM=tmux)

Additional Information

Related issues (cross-reference, not duplicates):

• #50732 — post-resume context accounting broken; inconsistent /context output. Closest match but specific to resume rather than start.
• #50204 — auto-compact triggers on actual server token count while UI shows plenty of room. Explains why the developer sees "plenty of context room" before the auto-compact fires.
• #34332 — Opus 4.6 1M auto-compact at ~76K with 924K unused. Same early-firing pattern on extended-context family.
• #13112 — compaction net-negative behavior confirmed (context loss + degraded performance).
• #38483 — autoCompactEnabled setting silently ignored in settings.json; only honored via claude config set -g autoCompactEnabled false writing to ~/.claude.json.

Workaround I'm currently using: claude config set -g autoCompactEnabled false per #38483 — eliminates the on-start auto-compact entirely. Useful as escape hatch but the underlying regression (net-negative compaction on 1M) likely affects users who don't know about this config flag.

Suggested investigation areas (from the affected developer's perspective):

1. Compare the size of the compaction summary against the size of the messages it replaces on Opus 1M sessions — looks like the summary is larger than what it replaces
2. Verify whether MEMORY.md / CLAUDE.md / project-context re-injection at compact time is being counted in the post-compact total — if those re-load on compact, they'd inflate the post-compact byte count
3. Check whether the on-start trigger itself is the problem (compact firing at session-start when previous-session state is still being deserialized) — distinct from the steady-state compact path