A setting to turn off compact-before-send on stale Claude threads

[yashaka]

Problem

Since #16631 (and its chip form, #17127), a Claude thread with 100k+ tokens that has been idle for 70+ minutes compacts on send: Enter runs /compact first, then sends the message. The chip/menu lets me skip that for one send, and the choice resets (per thread, and on reload/remount).

For some workflows compaction is never the right default. I keep long-lived agent sessions whose state I manage outside the transcript (durable notes in the repo, re-read on resume), and I deliberately resume old threads with full history, accepting the cold-cache cost. For me an accidental Enter is an irreversible loss of the conversation's working context — and the default is the destructive path on every stale thread, every time.

There is already a permanent off switch in the code — the t3code:resume-compaction-dismissed:<environmentId>:<providerInstanceId> localStorage flag — but the only UI path that sets it is answering "Don't ask again" on Claude's own resume dialog, which (per the #16631 notes) practically never appears under the v2 orchestrator. Today the only way to turn the offer off is DevTools → localStorage.setItem(...) per environment and per client.

Proposed behavior

A client setting, e.g. Settings → General → "Compact stale Claude threads before sending" (on by default is fine), that:

• when off, never shows the Compact chip and never prepends /compact — sends always keep full history;
• maps to (or replaces) the existing dismissal flag, so it applies across environments viewed in that client;
• leaves Compact context in the context meter available for an explicit compaction.

Related: #17111 (the chevron that offers the opt-out does nothing in a resting composer, so every send compacts).

[moinmir]

Would like this to be configurable as well.

[Zedyas]

+1. This is an issue I'm facing in T3 Code right now. Here is data from my own threads, plus one gap I don't see covered here yet.

Data (nightly builds from Oct 8–9; current build 0.0.46-nightly.20261008.2849). Each row is a pre-send /compact from the chip. My actual message followed 17–56 ms later and went into the queue. All are Claude threads with a 1M context window, and Auto-compact after is set to 500000.

When (UTC)	Tokens in context	Idle before send	What happened
Oct 8 13:47	423,515	847 min	I stopped it after 12 s
Oct 8 13:49	460,668	835 min	I stopped it after 6 s
Oct 8 18:36	350,594	213 min	I stopped it after 12 s
Oct 8 22:25	138,028	74 min	I stopped it after 5 s
Oct 9 00:31	272,206	99 min	I stopped it after 6 s
Oct 9 01:14	113,327	158 min	compacted before I noticed
Oct 9 03:06	111,770	82 min	I stopped it after 3 s
Oct 9 03:08	200,591	76 min	I stopped it after 13 s

Each time, I pressed Enter to reply to the agent, not to compact.

Gap not covered yet: the 100K threshold ignores "Auto-compact after". All 8 were below the 500K limit I set on purpose to keep long sessions intact. Compact-before-send uses a fixed 100K threshold and never reads autoCompactWindow.

What would fix it for me:

1. The persistent setting proposed here (feat(web): add a setting to turn off compact-before-send for old Claude threads #17234 implemented it; its author closed it without merging).
2. When autoCompactWindow is set, compact-before-send only applies at or above that value.