[BUG] Scheduled tasks: WebSearch tool calls hang indefinitely in background/cron-triggered sessions

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?

A scheduled task (Claude Code desktop app's "Scheduled" / scheduled-tasks feature, cron-triggered) that calls the WebSearch tool gets stuck indefinitely on the WebSearch call - no result, no error, no timeout. The exact same WebSearch query executed manually in an interactive session on the same machine, same account, at essentially the same time, returns normally within a few seconds.

This makes any scheduled task that depends on WebSearch unreliable/unusable.

What Should Happen?

WebSearch calls from a scheduled/background-triggered session should complete in roughly the same time as an interactive session (seconds), or fail/timeout with an error rather than hanging indefinitely.

Error Messages/Logs

No error is ever thrown - that's part of the problem. Evidence from session transcripts (list_events):

Run 1 (session local_aa541c89-94e6-44e3-9a0c-5dac2a188f0b): started 2026-09-11T08:55:28Z. Progressed through several WebSearch calls, then stalled on the 5th call. Still "running" with zero new activity when checked again at 2026-09-11T10:36:05Z (~1h40m later, no error, no progress). Manually interrupted; transcript shows the interrupt landed mid-WebSearch-tool-call ("[Request interrupted by user for tool use]").

Run 2 (session local_3d6a8422-0097-4fb2-9eb1-9fbaf195ba9e): similar - did eventually trickle forward a little (41->49 transcript messages over several minutes) before being manually stopped, again while mid-WebSearch.

Control test: the identical WebSearch query run directly in an interactive session (same machine, same account) returned normally in a few seconds - ruling out a global WebSearch outage.

Run 3, after reducing the task's prompt to cap WebSearch usage at exactly 2 calls (to rule out "too many calls" as the cause): session local_7e5dc769-7eaf-4aba-bdee-c65ee8d910b5, created 2026-09-11T11:56:00Z. Hung on the very first WebSearch call. Still stuck with zero progress after 17 minutes (checked at 2026-09-11T12:13:19Z). Manually stopped.

Steps to Reproduce

1. Create a scheduled task (via the desktop app's Scheduled Tasks feature / scheduled-tasks MCP) whose prompt instructs the agent to call the WebSearch tool (e.g. to look up recent news).
2. Trigger it, either via "Run now" or by waiting for its cron schedule to fire.
3. 3. Watch the task's session transcript (e.g. via list_events on the session tied to the run).
4. 4. Observe: the agent calls WebSearch once. The tool call never returns - no result, no error - for 15+ minutes, while the session status stays "running" and lastActivityAt stops advancing.
5. 5. In parallel, run the exact same WebSearch query directly in a normal interactive Claude Code session on the same machine/account - it returns a normal result in a few seconds.

Note: reducing the number of WebSearch calls in the task's prompt (from 5+ down to a hard cap of 2) did not prevent the hang - it recurred on the very first WebSearch call in that run.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Unknown (desktop app; claude --version not available on PATH in this environment)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

This bug was found via the Claude Code desktop app's "Scheduled Tasks" feature (sidebar "Scheduled" section / scheduled-tasks MCP), not a terminal session - so "Terminal/Shell" above doesn't really apply; selected "Other" as the closest fit.

The scheduled task ran locally (not a cloud routine) and was triggered both automatically via its cron schedule and manually via "Run now". The tool call that hangs is the client-facing WebSearch tool, called from within the scheduled-task-spawned session's agent loop.

Happy to share the full session transcripts (list_events output) for the session IDs mentioned above if that would help triage.