[BUG] archive_session with session_id "self" hangs for hours in scheduled runs, delaying other scheduled tasks

Summary

When a scheduled task ends by archiving its own session — mcp__ccd_session_mgmt__archive_session with session_id: "self" — that single tool call can take hours to return. Measured gaps between the tool_use and its tool_result, from transcripts: 1h58m, 3h52m (a Bash call, see below), 4h38m, and 7h09m.

The run does eventually complete and reports succeeded / archived: true. Nothing fails. But while it hangs, the session appears to occupy an execution slot, and other scheduled tasks due in that window do not start until it returns.

Environment

• Claude Code Desktop app (macOS 26.5), CLI 2.1.263
• Local scheduled tasks, permissionMode: auto (verified in the run metadata — this is not a permission prompt waiting for an answer)
• Machine awake throughout (pmset -g log shows no Sleep/Wake events in the affected period)

Evidence

A daily task that normally takes 2–4 minutes took 7h09m two days in a row. Its transcript shows one gap of 25,7xx seconds, sitting exactly between the archive_session tool_use and its tool_result. Everything before that gap ran in ~30 seconds.

Removing the self-archive step fixed it completely. Same task, same prompt otherwise, triggered manually: 32 seconds, start to finish. That is the whole delta — the work was never slow, the archive call was.

The knock-on effect on other tasks. On 2026-09-15 (local time):

| Task | Scheduled | Actually started | Note |
|---|---|---|---|
| Task A (daily) | 11:38 | 11:38 | ran, then hung 4h38m in archive_session, returned 16:18:32 |
| Task B (one-time) | 12:30 | 16:23 | its first Bash call sat undispatched for 3h52m |
| Task C (daily) | 13:08 | 16:19:34 | ~3h11m late |
| Task D (daily) | 13:34 | 16:19:34 | ~2h45m late |

Tasks C and D both started at the same second, ~62 seconds after Task A's archive call finally returned — i.e. on the next scheduler tick after the slot freed. C and D each then completed normally in 2–3 minutes.

Task B is worth calling out separately: the hung call there was a plain Bash, not archive_session. The command began with date, and the date output printed 3h52m after the model emitted the call — so the delay is in dispatching the call, not in executing it. A timeout wrapper inside the command cannot help.

Why this is worse than it looks

Many task prompts follow the pattern "if there's nothing to report, archive the session". If archiving is the last step and no chat message was written first, the user sees nothing at all for up to 7 hours — indistinguishable from a dead task. We only found it by diffing timestamps inside the raw transcript.

Expected

• archive_session returns in a bounded time, or fails fast.
• A hung tool call in one scheduled session should not delay other scheduled tasks — or, if there is an intentional concurrency limit, it should be documented so schedules can be planned around it.

Repro sketch

1. Create a local scheduled task whose final step calls mcp__ccd_session_mgmt__archive_session with session_id: "self".
2. Set permission mode to auto so nothing is waiting on a human.
3. Let it run unattended; compare createdAt / lastActivityAt in the run metadata against the actual work done in the transcript.

Related: #91724 describes a different failure (unanswered permission prompt) with a similar user-visible symptom — a routine that appears stuck with no way to tell "still working" from "wedged".