[BUG] WebFetch tool always fails — Cloudflare bot protection on claude.ai blocks headless domain verification requests

Resolved 💬 4 comments Opened Mar 27, 2026 by oralion Closed Jun 2, 2026

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?

[Diagnosed and issue prepared by Claude]

The built-in WebFetch tool is completely non-functional in any headless/CLI environment. Before fetching any URL, Claude Code makes a domain safety verification request to https://claude.ai/code/. Cloudflare's bot protection on claude.ai returns a 403 with a JavaScript challenge (cf-mitigated: challenge) that a CLI process cannot complete.

As a result, every WebFetch call fails regardless of the target URL — even for domains that are fully accessible and have no restrictions.

This is not a user configuration issue and not specific to any particular network or machine. It affects any non-browser HTTP client.

What Should Happen?

WebFetch should successfully fetch publicly accessible URLs. The domain safety verification should not depend on a Cloudflare-protected browser endpoint that rejects headless clients. Options:

Use a verification endpoint on api.anthropic.com (or similar) that is not behind Cloudflare's bot challenge
Skip verification when running in an authenticated Bedrock/API context where client identity is already established
Gracefully degrade — if the verification endpoint is unreachable, fall back to a configurable allow-list or proceed with a warning rather than hard-blocking all fetches

Error Messages/Logs

Error shown for every WebFetch call regardless of target domain:

Unable to verify if domain <X> is safe to fetch. This may be due to network
restrictions or enterprise security policies blocking claude.ai.
Actual HTTP response from https://claude.ai when called by Claude Code's verification step:

HTTP/1.1 403 Forbidden
server: cloudflare
cf-mitigated: challenge
CF-RAY: 9e2f58a20e2003a5-ZRH
Content-Type: text/html; charset=UTF-8
Response body:

<title>Just a moment...</title>
<span id="challenge-error-text">Enable JavaScript and cookies to continue</span>
Connectivity check confirming the target domains themselves are reachable:

mermaid.js.org  → HTTP 200  ✓
github.com      → HTTP 200  ✓
claude.ai       → HTTP 403  ✗ (Cloudflare JS challenge — not a network block)

Steps to Reproduce

  1. Run Claude Code via AWS Bedrock (CLAUDE_CODE_USE_BEDROCK=1) or any non-browser environment
  2. Ask Claude to fetch any public URL, e.g.:

"Fetch the content of https://github.com/ and summarise it"

  1. Claude attempts to use the WebFetch tool
  2. The tool fails immediately with: Unable to verify if domain github.com is safe to fetch...
  3. This occurs for every URL — the target domain is irrelevant

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.28

Platform

AWS Bedrock

Operating System

Ubuntu/Debian Linux

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

The error message is misleading. It reads: "This may be due to network restrictions or enterprise security policies blocking claude.ai." This causes users and IT teams to investigate local network/firewall policy when the actual blocker is Cloudflare on Anthropic's own infrastructure. The corporate proxy passes the connection to claude.ai just fine — the 403 is returned by Cloudflare after the TLS handshake succeeds.

This likely affects all Claude Code deployments in headless/server/CI environments (including all Bedrock deployments), not just corporate networks. Any environment without a real browser session cannot complete a Cloudflare managed challenge.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