[BUG] Scheduled task hangs indefinitely on its first Bash tool call when run unattended (no timeout, no error)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

A local scheduled task (created via the "Scheduled" feature in the Claude Code desktop app) consistently hangs forever the moment it runs unattended — even on the single simplest possible action (a bare echo redirect via the Bash tool). The task works perfectly when a human is present and clicking through prompts, but every unattended firing freezes permanently with zero progress, zero error, and no timeout, even though the Bash call was given an explicit timeout parameter.

Environment

• Windows 11 Pro (10.0.26200)
• Claude Code desktop app (Windows)
• Model: claude-sonnet-5
• Task type: local recurring scheduled task ("Scheduled" section / mcp__scheduled-tasks tools), not a cloud routine
• Project folder has its own .claude/settings.json with "permissions": {"defaultMode": "bypassPermissions"}, scoped to that folder only

Steps to reproduce

1. Create a local scheduled task whose prompt does real work: read some files, dispatch a few background Agent tool calls, write results to a file.
2. Confirm the task works correctly when run via "Run now" while attended (approving any prompts that appear) — in our case it completed successfully in ~14 minutes and produced correct output.
3. Trigger the same task via "Run now" unattended (don't watch it, don't approve anything).
4. Observe: the task's session freezes on its very first tool call and never recovers.

What we tried, to isolate the cause

• Added a hard timeout parameter (30s–120s) to every Bash call in the task's prompt, explicitly instructing it to always pass one. Result: no change — the very first Bash call (a bare echo "..." >> logfile.txt) still never returned and never errored, even 5+ minutes later. This suggests the hang happens before the command execution's own timeout logic even engages — i.e., at dispatch, not inside the shell process.
• Set the task's project folder to "permissions": {"defaultMode": "bypassPermissions"} specifically to rule out an unanswerable permission-approval prompt. Result: no change — froze identically.
• Ruled out a file lock (the target file was confirmed closed on the user's end).
• Ruled out a stuck OS-level subprocess: checked Get-Process for python/soffice/node/etc. during a freeze — nothing was running that could explain a hang.
• Ruled out the task's own application logic (a specific step like a LibreOffice/recalc call) — removed that step entirely from the prompt; hang persisted at an even earlier point (the literal first Bash call).
• Added explicit checkpoint logging as the task's very first instruction (write a timestamped line to a log file before doing anything else, using the simplest possible command). Result: the log file remained completely empty across multiple unattended runs — the task never got past its first tool call at all.
• Recreated the task fresh in a brand-new, dedicated project folder (to rule out any stale/inherited configuration from an older folder). Result: no change, identical freeze.

Current best hypothesis

Something in how the app dispatches a tool call (specifically Bash) for an unattended/scheduled session differs from an attended one, and that dispatch step itself is hanging — before the shell command runs, before any of Claude Code's own per-call timeout logic can apply. A single attended run with the exact same prompt content completes normally, which rules out the prompt/task logic itself as the cause.

Impact

This makes the "Scheduled" feature unusable for any task expected to run unattended (which is the entire point of scheduling something) if that task needs to do real file/shell work. A watchdog task we built to detect and auto-stop hung runs works correctly (confirms the scheduled-tasks system itself is otherwise functioning — it can list runs, check session activity, and stop a session), which further isolates the issue to tool dispatch inside the hung session specifically, not the scheduling/dispatch of the session itself.

What would help

Any way to see why an unattended session's tool call is pending — e.g., whether it's parked behind a permission dialog that bypassPermissions didn't actually apply to, or a distinct workspace-trust gate for unattended contexts, or something else entirely.

What Should Happen?

The scheduled task should complete successfully when run unattended, just as it does when run attended with identical prompt content (confirmed: the same task completed correctly in ~14 minutes when a human was present to approve prompts). At minimum, if something legitimately blocks it, it should fail fast with a visible error or timeout — not hang silently and indefinitely with zero output, zero error, and no way to tell what it's waiting on.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

1. Create a local scheduled task whose prompt does real work: read some files, dispatch a few background Agent tool calls, write results to a file.
2. Confirm the task works correctly when run via "Run now" while attended (approving any prompts that appear) — in our case it completed successfully in ~14 minutes and produced correct output.
3. Trigger the same task via "Run now" unattended (don't watch it, don't approve anything).
4. Observe: the task's session freezes on its very first tool call and never recovers.

Claude Model

Sonnet (default)

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.110.0.0 (this is the Claude desktop app version, which is what's running the Code tab / scheduled tasks here

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Git Bash / MSYS2