fix(composer): compact context without clearing the draft

[incognitojam]

Note

TL;DR: Compact context and the resume banner's Compact now work while a draft is in the composer, and the draft is left untouched. /compact is sent as its own turn instead of being typed into the draft. Upstream has an equivalent fix that depends on a larger compaction chain; this function gets replaced when that chain is taken in.

Problem

Compact context in the context meter, and Compact on the resume-compaction banner, were disabled whenever the composer held a draft, with the tooltip "Send or clear your draft before compacting". That was deliberate: compacting worked by overwriting the draft with /compact and submitting it through the normal send path, so any half-written message would have been destroyed.

Fix

ChatView now has a dedicated onCompactContext that sends /compact as its own turn. It never reads or clears the composer draft, and it omits composerDraftRevision, so the server does not clear its autosaved copy of the draft either. The draft check is removed from compactDisabled, and both entry points (context meter and resume banner) call the new function. ChatComposer no longer injects /compact into the draft, which also removes the compactContext handle method and the pasted-image-compression guard that only existed because compacting used to snapshot the draft.

docs/user/providers-claude.md gains one sentence saying compacting leaves a draft in place.

Surfaces: web and desktop share this code. Mobile has no Compact button. Only the Claude provider offers compaction. The server and wire contracts are unchanged.

Relationship to upstream

Upstream fixes the same bug with the same design in pingdotgg/t3code#11103. That change cannot be taken on its own: it edits code introduced by pingdotgg/t3code#9293, which moves compaction into a server-side command and adds it for Codex, OpenCode and mobile, and is followed by pingdotgg/t3code#9623, pingdotgg/t3code#10112 and pingdotgg/t3code#11107. This PR is a fork-written fix for the current client-side /compact path and is not a port of any of them, so it does not mark them as taken in. When that chain is taken in, replace onCompactContext in ChatView.tsx with the upstream version; the code comment says the same. For that reason there is no fork feature ledger entry.

Before / after

Same thread, same draft in the composer, context meter open.

Before	After

After clicking Compact context with the draft present: /compact is sent as its own message and the draft is still in the composer. (Claude answered "Not enough messages to compact" here because this small thread had already been compacted a moment earlier.)

Verification

Exercised in a headless Chromium against an isolated dev server (worktree-local state seeded from a snapshot), in a fresh Claude Sonnet 5 thread in a scratch project:

• With a draft typed in the composer, Compact context was enabled. Clicking it produced exactly one /compact user message and the compaction turn ran to completion ("Worked for 31s").
• The draft text was intact immediately after the click, after compaction finished, and after a full page reload (so the server-side autosave was not cleared).
• The preserved draft then sent normally and the composer cleared.
• Compact context with an empty composer still works and leaves the composer empty.
• No new browser console errors; the only ones seen were two HTTP 400 resource-load errors that appear on every page load, including before any interaction.

Focused checks: tsgo --noEmit for apps/web, vp lint on the changed files, and ContextWindowMeter.test.tsx / ComposerBannerStack.test.tsx pass.

Not verified: the desktop Electron shell was not run separately (it wraps the same web code), and the resume-compaction banner's Compact button was not clicked in the browser because the scratch thread was too small to trigger the banner; it calls the same function as the meter button.

---

Written by an agent (Claude Code, claude-fable-5-1).