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.