Autocompact never fires proactively at the context edge — autonomous/headless sessions park until the next user message (desktop app + Agent SDK)

Summary

Autocompact never fires proactively when a session reaches the context edge. It fires only lazily, at the start of the next incoming turn (user message, hook/notification, or scheduled wakeup). A session that hits the edge with no future input source parks there indefinitely — this silently kills long-running autonomous/headless sessions overnight.

This affects both the desktop app and applications embedding the Agent SDK. Since the harness is closed source we can't tell which layer owns the compaction trigger (CLI core vs desktop app vs SDK) — part of the ask is clarifying that.

Environment

• Claude Code v2.1.205, Windows 11 Pro (10.0.26200)
• Desktop app (entrypoint: claude-desktop), model claude-fable-5 (200k window; also reproduced with non-1M models via the Agent SDK)
• Long-running autonomous session (background subagents + scheduled wakeups)

Evidence (from one overnight session transcript, 2026-07-14)

The session JSONL shows six compact_boundary events across the night. Every one fired at next-turn start, immediately after a new input arrived — never at the moment the context threshold was crossed:

| compact_boundary (UTC) | Trigger immediately preceding it |
|---|---|
| 05:05:47 | incoming input (next turn start) |
| 07:02:31 | incoming input (next turn start) |
| 10:25:32 | incoming input (next turn start) |
| 12:52:01 | task-notification at 12:47 → turn grew to peak 168,184 tokens at 12:49 → compacted at next turn |
| 13:47:51 | task-notification at 13:45:53 |
| 14:50:51 | user message at 14:48:24 — context had been sitting at ~165k since 14:42 with nothing pending; compaction fired only because the user manually sent a message |

The session only survived the night because it happened to keep receiving subagent completion notifications and had self-scheduled wakeups. When the model instead reaches the edge mid-turn, we've previously lab-verified the turn is silently cut (stop_reason: tool_use, no error surfaced) and compaction defers to the next query — in an autonomous session with nothing else inbound, that next query never comes and the session appears "crashed" until a human types something.

Agent SDK reproduction

Our application embeds the Agent SDK to run many concurrent sessions. Same behavior: sessions that approach the window edge stall and never resume on their own. We attempted to mitigate by forcing the autocompact setting on for every session that isn't on a 1M-context model — no effect; the stall still occurs.

Expected

Compaction should fire proactively when the threshold is crossed — either immediately (in-place, which the CLI demonstrably can do since it sometimes compacts mid-turn) or at latest at the end of the current turn — rather than waiting for a future input that may never arrive.

Ask

1. Trigger autocompact eagerly at threshold-crossing (or end-of-turn), not lazily at next-turn start.
2. If the turn is cut at the edge, surface it (error/event) instead of a silent stop_reason: tool_use cut.
3. Clarify which layer (CLI core / desktop app / Agent SDK) owns the compaction trigger so embedders know where the fix lands and whether an SDK-side workaround exists today.