Desktop scheduled-task runs wedge at their first Bash tool call (approvals and allowlist rules don't help)

## Summary

Desktop app (Code tab) scheduled-task runs consistently freeze at their **first Bash tool call**. Three separate runs of the same task all wedged with an identical signature: the session issues its first Bash call ~25–30 s after start, `lastActivityAt` never advances again, and the run stays `running` indefinitely (observed 20+ minutes). Approving permission prompts does not resume them, and pre-adding permission allowlist rules that cover the command does not prevent the wedge.

## Environment

- Claude Code 2.1.240, desktop app (macOS), Code tab
- macOS 26.6.2 (Darwin 25.6.0), Apple Silicon
- Model for the task runs: claude-opus-5[1m]
- Interactive sessions on the same machine run Bash normally (same settings, same hooks)

## Steps to reproduce

1. Create a scheduled task via the `scheduled-tasks` MCP (`create_scheduled_task`) with a one-time `fireAt` and a prompt whose first action is a trivial shell command (mine starts with `date -u`).
2. Dispatch it with `run_scheduled_task` (same as clicking "Run now").
3. Watch the run session via `get_session` / `list_events`.

## Observed

- Run 1: created 07:48:44Z, `lastActivityAt` frozen at 07:49:10Z at the first Bash call. The user approved the pending permission prompt inside the run's session window ~20 min later; activity never advanced.
- Run 2 (fresh dispatch): created 08:14:16Z, frozen at 08:14:41Z — same signature.
- I then added `permissions.allow` rules to `~/.claude/settings.json` covering every command the task uses (verified the JSON parses; rules include `Bash(date *)` and the specific ssh prefix).
- Run 3 (after rules were live): created 08:18:45Z, frozen at 08:19:14Z — identical wedge, so this is not a permissions/approval issue.
- In each case `list_events` shows the assistant's opening message and `(called Bash)`, then nothing further; the transcript message count stays constant.
- All timestamps 2026-09-18Z.

## Expected

The first Bash call either executes (allowlisted) or prompts and then resumes on approval; the run proceeds to completion.

## Possibly relevant

- The account has a substantial custom hook set in `~/.claude/settings.json`, including `PreToolUse` hooks matching `Bash` (shell scripts + `/usr/bin/python3` scripts). These run fine in every interactive session. If the scheduled-task runner launches sessions without a TTY or with a different stdin wiring, a hook or the runner's hook plumbing may be where the call never returns — I could not distinguish "Bash tool call never dispatched" from "PreToolUse hook never returned" with the observability available (`list_events` shows no hook error, and the frozen `lastActivityAt` is the only signal).
- The task's working folder is a trusted git repo; the workspace-trust check passed (sessions do start and produce their first assistant message).
- Workaround that works: a durable `CronCreate` one-shot inside an interactive session runs the identical commands without issue.

## Impact

Scheduled tasks that need any shell access are unusable on this setup; each attempt leaves a permanently "running" session.

Reproduce the freeze through the scheduled-tasks MCP using create_scheduled_task and run_scheduled_task, then observe the run with get_session and list_events. Inspect the scheduled-task runner's first Bash dispatch and the PreToolUse hook plumbing, especially without a TTY. Done means an allowlisted or approved first Bash call resumes and the scheduled run completes.

Written by the indexing model from the issue text.