[Bug] Auto-Compact triggers prematurely on Opus 5.5 1M context window

Same problem and there is no way to turn it off

Same here, and the pattern points to idle compaction (#98747), not the token threshold.

Environment: Windows 11, Claude Code 2.1.294 (native, autoUpdatesChannel: latest), model claude-fable-5-1, /context shows 141k/1m and Auto-compact window: 1m tokens. No DISABLE_AUTO_COMPACT, CLAUDE_CODE_AUTO_COMPACT_WINDOW, CLAUDE_AUTOCOMPACT_PCT_OVERRIDE, CLAUDE_CODE_MAX_CONTEXT_TOKENS or CLAUDE_CODE_DISABLE_1M_CONTEXT in env or any settings.json.

Across 3 long-running sessions over 2 days (2026-10-07/08), every compactMetadata.trigger: "auto" boundary looks like this:

| session | preTokens | minutes since last real user/assistant message |
|---|---|---|
| A | 254,064 / 287,144 | 53 / 53 |
| B | 268,221 / 616,468 / 242,440 / 618,587 / 611,019 | 55 / 56 / 55 / 56 / 56 |
| C | 390,525 / 308,524 / 268,338 / 236,151 | 55 / 55 / 55 / 55 |

11 of 11 fired after ~53–56 minutes of inactivity with context ≥ 200k, none anywhere near the 1M threshold. Five user-initiated /compact runs in session A (trigger: "manual", 508k–760k) show the window itself was fine. That matches the idle path described in #98747 (fires at 90% of the 1-hour cache TTL, context ≥ 200k) and, since 2.1.290, it is logged as auto — which is why it looks like premature threshold compaction.

Workaround that keeps threshold auto-compact on: "idleCompaction": false in settings.json (per #98747). A distinct trigger: "idle" value would make this much easier to diagnose from the transcript.

This is a major regression for my workflows. I tend to run very long sessions and workflows and auto-compact is hurting them. I NEED a way to disable auto-compact.