[Bug]: "Compact next" is selected on a stale Claude thread, but the send goes out uncompacted (desktop, v0.1.3) #27966

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web (desktop composer), possibly apps/server

Steps to reproduce

1. Settings: "Compact idle threads" = When you return (idleCompaction: "onReturn").
2. Run a long Claude thread (claudeAgent, claude-opus-5-5) well past 200K tokens.
3. Leave it idle about 4 hours, far past the prompt-cache TTL.
4. Come back. The composer shows the Compact next pill (tooltip: "Next send compacts N tokens first").
5. Leave it on Compact next and send an ordinary message.

Expected behavior

The send runs /compact first, then delivers the message on the compacted context.

Actual behavior

The message goes straight to the model on the full, uncached history. No compaction turn item is recorded for that run or for the turns after it. The only compaction in the thread is a manual /compact sent later.

Reproduced on two threads at the same time, on two separate environments of the same desktop install (a WSL server and a Windows server), so it is not specific to one thread or one environment:

Diagnosis

• The client never dispatched the /compact. The effect outbox has exactly one provider-turn.start for each stale send (A: 02:53:21.647Z, B: 02:54:11.037Z), for the user's message only. Per Idle compaction is skipped when the server restarts, including for a desktop update, during the wait #27915, the "When you return" path normally dispatches /compact with idleCompaction: "onReturn" first and queues the message behind it. No such turn exists, so the compact-before-send step was skipped before anything reached the server. That points to the web composer's send path, not the server.
• The full cost was paid. The Claude SDK result for each stale send shows the whole history re-written to the cache, with no compact_boundary in the session:
  • A: cache_creation_input_tokens: 615301, cache_read_input_tokens: 12825
  • B: cache_creation_input_tokens: 420385, cache_read_input_tokens: 18270
• In both orchestration_v2_projection_runs rows, contextHandoffId is null and no compaction turn item exists for the run. The only compaction item in each thread belongs to the later manual /compact run.
• The pill showed "Compact next", not "Keep full", at send time on both threads. Nothing was toggled between seeing the pill and pressing Enter.

Impact

Major degradation: the two sends together re-wrote over a million tokens to the cache, and the follow-up turns kept paying on the uncompacted context, while the UI said they would compact first.

Version or commit

Desktop + server 0.1.3 (Windows desktop, servers on Windows and on WSL). I checked the v0.1.4 and v0.1.5 release notes and found no fix for this path.

Environment

Windows 11 desktop app; one server on Windows, one on WSL2 (Ubuntu), both 0.1.3. Provider: Claude (claudeAgent).

Related, but not the same

• [Bug]: Mobile sends skip "When you return" idle compaction #27911 Mobile sends skip "When you return" idle compaction (these sends were from the desktop composer)
• Idle compaction is skipped when the server restarts, including for a desktop update, during the wait #27915 Idle compaction skipped after a server restart (that is about the "before the cache expires" timer; here the compact-before-send fallback itself didn't run, and the Windows server had been up since 2026-10-28)
• [Bug]: Switching from an idle Claude thread to Codex still triggers automatic /compact #25943 / fix(web): scope resume compaction to the selected provider conversation #26142 Claude-to-Codex switch inherits Compact next (no provider switch here)
• [Bug]: Compact idle threads "Never" triggers compaction #26799 "Never" still compacts (the opposite symptom)

Logs or stack traces

orchestration_v2_events had already been pruned for these threads; the outbox rows and provider logs above are what remains. I can share sanitized excerpts on request.