Desktop app (Windows): headless scheduled-task runs hang mid-tool-call (~100% rate) — tool_result never delivered; interactive sessions and CLI claude -p unaffected

Environment

• Claude Desktop for Windows 1.22209.0 (Claude Code 2.1.209), Microsoft Store install
• Windows 11 Pro build 26100, desktop workstation (i9 / 64 GB, always on AC)
• ~20 scheduled tasks ("routines") configured in the app, schedules from every-30-min to daily/weekly

Symptom

Since an app freeze on 2026-07-15 (app was unresponsive and was relaunched), essentially every headless scheduled-task run hangs 30–60 seconds in, permanently:

• The run starts normally, the model streams turns, then issues a tool call — and the tool result is never delivered back to the session.
• The session transcript's LAST entry is an assistant message containing a pending tool_use block, with no subsequent tool_result ever appended. The claude.exe for the run stays alive indefinitely (some CPU spin), transcript mtime goes stale.
• Affects both MCP tools and built-in tools (Grep, Bash/PowerShell, file reads) equally — so it does not look tool-specific.
• A second, rarer signature: the transcript ends at a last-prompt metadata entry and never progresses.
• On one observed day: 28 of 28 scheduled runs hung, 0 completed. A couple of runs on a prior evening did complete, so it appears to be a near-100%-rate race, not an absolute block.

What is NOT affected

• Interactive sessions in the same app work perfectly (same machine, same MCP servers, same tools).
• Headless CLI runs work perfectly: the same prompts run via Windows Task Scheduler → claude -p (stdin prompt, same MCP config) complete reliably in 1–11 minutes, dozens of runs, zero hangs. This isolates the bug to the desktop app's scheduled-run/tool-execution pipeline (IPC between the headless session and its tool executor?), not the core agent loop.

Persistence / what we tried

• Survives a full PC reboot and an app update (bug present on 1.22209.0).
• Killing the hung claude.exe processes frees the dispatcher's ~3 concurrency slots — new runs then launch, but hang the same way within ~a minute.
• Secondary effect worth noting: hung runs pin the dispatcher slots, so newly-due runs are skipped to their next occurrence (daily tasks silently skip a whole day).

Current workarounds

1. A watchdog that kills scheduled-run claude.exe whose transcript ends in a pending tool_use and has been stale >8 min.
2. Migrated all routines to Windows Task Scheduler + claude -p, which works flawlessly.

Ask

Is this a known issue in the desktop scheduled-task runner? Happy to provide sanitized transcript tails (assistant tool_use with no tool_result), process trees, or run the runner with debug logging if you tell us how to enable it.