[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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

```shell

```

### 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

Start at the Scheduled feature and the mcp__scheduled-tasks tools, then compare the first Bash tool call in an unattended run with the same call in an attended run. Trace where the unattended call remains pending, and verify that the task either completes or reports a visible timeout or error instead of hanging indefinitely.

Written by the indexing model from the issue text.