Claude Code WebFetch Timeout: 60s Idle, 300s Total

Five of my WebFetch calls have died with the same line: timeout of 60000ms exceeded. Two were eaton.com product pages, one was a CDW listing, one was eBay's partner network agreement and one was a blog post on shkspr.mobi. Each failed about 60 seconds after it went out. That looks like a 60-second cap on WebFetch, and it isn't one. A page that sends one byte a second for 90 seconds comes back fine, and until four days ago nothing capped the total at all.

This post separates the limits. The evidence is three test fetches I ran today on Claude Code 2.1.270, the tool records of 1,499 WebFetch calls in the Claude Code transcripts on this Mac mini (25 July to 14 September 2026), and the changelog and issue tracker for the history.

Three limits, three different errors

Limit	What it counts	Text Claude sees	Can you change it
Idle timer	60 s with no bytes arriving	timeout of 60000ms exceeded	No documented setting
Download deadline	300 s for the whole download, redirects included	Fetch did not complete within the 30s deadline (with my 30 s override)	CLAUDE_CODE_WEBFETCH_DEADLINE_MS, v2.1.268+, 0 turns it off
Size cap	10,485,760 bytes of response	maxContentLength size of 10485760 exceeded	No documented setting

Only the deadline is documented. The environment variable reference calls it the upper bound on “how long WebFetch waits for a page to download, including any redirects it follows,” and lists no other WebFetch limit. The other two I know only from error text, which matches the wording in axios's Node adapter character for character. My reading is that WebFetch downloads through axios with timeout: 60000 and a 10 MiB maxContentLength, which is an inference from strings, not documentation. The size cap fired once for me, on a TP-Link switch datasheet PDF.

The test: silence against a slow drip

httpbin's /drip endpoint holds a response open and releases bytes on a schedule, which is the shape of a server that never quite finishes. I ran three fetches against it from Seoul between 18:04 and 18:08 KST:

# 1. default settings: 90 bytes, one per second
WebFetch https://httpbin.org/drip?duration=90&numbytes=90&delay=0
  -> 200, 90 bytes, durationMs 96641

# 2. default settings: nothing for 70 s, then 2 bytes
WebFetch https://httpbin.org/drip?duration=2&numbytes=2&delay=70
  -> Error: timeout of 60000ms exceeded        (60.8 s)

# 3. claude -p with CLAUDE_CODE_WEBFETCH_DEADLINE_MS=30000: 60 bytes over 60 s
  -> Error: Fetch did not complete within the 30s deadline   (30.6 s)

The first run is the one that matters. It took 96.8 seconds and never tripped the 60-second timer, because the timer only counts silence. In the axios source the value goes to Node's req.setTimeout, which Node documents as socket inactivity, and the drip result matches that. (Its answer said the body was 68 bytes; the raw file WebFetch saved beside it held 90. Don't ask the summarizer to count.)

The second run failed where you would expect, but I can't count it as clean proof. Curl against the same URL got a 504 from httpbin's own gateway at 60.8 seconds, so the gateway and the client timer were racing. The five production failures are the better evidence for the silence case: real sites, each ending between 60.5 and 60.7 seconds, each with the client's message rather than an HTTP status.

What 1,499 real fetches looked like

The transcript records carry a durationMs for every successful download, separate from how long the whole call took. Across 1,333 successful downloads from 591 hosts, the median was 4.8 seconds and the 99th percentile 14.8. Exactly one passed 60 seconds: the raw changelog file on raw.githubusercontent.com, 676 KB in 106.4 seconds, which streamed the whole time and so never went quiet long enough for the idle timer.

End to end is a different number. Twenty-four calls took longer than 60 seconds from request to result, and of the 16 that recorded a download time, 15 had downloaded in under 15 seconds. The rest was the small model reading the page, or waiting on a slower call in the same parallel batch: on 13 September a 403 and a 404 that downloaded in under a second each came back 90 seconds after they were requested, alongside a slow sibling. Time WebFetch from outside and you are timing the summary and the batch too.

Timeouts are also a small share of what goes wrong: 69 of the 1,499 calls errored, and the idle timer was 5 of them. Thirty-one were the preflight blocklist from how Claude Code web fetch works, and TLS failures, empty DNS lookups and refused connections made up 24 more. A 403 or 404 isn't an error to the tool at all; 195 came back as ordinary results for Claude to read.

Eleven months of “WebFetch has no timeout”

Issue	Filed	Closed	Report
#8980	5 Oct 2025	16 Jan 2026, not planned	Hangs when the site is not accessible
#11650	14 Nov 2025	12 Feb 2026, completed	Freezes with no way to interrupt except restarting
#24684	10 Feb 2026	12 Feb 2026, completed	Hanging websites freeze the whole session
#26882	19 Feb 2026	26 May 2026, closed as inactive	“Fix from #24684 not effective”
#34565 and two more	14 to 17 Mar 2026	12 to 15 Apr 2026, not planned	Indefinite hangs, no timeout
#86910	15 Aug 2026	open	A 1 MB page with 598 KB of inline CSS hangs; one attempt ran 51 minutes
#89639	25 Aug 2026	open	Scheduled desktop tasks wedge about 30 s into a WebSearch or WebFetch call

