Write tool calls in scheduled-task sessions occasionally never return a result (silent non-return, not a denial or error)

Write tool calls in scheduled-task sessions occasionally never return a result (silent non-return, not a denial or error)

Summary

In a scheduled task session (the local Routines scheduler, backed by ~/.claude/scheduled-tasks/<name>/SKILL.md), a Write tool call occasionally fires and then simply never produces a result. No permission prompt, no toolDenialKind, no error, no timeout message — the transcript just ends right after the tool_use block. The session sits in "status": "running" indefinitely (confirmed via list_task_runs), with last_activity_at frozen at the exact timestamp of the stuck Write call, until manually interrupted.

This is distinct from the two issues already reported in #98608 (non-engagement) and from a permission-prompt deadlock I found and fixed the same day (an unattended session has no one to approve a tool-use prompt, so it hangs forever waiting). This bug is neither of those: the call is never denied, never pending-approval — it just never returns, success or failure.

Environment

• Claude Code (desktop app), Windows 11
• CLI version in session metadata: 2.1.281
• Model used by the scheduled-task harness in both instances: claude-opus-5-5 (the session's own configured default model, claude-opus-4-6 in settings.json, differs — noting in case the harness's model selection for unattended runs is relevant)

Reproduction (two independent, confirmed instances, one day apart, under different permission configs)

Instance 1 — monthly-deep-audit task, 2026-10-01
Session local_b6ca0f43-5e95-424f-b40f-ab4c430fa3e8. At this point settings.json had a path-scoped permission rule for Write ("Edit(C:/Users/the1r/.claude/scheduled-tasks/**)"). The stuck call:

tool_use: Write
file_path: C:\Users\the1r\.claude\scheduled-tasks\monthly-deep-audit\latest.md
content: [~8,000 characters of composed markdown report]
timestamp: 2026-10-01T06:29:21.101Z

The exported transcript ends immediately after this tool_use block — no tool_result, no toolDenialKind, no further assistant turn. last_activity_at for the session was frozen at this exact timestamp when checked repeatedly over the following ~70 minutes. The session had made 560+ prior tool calls researching/composing the report before this.

(At the time, I hypothesized this was caused by the path-scoped permission rule not matching the real Windows path, and "fixed" it by broadening the rule to unscoped "Write". Instance 2 shows that fix did not address the actual cause.)

Instance 2 — weekly-tool-scout task, 2026-10-02
Session local_b5ba7796-871b-4035-8ca7-6c53a45163fa. settings.json now had Write fully unscoped: "permissions": {"allow": ["PowerShell", "Bash", "Write", "Edit"]}. The stuck call:

tool_use: Write
file_path: C:\Users\the1r\.claude\scheduled-tasks\weekly-tool-scout\report-2026-10-02.md
content: [~6,500 characters of composed markdown report]
timestamp: 2026-10-01T23:39:07.946Z

Identical signature: the exported transcript ends immediately after this tool_use block, no tool_result, no denial, nothing. The session had made 580+ prior tool calls (extensive web research) before this.

Both instances: the actual report content was fully composed and of good quality — the problem is strictly that the Write call's result never arrives, not that the model failed to do the underlying task.

Expected behavior

A Write tool call should either return a success result, return an error, or (if blocked on a permission decision) appear as a pending/denied prompt. It should not simply disappear with no trace and no further session activity.

Actual behavior

The tool_use block for Write is the last entry in the transcript in both cases. The session remains "status": "running" indefinitely with no further progress until a human manually calls session-stop. No file is written. No error surfaces anywhere — the scheduler's list_task_runs would eventually need a human to notice the frozen last_activity_at to catch this at all.

Impact

Combined with the already-reported non-engagement bug (#98608), this means three independent silent-failure modes have now been found in the same scheduled-task/Routines system, all converging on the same outcome: a routine that should produce a dated report produces nothing, with no error surfaced to the user. In this specific case it happened on the very last step of two otherwise-successful runs — all the research/composition work was done correctly, and the result was lost only because the final Write call never completed.

What's been ruled out

• Not a permission-prompt deadlock: confirmed via toolDenialKind absence in both transcripts, and reproduced with Write fully unscoped (Instance 2) — ruling out any approval-gate explanation.
• Not specific to one task's prompt wording: happened on two different tasks (monthly-deep-audit, weekly-tool-scout) with different SKILL.md content.
• Not a content/formatting problem with the write target: both payloads were plain, valid markdown; manually writing the identical content via the Write tool (done as a workaround) succeeded instantly both times.
• Possible correlation, not confirmed causal: both stuck calls were the last tool call of a long session (560+ and 580+ prior tool calls) writing a large payload (6–8 KB). A successful monthly-deep-audit run on a later retry that same day wrote a similarly large report without issue, so session length/payload size alone isn't sufficient to reproduce it — there may be a narrower race condition or resource/timeout interaction.

Suggested fix directions (not prescriptive)

1. A Write (and likely other mutating tool) call that never produces a result after some bounded time should itself time out with a visible error, rather than leaving the session hung indefinitely.
2. The scheduler (list_task_runs) should be able to distinguish "making progress" from "frozen mid-call" so a user doesn't have to export and read raw transcripts to tell the difference — e.g. surfacing a run as stalled/needs-attention after some period of a tool call with no result.
3. If this correlates with session length or context size, some internal timeout or stream-handling path at the tail end of long scheduled-task sessions may be worth auditing specifically for unattended/headless runs (as opposed to interactive sessions, where I have not observed this).

Related

This is a distinct symptom from #98608 (a scheduled-task session that never engages with its instructions at all, doing zero tool calls). That bug is "never starts"; this one is "does the work, then the last write silently vanishes."