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 <script> 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.