Three issues, #17735 among them, were closed as completed on 12 February, the day 2.1.40 reached npm, yet the changelog has no WebFetch line between 2.1.33 and 2.1.69. A week later #26882 said the fix wasn't working, and a commenter there had a research subagent stuck for over an hour on its 76th fetch. The changelog's first WebFetch hang fix is 2.1.117 in April (truncating very large pages before markdown conversion), and its first time limit is 2.1.268, published on 10 September.

That deadline may not cover the cases still open. The docs scope it to the download, and the #86910 reporter wrote that “the page download completes, then no further bytes arrive” before the hang. A later commenter traced one variant to a response labelled Content-Encoding: gzip that isn't gzip, where the decoder error is swallowed and the fetch never settles. I haven't reproduced either, and I would not assume five minutes ends them.

What I would set on an unattended rig

A hung fetch in a headless run costs more than the fetch. When I measured how often my unattended runs go quiet, the expensive part was that a stuck run also blocks the scheduled runs behind it. Three settings follow from the numbers above.

1. Be on 2.1.268 or later. Check with claude --version. Headless claude -p does not check for updates by itself (details on why Claude Code stops updating), so an unattended box can go without this fix indefinitely.
2. Set a tighter deadline in the job's environment. Most env values in a project settings file wait for workspace trust, which a headless run may never grant; an exported variable is what worked in my probe. On my data, 120000 would have cut none of 1,333 downloads and 90000 would have cut exactly one, the changelog.
3. Send known-slow hosts to curl. Nothing documented raises the 60-second idle timer. For a site that routinely goes quiet longer than that, Bash curl --max-time gives you a limit you control, with the exit code 28 caveats that come with it.

For a launchd job the variable goes in the plist, as with any other launchd environment variable:

<key>EnvironmentVariables</key>
<dict>
  <key>CLAUDE_CODE_WEBFETCH_DEADLINE_MS</key>
  <string>120000</string>
</dict>

My own publishing jobs don't set it yet. To count these errors in your transcripts, parse tool results rather than grepping: a plain grep also matches every time the string was merely typed.

python3 - <<'EOF'
import glob, json, os, re, collections
pat = re.compile(r'timeout of \d+ms exceeded|within the \d+s deadline|maxContentLength size of \d+ exceeded')
hits = collections.Counter()
for f in glob.glob(os.path.expanduser('~/.claude/projects/*/*.jsonl')):
    for line in open(f, errors='ignore'):
        if '"tool_result"' not in line:
            continue
        try:
            parts = json.loads(line).get('message', {}).get('content', [])
        except ValueError:
            continue
        for p in parts if isinstance(parts, list) else []:
            if isinstance(p, dict) and p.get('type') == 'tool_result' and p.get('is_error'):
                m = pat.search(str(p.get('content')))
                if m:
                    hits[m.group(0)] += 1
print(hits)
EOF

FAQ

What is the WebFetch timeout in Claude Code?

There are two time limits. An idle timer fails a fetch after 60 seconds with no bytes arriving, with timeout of 60000ms exceeded. Since v2.1.268 a separate deadline fails any download that hasn't finished after 300 seconds, redirects included. A page that keeps sending bytes can run past 60 seconds; my 90-second trickle test returned normally.

How do I change the WebFetch timeout?

Set CLAUDE_CODE_WEBFETCH_DEADLINE_MS in milliseconds, plain digits, in the environment Claude Code starts with; 0 removes the limit. It needs v2.1.268 or later and changes only the total download deadline. No documented setting moves the 60-second idle timer, so for hosts that stay silent longer, fetch with curl through Bash.

Why does WebFetch hang forever?

Before v2.1.268 nothing bounded the total download time, so a server that held a response open without finishing could stall the tool, and issues reported it from October 2025. The deadline now covers the download. Issue #86910, still open, describes hangs after the download has completed, which the deadline may not reach.

The census parses WebFetch tool_use and tool_result pairs in the 2,112 transcript files under ~/.claude/projects on this machine as of 18:00 KST on 14 September 2026, with probe directories excluded: 218 sessions, 1,499 calls, versions 2.1.220 to 2.1.270. Download times and HTTP codes come from each record's toolUseResult; end-to-end times are the gap between the call and result timestamps. Each test ran once, from Seoul, against httpbin.org. The axios attribution rests on matching error strings in axios 1.20.0, and issue states were read from the GitHub API the same evening and will drift. The launchd publishing runner mentioned here is part of the Playbook ($12), the one paid link in this post; there are no affiliate links.