[BUG] archive_session's "live work" refusal names four causes and identifies none

What's wrong

mcp__ccd_session_mgmt__archive_session refuses with a message that enumerates four possible causes and identifies none of them:

Session self ("<title>") was not archived: it still has live work
(an agent run, a Remote Control client, a queued message or a background task).
Wait or ask the user; they can also archive it from the sidebar.

The four causes have different remedies, and two of them are invisible from inside the session:

| cause | can the calling session see it? | does waiting clear it? |
| --- | --- | --- |
| an agent run | sometimes (its own task list) | yes, if it is really running |
| a background task | yes | yes |
| a Remote Control client | no | no, the user must disconnect |
| a queued message | no | no, it is consumed on the next turn |

So a session that has checked everything it can reach and found nothing is left with two candidates it cannot inspect, and the reasonable conclusion is that the block is on the user's side. In the case below that conclusion was wrong, and the session told the user so, twice, in writing.

Not a duplicate of #93259. That issue is about the third branch of the same message builder, where pinned and on_screen collapse into "pinned or in use", and its suggested fix splits those two. This is the losable_work branch, which that fix does not touch. Fixing #93259 as written leaves this message exactly as it is. I have not disassembled the bundle myself, so I am taking the code shape in #93259 on its author's authority, but the name it quotes, losableWorkKind(...), suggests the app already computes which kind and the message builder discards it.

What should happen

Render the specific kind, and say whether waiting can clear it:

• agent run → … still has an agent run in progress. Wait for it, or stop it with TaskStop.
• background task → … still has a background task running. Wait for it, or stop it.
• Remote Control client → … has a Remote Control client attached. Ask the user to disconnect it, or archive from the sidebar.
• queued message → … has a queued message waiting. It will clear on the next turn.

Even collapsing to two buckets (something you can act on, something only the user can) would be enough to stop an agent reporting the wrong cause.

Steps to reproduce

The general shape is any losable_work hold. The one I measured is reliable and also, I think, a bug in its own right:

1. Start a Workflow with enough agents that several run concurrently.
2. Stop it with TaskStop while agents are mid-run.
3. Call archive_session with session_id: "self". It refuses with the message above, and keeps refusing for the rest of the session's life.

Step 3 never recovers, because the aborted workflow leaves agent runs registered as started with no terminal record. Nothing is actually running. I am reporting the message here rather than the leak, to keep this to one bug, but the leak is the reason the message's ambiguity was expensive rather than merely untidy, and it may deserve its own report.

Measured

One session, a private repo, 2026-09-10 (all times UTC). Two workflows ran; the second was aborted at 04:53:03.247Z with status: killed, error: Error: Workflow aborted.

Journal counts from ~/.claude/projects/<project>/<session>/subagents/workflows/<runId>/journal.jsonl, with the completed workflow in the same session as the control:

| workflow | started | result | failed | outstanding |
| --- | --- | --- | --- | --- |
| completed | 56 | 50 | 6 | 0 |
| killed | 95 | 87 | 4 | 4 |

The four orphaned agents each stopped writing between 04:51:54Z and 04:53:03Z, at the abort, and nothing in that directory was written afterwards. So from the first archive attempt onward there was no live process.

Five archive_session calls, all with the literal "self", all refused with the identical message: 05:00:45, 05:01:10, 05:31:55, 05:40:43, 05:43:23. Archiving from the sidebar worked at about 05:43:57.

The misleading part. A second TaskStop on the killed workflow's task id answers No task found with ID: <id>, which reads as terminal and is not: the task record is gone, which is what a kill does, and it says nothing about the agents that task spawned. With TaskStop reporting clean, ps clean, and the refusal naming two causes it cannot see, the session concluded the user had a Remote Control client or a queued message holding it. It had neither.

For what it is worth on the actionability question: that session had counted the journal itself and printed outstanding = 4 seven minutes before its second refusal, and discarded the number because TaskStop had contradicted it. A message that named the cause would have settled it in one line.

Environment

• Claude Desktop 1.49585.0 (macOS 26.6.2, build 25G83, arm64)
• Claude Code CLI 2.1.146. Not the latest (2.1.267 at the time of filing); flagging that rather than ticking the box, since I have not retested on it. The handler in question appears to be the desktop app's rather than the CLI's, so I do not expect the CLI version to matter, and I could not confirm that: the sentence does not appear as a literal in app.asar or the CLI binary, which matches #93259's note that it is assembled from a template with interpolation.
• Platform: Anthropic API

Related

• #93259: the same message builder, different branch (pinned / on_screen). Worth fixing together.
• #82151: a turn ending with background tasks still running and no signal. Adjacent: same underlying registry, opposite symptom.