WebFetch tool has no timeout: hanging websites freeze the entire session

Bug Description

The WebFetch tool has no timeout parameter. When a website is slow, unresponsive, or deliberately hangs the connection, the entire Claude Code session freezes indefinitely. The model is not "thinking" at this point: it is waiting for the tool response, so it cannot recover, retry, or skip. The only way out is for the user to manually interrupt the session.

Steps to Reproduce

1. Call WebFetch on a URL that hangs (slow server, anti-bot protection that delays response indefinitely, paywall holding the connection open)
2. The session freezes completely. No output, no progress, no way for the model to detect the hang or move on.

This is especially problematic when multiple WebFetch calls are made in parallel (recommended pattern for performance): one hanging URL blocks ALL parallel calls in the same message from returning.

Expected Behavior

WebFetch should support a timeout parameter (similar to the Bash tool's timeout parameter) so that:

• The call returns an error after N milliseconds instead of hanging forever
• The model can catch the timeout and skip the source or try an alternative
• The user's session is never blocked indefinitely by a single unresponsive URL

Why This Matters

Websites may do this intentionally

Some websites may deliberately hold connections open or delay responses as an anti-AI/anti-scraping measure. Without a timeout, this becomes an effective way to freeze Claude Code sessions indefinitely. A website can block a user's entire session just by not responding.

No recovery path

Unlike the Bash tool which has a timeout parameter, WebFetch offers zero control over how long the call waits. The model cannot set a deadline, cannot detect the hang, and cannot abort.

Proposed Solution

Add an optional timeout parameter to WebFetch, similar to the Bash tool:

WebFetch(
  url: "https://example.com/article",
  prompt: "Extract key facts",
  timeout: 15000  // Return error after 15 seconds
)

A sensible default timeout (e.g., 30 seconds) would also prevent accidental hangs even without explicit timeout values.

Current Workaround

Avoid WebFetch for unreliable URLs and use Bash with curl instead (which supports the timeout parameter), but this loses the built-in content extraction and prompt-based processing that makes WebFetch useful.