[BUG] WebFetch truncation is invisible to the model — absent from the tool description, unmarked in the result, and the web-fetch subagent can neither detect nor recover from it

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?

WebFetch truncates long pages at a fixed character limit. The human documentation now says so, and even says what to do about it — "use curl via Bash for the unprocessed page". None of that reaches the model that has to make the decision. The tool description is the model's entire picture of the tool, and it contains no mention of truncation, no limit, and no recovery path.

Here is the description in full, as it appears in the agent's tool definitions — one lead sentence and four bullets, nothing elided:

Fetches a URL, converts the page to markdown, and answers prompt against it using a small fast model. - Fails on authenticated/private URLs — use an authenticated MCP tool or gh for those instead. - Fails on localhost and other hostnames without a dot; for a local server, use curl via Bash. - HTTP is upgraded to HTTPS. Cross-host redirects are returned to you rather than followed; call again with the redirect URL. - Responses are cached for 15 minutes per URL.

The words truncate, limit, size and length do not appear. The input schema is {url, prompt} with additionalProperties: false — no offset, no page, no max-length. The string "use curl via Bash" is present, but it is scoped to unreachable hosts, not to dropped content, and it says nothing about curl returning a more complete page.

So the model has no basis for knowing that a fetch can come back partial, and no reason to reach for the remedy that the docs describe to humans. On a plain-text fetch of https://www.rfc-editor.org/rfc/rfc9110.txt, the tool's own boundary note reported returning 39,415 of 502,907 characters — 7.8% of the document. Nothing in the tool result carries that forward as a flag, so the calling model sees an answer about 7.8% of a document presented exactly like an answer about all of it.

The result is that a fetch reporting "the page doesn't mention X" is indistinguishable from the page genuinely not mentioning X. A commenter on #51783 reported precisely this — a 2.5 MB response truncated with no marker, after which the summarizer stated the repository "has no packages/ directory". That issue was closed for its documentation scope and the observation was never addressed.

The web-fetch subagent makes this structural

There is a built-in web-fetch subagent type whose entire toolset is WebFetch, plus a handback and an advisor. It has no Bash. So when it hits the cut it cannot curl, cannot read a file, and has no fallback of any kind — its only available move is to hand back a caveat.

Two descriptions would need to carry the constraint and neither does:

• The agent's own prompt. It is not told that long pages are truncated, so it cannot reliably detect that it happened, and it cannot tell its caller "this page exceeds what I can retrieve, fetch it yourself with curl" — which is the one genuinely useful thing it could say.
• The caller-facing agent description. It reads "Use this to fetch and read web pages / URLs when you do not have a direct WebFetch tool of your own", with no mention of a size ceiling. A caller delegating "read this long specification" to it is routing the task to an agent that is structurally incapable of completing it, and cannot know that in advance.

What this costs in practice

From a background subagent transcript of mine (2026-09-17, v2.1.274), researching the INSDC Feature Table specification:

Critical caveat up front: WebFetch truncates every full copy of the INSDC Feature Table at ~39.4k characters, which lands mid-Appendix-I. Appendix II (feature-key → qualifier lists) and Appendix III (qualifier definitions) both fall past the cut in every complete copy. […] answered only from a model-generated summary of the truncated tail. Membership is almost certainly right […] but I cannot present it as the FT's exact text, and I cannot vouch for completeness.

That agent had Bash available and called it 59 times in that same transcript, so this is a measured count rather than an assumption. One curl would have returned the entire specification. It inferred the truncation from the shape of what came back, degraded its own answer, warned that it could not vouch for completeness — and never reached for the remedy, because nothing in its tool definition suggested one existed.

What Should Happen?

Nothing here requires raising the limit.

1. State the limit and the remedy in the WebFetch tool description — that long pages are truncated at a fixed character limit, and that curl via Bash returns the unprocessed page. This is the same advice the public docs already give humans; the model that needs it is the one that never sees it.
2. Mark the truncation in the result — a truncated: true flag with characters retained and total, plus a marker in the content handed to the extraction model, so "absent from the page" and "absent from the part I was given" stop being the same observation.
3. Tell the web-fetch subagent in its own prompt that its content can be truncated and that it has no way to recover, so it can hand back "this exceeds what I can retrieve, fetch it directly" rather than a hedged partial answer.
4. Say it in the caller-facing web-fetch agent description too, so a caller can choose curl instead of delegating a long-document task to an agent that cannot finish it.

Error Messages/Logs

Steps to Reproduce

1. Inspect the WebFetch tool description available to the model. Observe that it states no size limit and gives no recovery path for dropped content.
2. Ask Claude to WebFetch https://www.rfc-editor.org/rfc/rfc9110.txt and quote the final lines verbatim — the RFC ends with the editors' postal addresses.
3. The answer comes from the first ~39.4k characters; the reported end of the document is wrong, and nothing in the result indicates that 92% was missing.
4. curl -sS https://www.rfc-editor.org/rfc/rfc9110.txt | wc -m returns 502,907 characters (502,941 bytes) in one call, with the real tail present.
5. Repeat step 2 by delegating to the web-fetch subagent. It has no Bash, so even having inferred the truncation it cannot perform step 4.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.274

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

iTerm2

Additional Information

One inconsistency worth fixing alongside

The tool description says WebFetch "answers prompt against it using a small fast model" — a summarizer. In at least some configurations the system prompt instead states that WebFetch "returns the raw page as markdown inside <fetched-web-content> tags rather than a summary". Those describe different return values, and the schema still requires a prompt whose stated purpose only makes sense under the summarizer behaviour. A model cannot reason about the fidelity of what it received while its own two sources disagree about what it received.

Prior art

• #51783 — the only one closed by a human (bcherny, 2026-08-17), as completed, once the truncation was documented for readers. Its comment thread contains the silent-truncation report described above, which was not addressed. Closed but unlocked.
• #22937 — "WebFetch tool truncates large documentation pages, preventing access to critical content". Asked for a content-length indicator, an error on overflow, and offset/pagination. Labelled high-priority by triage, then closed by github-actions[bot] after a stale label and locked. No maintainer ever commented.
• #58467 — optional raw/verbatim mode. Same story: stale-bot closed, bot-locked, no maintainer comment.
• #50647, #59882, #53297 — lossy-extraction and fidelity reports. All three stale-bot closed, bot-locked, no maintainer comment.
• #90416 (open) — structurally identical no-signal failure for PDFs: unreadable content reaches the summarizer with no marker, producing fabricated verbatim quotes.
• #73514 (open) — the maintainer reply here is the only public source for the raw-passthrough cap (~100 KB / ~25K tokens for preapproved Markdown documentation domains).

To be explicit about the pattern: of the six closed issues in this area, five were closed by the stale bot with no maintainer having commented at any point, and subsequently locked so they cannot be revived. I am filing rather than commenting because #51783 is the only unlocked venue and it is closed as completed.

Already shipped, not being re-requested: the Accept header preferring Markdown (#60856, #41097), and the download-deadline and cache-TTL environment variables.

Environment Info

• Platform: linux (arm64 devcontainer, Ubuntu 26.04, on an Apple Silicon macOS host)
• Terminal: VS Code devcontainer
• Version: 2.1.274
• Feedback ID: 2c12de47-9904-4de3-80f4-e3eac31a337e