Desktop: archiving a session mid-turn kills its worker instantly with no confirmation — and leaves no interruption marker in the transcript

Summary

In the Claude desktop app (Code tab, macOS), archiving a session from the sidebar takes effect immediately — no confirmation dialog, no undo toast — even when the session is actively running a turn. Measured on a live session (details below): the per-session worker was killed mid-turn within a second of the click, holding four tool results that had not yet been acted on, and the transcript was left with no marker that an interruption ever happened.

The product already treats this action as approval-worthy when Claude performs it. The shipped archive_session tool description says, verbatim:

This tool ALWAYS prompts the user for confirmation. Only call it after the user has explicitly agreed to archive a specific session — never speculatively.

So the current bar is: agent-initiated archive → mandatory approval card; human misclick on a running session → zero friction. The app also already shows a confirmation modal for Delete. Archive is the odd one out.

What happened

I misclicked "Archive" on a session that was in the middle of a turn. It disappeared from the sidebar instantly. I reopened it and asked the resumed session to reconstruct what had happened from its own transcript and process state (all times JST, 2026-08-22):

| | Evidence |
|---|---|
| Worker killed mid-turn | Worker PID 72057 was recorded alive at 05:12. After the archive, a new worker PID 98978 was running, started 05:22:32. The parent Claude.app process (PID 96989) had been up since the previous day — only the per-session worker was killed. |
| Where in the turn | Last tool_result at 05:21:50 (four parallel Read/Bash calls had just returned). The Write that should have followed never fired. Next transcript entry: 05:22:33. |
| No interruption marker | In that window the transcript contains zero entries with interrupted: true, isApiErrorMessage: true, or any error/abort record. The only trace is an isMeta: true user entry — "Continue from where you left off." — which is byte-identical to an ordinary resume/compaction prompt. |
| What the agent saw | The resumed session treated the meta prompt as a normal resume, replied "No response requested", and went silent. It learned it had been archived only because I typed an apology two seconds later. Its own summary: "without the human's statement, neither I nor the transcript would contain any information that an interruption occurred." |
| Data loss | None — by luck. The kill landed between a batch of reads and the first write. One turn later it would have interrupted an in-progress edit/commit. |

Why this deserves a guard

1. Asymmetry with the agent path. archive_session always prompts (quote above); the human click never does. Same destructive operation, opposite friction.
2. Asymmetry with Delete, which does show a confirmation modal in this app.
3. The interruption is invisible to the agent and to the record. Because the resume prompt is indistinguishable from a normal continuation, no hook, script, or post-hoc check can detect that a turn was cut. The human's memory is the only evidence. That makes "just undo it afterwards" insufficient — you first have to know something was cut.
4. Archive is effectively one-way in the desktop UI (#67835), so a misclick reads as losing the session rather than filing it.
5. This is a data point for the open question in #83718 / #75548. #83718 reports the background process keeps running after archive; #75548 reports auto-archive terminates in-flight work. On app 1.34493.1 / worker 2.1.237, a manual sidebar archive definitively kills the worker within ~1 s. Reporting in case it helps reconcile those two.

Requested behavior

Any one helps; the first is the minimal version:

• Confirm before archiving a running session. Show a dialog when the target has isRunning: true, stating that its in-flight turn will be terminated. A "don't ask again" checkbox keeps it out of the way for users who archive frequently. (Idle sessions could stay one-click.)
• Undo toast after archiving ("Session archived — Undo"), keeping the action one-click for intentional use while making misclicks recoverable.
• Write an interruption marker into the transcript when a session is archived mid-turn (e.g. a meta entry distinct from the plain "Continue from where you left off."), so the resumed session — and any tooling reading the JSONL — can tell a cut turn from a normal resume. Today it cannot.

The batch/at-scale case is already covered by #82781 and is not what this asks for.

Environment

• Claude desktop app 1.34493.1, macOS (Darwin 25.5.0), Code tab
• Embedded worker 2.1.237 (transcript entrypoint: claude-desktop); a separate CLI install on PATH is 2.1.198 and was not involved
• Single machine; archive clicked in the same app instance that was running the session

Related issues

• #87477 — the same confirmation request for the context-menu case (filed 2026-08-18, closed by the triage bot 2026-08-21 as "doesn't appear to be about Claude Code"). These are Claude Code sessions in the desktop app's Code tab, the same surface as #75548, #81064 and #69457, all triaged here under area:desktop. Re-filing with the mid-turn measurements and the transcript-marker request, which that report did not cover.
• #67835 — archive is one-way: no unarchive path / Archived view in desktop.
• #69457 — X button on home screen session cards archives the session (different trigger, same missing guard).
• #75548 / #83718 — conflicting reports on what archive does to a running process; see point 5.
• #82781 — bulk archive with a single confirmation (distinct: at-scale, not the missing single-session guard).

Happy to share the redacted transcript excerpt around 05:21–05:23 or test a fix.