Scheduled task sessions hang indefinitely (isRunning stuck true, zero progress, no error) - two confirmed triggers fixed, hang persists

## Summary

A Claude Code scheduled task (Claude Code Desktop's "scheduled-tasks" feature, cron-based) repeatedly hangs indefinitely a few tool calls into every run — `isRunning: true` forever, `lastActivityAt` frozen within ~10-15 seconds of session start, zero further tool calls logged, no error surfaced anywhere, for hours (observed up to 9+ hours before being manually stopped). This has happened on essentially every run of one specific scheduled task for several days running.

Two distinct, independently-reproducible triggers were found and fixed at the project-content level, but the hang **persists after both fixes**, via a third, unidentified cause — which is why I'm filing this rather than continuing to patch around it.

## Environment

- Claude Code Desktop app, Windows 11
- Model: `claude-sonnet-5`
- Feature: scheduled tasks (`mcp__scheduled-tasks__*` / a cron-triggered `SKILL.md`-driven session), triggered both on its normal cron schedule and manually via "Run now"
- The task's own project has a `.claude/settings.json` with a Bash permission allowlist (specific `bun run:*` / `python ` patterns)

## Confirmed contributing cause #1 (fixed, insufficient alone)

The scheduled task's instructions had it `Read` a JSON state file that had grown to ~9 MB. Reproduced directly: an interactive `Read` tool call with no `limit`/`offset` on a file that size returns an immediate hard error:

```
File content (9MB) exceeds maximum allowed size (256KB). Use offset and limit
parameters to read specific portions of the file, or search for specific
content instead of reading the whole file.
```

That error is clean and immediate in an **interactive** session. In the **scheduled/headless** session, every observed hang froze right around the point in the instructions where this same Read would occur (3 tool calls in, matching "read file A, read file B, read the oversized file"). Rewriting the task to never `Read`/`Write`/`Edit` that file directly (routing all access through a small helper script instead) removed this specific trigger — but a fresh run **still hung afterward**, at a different point.

## Confirmed contributing cause #2 (fixed, insufficient alone)

One hung run's transcript showed it calling a UI/session-organization tool (specifically, a "mark a chapter in the interactive transcript" tool intended for interactive sessions) as an early step, then freezing immediately — before doing anything else, including any file access. A headless scheduled session has no UI to show such a thing to, and the tool call appears to simply never return. Explicitly instructing the task not to call any UI/session-management tools removed this specific trigger — but again, a fresh run **still hung afterward**.

## Residual issue (not fixed, not diagnosed)

After both fixes above were live, two more fresh runs of the same task were triggered and **both hung again**, each at a different point (2-3 tool calls in), involving neither of the two causes above. The pattern across every hang observed (roughly 8 separate occurrences over 3 days):

- `isRunning` stays `true` indefinitely (one instance was left running 9+ hours with zero progress before being manually stopped)
- `lastActivityAt` freezes within ~10-15 seconds of session creation
- No error, warning, or partial tool-call request is ever visible via the session's event log (`list_events`-equivalent) — the transcript simply stops advancing
- The specific tool called immediately before the freeze differs between occurrences (sometimes a plain file read, sometimes a Glob, sometimes a session-management tool call) — there's no single reproducible "last call" signature once the two causes above are excluded

## What was ruled out

- **Not a Bash-permission-approval deadlock in the way we initially assumed.** The project's own troubleshooting notes (written after the first couple of hangs) assumed an unapproved Bash pattern was blocking on a permission dialog nobody could answer. Every hang actually observed froze *before* any Bash call appears in the transcript at all — right after plain `Read`/`Glob` calls that don't require approval. This doesn't rule out a permission block on a later call whose *request* was never logged, but it means the original theory was unconfirmed, not settled, and two rounds of "find a concrete trigger and fix it" (see above) still didn't clear the underlying issue.
- **Not resolved by reducing concurrent session load.** The account had ~49 concurrent sessions (interactive, "Remote Control" from another device, and "cloud" type) at the time of investigation, several related to troubleshooting this same recurring hang. ~20 stale local sessions were archived (down to 42 total), and the scheduled task was retriggered — it hung again, at the same early-freeze signature, within the same few minutes.

## Ask

Is there a known failure mode where a scheduled/headless Claude Code session can silently stall a few tool calls into a run, with no error surfaced to the session's own event log? If so, what causes it, and is there a way to inspect a live-hung session for whether it's actually blocked on a pending approval prompt versus wedged at the infrastructure level? Right now the only visible signal is "no further activity, ever," which is indistinguishable between "waiting for something that will never come" and "genuinely dead."

Happy to provide more detail (exact tool-call sequences, timestamps) on request — omitted here since they reference private project content, but the pattern above is what's reproducible.

Start with the cron-triggered SKILL.md and the project's .claude/settings.json, then reproduce a hang while inspecting the live session through its event log or list_events-equivalent. Compare runs after removing the oversized JSON Read and UI/session-management call, and determine whether a pending approval is observable. Done means the stall has a reproducible cause or a documented way to distinguish approval waits from infrastructure hangs.

Written by the indexing model from the issue text.