[Bug]: Stop still kills the Claude CLI and `--resume`s, so every Stop rewrites the full prompt cache (not covered by #10689)

[willmarkman]

Before submitting

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

Closest existing reports: #10600 (closed by #10689, which only fixed the idle-reaper clock and says "Claude cache invalidation after a genuine restart is unchanged"), #7338 (closed, asked for hard evidence), #8997 (the interrupt-instead-of-close fix, closed unmerged). This is the Stop half of #10600 that the triage there listed as still forcing a --resume.

Area

apps/server

Steps to reproduce

1. Start a Claude Code thread and let it run a few tool calls so the context is a few tens of thousands of tokens.
2. Press Stop while a tool call is running.
3. Within the cache lifetime (I waited two minutes) send a follow-up in the same thread.
4. Open ~/.claude/projects/<project>/<session-id>.jsonl and compare cache_read_input_tokens / cache_creation_input_tokens on the assistant messages before and after the Stop.

Expected behavior

Stop interrupts the in-flight turn and keeps the CLI process, so the follow-up continues with the same prompt prefix and hits the cache. This is what native Claude Code does on Esc: it appends [Request interrupted by user] and the process stays up.

Actual behavior

Stop goes through interruptTurn → stopSessionInternal → query.close() in apps/server/src/provider/Layers/ClaudeAdapter.ts (the code comment calls Stop a hard session boundary). The next message --resumes a new process and the whole prompt is re-sent as a cache write.

Per-turn usage from the transcript, deduplicated by message id:

Time	Event	cache_read	cache_creation
14:59:33	last turn before Stop	66,247	1,839
15:01:34	Continue from where you left off. meta + <synthetic> reply	0	0
15:01:44	first turn after follow-up	0	75,181
15:02:01	next turn	75,181	628

One Stop rewrote 75k tokens that were cached two minutes earlier. That single turn cost more than the rest of the six-minute session combined, and it scales with thread length. The idle reaper was not involved (two-minute gap), so #10689 does not touch this path.

An extra trigger beyond the git status one in anthropics/claude-code#78720: with the follow-up message the resumed process received a deferred_tools_delta adding claude.ai connector tools (Gmail) and a mcp_instructions_delta appending Linear / Notion / PostHog instruction blocks. Connectors reconnecting late in the fresh process change the system prompt by themselves, so the miss happens even in an untouched repo.

Impact

Major degradation or frequent failure

Version or commit

0.0.41-nightly.20260909.1439 (includes #10689)

Environment

macOS 27.0.0, T3 Code Nightly desktop. Bundled Claude Code 2.1.266 (entrypoint: sdk-ts). Model claude-fable-5-1. Claude subscription, 1-hour prompt cache.

Logs or stack traces

14:59:33 assistant cache_read=66247 cache_creation=1839
15:01:34 user (isMeta) "Continue from where you left off."
15:01:34 assistant model=<synthetic> "No response requested."
15:01:38 user "fetch latest from gh, ..."
15:01:38 attachment deferred_tools_delta addedNames=[mcp__claude_ai_Gmail__..., ...]
15:01:38 attachment mcp_instructions_delta addedNames=["claude.ai Linear","claude.ai Notion","claude.ai PostHog"]
15:01:44 assistant cache_read=0 cache_creation=75181
15:02:01 assistant cache_read=75181 cache_creation=628

Full transcript lines available on request.

Workaround

Don't press Stop. Disabling cloud connectors in Claude Code settings (disableClaudeAiConnectors: true) removes one source of prompt mutation but not the restart itself.

[juliusmarminge]

Triage

Confirmed. This is the Stop half of #10600, and #10689 does not cover it.

#10689 only fixed the idle-reaper clock (lastSeenAt vs session updatedAt). Its PR text says Claude cache invalidation after a genuine restart is unchanged. Two minutes after Stop is well inside the 30-minute idle window, so the reaper was not involved.

What current main does

Stop (apps/server/src/provider/Layers/ClaudeAdapter.ts):

• interruptTurn calls stopSessionInternal, which query.close()s the CLI. The comment calls Stop a hard session boundary: interrupt() can ack while resumed background tasks keep the process alive (the fix(server): stop kills lingering Claude work #5891 runaway-fleet case).
• Tests assert that contract: interruptTurn settles live tasks and closes the provider session.

Follow-up (ProviderService.sendTurn → recoverSessionForThread):

• After close, hasSession is false, so the next message starts a new process with the persisted resumeCursor.
• startSession passes resume: existingResumeSessionId (SDK --resume).
• That is a genuine restart. Claude then re-sends the whole prompt as a cache write.

That matches the transcript: last turn cache_read=66,247; first turn after Stop cache_read=0 / cache_creation=75,181; next turn reads the new 75k prefix. Native Claude Code keeps the process up on Esc and appends [Request interrupted by user].

The deferred_tools_delta / mcp_instructions_delta on the resumed process is a second prefix mutation on top of the git status case in claude-code#78720. Disabling connectors removes that mutation but not the restart. Cache invalidation after restart is Claude CLI behavior; T3’s Stop teardown is what forces the restart.

What this is not

• Not a duplicate of [Bug]: Idle session teardown can trigger full Claude prompt-cache rebuilds after repository changes #10600 (closed; reaper-only).
• Not fix(claude): guard completed agent resumes #9130 (sub-agent SendMessage resume guard).
• Not an explanation of the no-restart A/B in [Bug]: Extremely high usage #7338. Keep that closed.

Related

• fix(server): stop kills lingering Claude work #5891 merged — Stop started closing the query so leftover background work could not outlive Esc.
• fix(server): keep Claude CLI alive across Stop #8997 closed unmerged — keep-alive across Stop. Review blocked it on delayed interrupt of a newer turn, a subagent started during interrupt(), leftover SDK result completing the next turn, and pending approvals / AskUserQuestion left open.
• Other teardown → --resume paths still exist: idle reaper, explicit session stop, server update / stopAll, effort / session replacement. Out of scope here.

Next step

T3-actionable: keep the Claude CLI alive across Stop.

Revisit the #8997 approach (stopTask + query.interrupt(), complete the local turn, keep the process; close() only if live tasks remain) and address those review findings. thread.session.stop and the idle reaper should still tear the process down.

Do not reopen #8997 as-is. The #5891 close-on-Stop behavior has to stay as the fallback when cooperative interrupt cannot settle live work.

Workaround remains: don’t press Stop. disableClaudeAiConnectors: true only removes one prefix-mutation source.

Severity: major for long Claude threads (full prefix rewrite per Stop; scales with context). Not a crash, and not an established subscription-quota percentage.