Autocompact thrashing: context refills to limit within ~3 turns of compact, repeats

Symptom

Autocompact is thrashing. In a long-running session, the context refilled to the limit within ~3 turns of the previous compact — three cycles in a row.

Each compact appears to do its job (summary produced, prior turns dropped), but the next ~3 tool calls re-bloat the context back to the limit, forcing another compact. Net effect: rapid cycling between compact → 2–3 turns of useful work → compact, with most of the budget spent on summarization rather than progress.

Hypothesis

A file being read or a tool output is likely too large for the context window. After compact, the freshly-loaded tool outputs immediately push back over the threshold.

Likely culprits in my session:

• MCP tool outputs (Slack channel history dumps, BigQuery result tables)
• Whole-file reads on large files
• Possibly outputs that are summarized into the post-compact context but still oversized

Suggested investigation

• Which tool calls produce the largest payloads post-compact?
• Are tool outputs being truncated before they're folded into the next context window, or carried in full?
• Is there a per-tool-output size cap that should kick in earlier (especially for MCP tools that paginate poorly)?

Suggested mitigations (user-side workarounds)

• Read files in smaller chunks (offset/limit on Read)
• Use /clear to start fresh when the cycle starts

But these are workarounds — the underlying loop shouldn't be possible to enter.

Environment

• Claude Code
• MCP-heavy workflow (multiple Slack MCPs, tool-gateway with BigQuery, etc.)