Summary

When a session is over the context budget AND has been compacted recently, shouldCompact() returns false to prevent infinite compaction loops. This is correct logic, but there's no fallback — the session becomes permanently blocked with no path to recovery except manual reset.

Reproduction

1. User has an active conversation accumulating context
2. At timestamp T+0: context hits 115K tokens (budget) → compaction runs → succeeds
3. At timestamp T+5min: context hits 115K tokens AGAIN (rapid accumulation)
4. Compaction checks: "already compacted recently" → returns false
5. Session enters blocked state — messages are queued but never processed
6. User is told "message not done" with no indication of why

Current Code

// proxy-72wW6ush.js:2067-2070
shouldCompact() → contextTokens > contextWindow - reserveTokens
// No cooldown, no fallback path

When compaction rejection happens, the session manager has no reset() or forceCompact() alternative.

Proposed Fix

1. Add a "stuck" detection: if session is over budget AND last compaction was >2min ago AND still over budget → auto-reset as last resort (notify user)
2. Or: emit a system event to the chat saying "Session is full, starting fresh" and auto-rotate
3. Track consecutive compaction rejections — after 3 rejections without recovery, force session reset

Related

• fix(auth): align resolveClawdbotAgentDir() with multi-agent path #337/OAuth credentials saved to wrong path - WhatsApp auto-reply fails to find them #338 (5-prong bloat defense)
• 🐛 Telegram Bot uses deprecated parse_mode: "Markdown" instead of "MarkdownV2" #311 (original compaction issues)

Severity

P1 — main session was blocked for 20+ minutes today, user couldn't get responses

Closes via PR from apex-workspace