[BUG] Cowork session transcript lost when interrupting (Esc) mid-stream then sending follow-up — Claude Desktop 1.4758.0.0 (MSIX)

Summary

In Cowork mode, interrupting a streaming assistant response with Esc and then sending a short follow-up message silently wipes the entire prior conversation history. The session becomes unrecoverable: scrolling up shows nothing, restarting the app does not bring it back, and the on-disk JSONL transcript contains only system metadata (no user/assistant messages).

Environment

• Claude Desktop: 1.4758.0.0 (MSIX install)
• Package family: Claude_pzs8sxrjxfjjc
• Install path: C:\Program Files\WindowsApps\Claude_1.4758.0.0_x64__pzs8sxrjxfjjc\app\Claude.exe
• OS: Windows 11
• Mode: Cowork

Steps to reproduce

1. Start a Cowork session and exchange a few turns.
2. While the assistant is streaming a response, press Esc to interrupt.
3. Send a short follow-up message that does not repeat prior context (e.g. "make it shorter", "and also …").
4. The assistant replies as if it has no prior context.
5. Scroll up in the UI — the previous turns are gone.
6. Close and reopen Claude Desktop — the session is not in the resume list.

Expected behavior

• The transcript should remain intact across an Esc interrupt + follow-up.
• The session should remain resumable from the UI after restart.
• Even if the runtime crashes mid-turn, content already streamed should be flushed to disk before the failure.

Actual behavior

• UI loses all prior turns after the Esc + follow-up sequence.
• The session's on-disk JSONL transcript contains only system metadata (~983 bytes), no message content.
• The session does not appear in the resume list after restart.
• Tokens consumed for the lost turns are not recoverable.

Investigation / on-disk state

Two orphaned Cowork sessions from the same time window were found on disk that do not appear in the runtime's session list:

| Session | Transcript | Notes |
|---|---|---|
| local_307fcd79-bb64-475c-8b99-b733bbdad0b0 | none (only an MCP log of 2 KB) | Earliest, ~10:04 UTC |
| local_313fe124-9a4d-4805-9470-f76dbf12a902 | 3fbce702-fd8c-4b11-89cd-d1f05cb52be8.jsonl, 983 bytes — system headers only, no messages | ~10:16 UTC, the actual lost conversation per user recall |

Locations (under MSIX redirection):

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions\
  <workspace-id>\<account-id>\local_313fe124-…\.claude\projects\…-outputs\
  3fbce702-fd8c-4b11-89cd-d1f05cb52be8.jsonl

This suggests the runtime does not flush the transcript to disk until after the first complete turn, and the Esc + follow-up code path drops the in-memory turn before persisting it. The session ID is also lost from the resume index.

Possibly related issues

• #53067 — onSessionRestored is undefined when XJ7({ enabled: false }) is invoked; resume crashes with FKH is not a function.
• #53044 / #53121 / #53284 / #53568 — same family of UKH/FKH is not a function errors on claude --resume in CLI 2.1.120.

The Claude Desktop runtime appears to share the underlying claude-cli-nodejs code path (cache directory LocalCache\Local\claude-cli-nodejs\Cache\… is present). If the same hook returns undefined here, an exception during resume / mid-turn could silently drop the in-memory session before it is written to disk.

Impact

Conversation is lost mid-task. Tokens are billed, no usable result, and the session cannot be reconstructed. Users have to manually start over.

Workaround (current)

• Avoid pressing Esc during a streaming response.
• For long / important conversations, periodically copy the chat into a local file as a backup.

Asks

• Persist transcripts on every turn boundary (or sooner — at least on every assistant token chunk's end-of-stream).
• Make the resume index repair itself by scanning local-agent-mode-sessions\ on startup so that on-disk sessions cannot become unreachable from the UI.
• Guard the onSessionRestored call site (FKH?.(K)) per the fix already discussed in #53067.