[BUG] Scheduled task runs report "succeeded" when they were aborted at a permission prompt or produced no output

Summary

A scheduled-task run reports status: "succeeded" in list_task_runs and in the Runs pane even when the run did no work at all — it was aborted at its first permission prompt, or produced no final output, or hung. There is no status that distinguishes these from a real success.

The practical consequence: the run status cannot be used to tell whether a routine is healthy, so anything built on it — including a user's own monitoring — is silently blind.

How we found it

A full audit of 20 local scheduled tasks (2026-09-14) found 4 that had never once completed their work. Every one of their runs showed succeeded. Not a single failed.

Their transcripts showed the real outcomes:

• 3 runs of one task aborted at the first tool call needing approval: Tool permission request failed: AbortError
• 2 other tasks aborted mid-run the same way
• A one-time task aborted on its very first command

Re-checking history turned up 4 more older tasks that had likewise been aborted or had hit the weekly usage limit — again, all succeeded.

The four shapes that all look like success

| What actually happened | Reported status |
|---|---|
| Aborted at a permission prompt with nobody present | succeeded |
| Ran but produced no final assistant message | succeeded |
| Hung on a single tool call for hours (see the companion issue on archive_session) | succeeded |
| Hit the weekly usage limit | sometimes failed, often not distinguishable |

Expected

At minimum, expose enough to tell these apart. Some options, roughly in order of usefulness:

1. A distinct terminal status for runs that were interrupted, e.g. interrupted / aborted, separate from succeeded.
2. A boolean or count on the run record for "tool calls that failed with a permission error".
3. A flag for "the run produced no final assistant message" — cheap to compute and catches most of these.

Any one of these would let a user (or a monitoring routine) answer "did my scheduled task actually do its job?" without parsing transcripts.

Current workaround, for context on the cost

We had to write a transcript reader that opens each run's .jsonl, counts tool_result blocks with is_error and Tool permission request text, checks for usage-limit strings, and checks whether any final assistant text exists. That is the only way we found to get ground truth. It works, but it depends on internal file layout and message structure that carry no compatibility promise — so the monitoring is one app update away from silently going green while everything is broken.

Environment

• Claude Code Desktop app (macOS 26.5), CLI 2.1.263
• Local scheduled tasks created both through the app and through the scheduled-tasks MCP tools

Related: #91724 reports the user-visible side of one of these cases (a routine wedged on an unanswered permission prompt) — this issue is about the fact that the run's reported status gives no indication anything went wrong.