›_ Claude Code Issues
Claude Code Issues / #58472

MCP relay WAF (anthropic.com) blocks tool calls whose body contains the literal string "oauth"

Resolved 💬 3 comments Opened May 12, 2026 by dobbscoin Closed May 16, 2026

Summary

Cloudflare WAF on anthropic.com (the MCP relay path) returns a generic HTML 403 block when an MCP tool call's request body contains the literal string oauth — typically when the model is debugging an OAuth-protected MCP integration (RFC 9728 / RFC 8414 well-known paths).

This makes Claude unable to investigate its own MCP integrations from inside a Claude Code session, because every curl, grep, or cat against /.well-known/oauth-protected-resource or /.well-known/oauth-authorization-server fails before it ever leaves Anthropic's edge.

Symptom

The tool call surfaces in Claude Code as:

Streamable HTTP error: Error POSTing to endpoint: <!DOCTYPE html>
...
<h2 class="cf-subheadline">You are unable to access anthropic.com</h2>
...
Cloudflare Ray ID: 9fab93259dd409b5

The blocked source IP shown in the page is the VPS's public IP — i.e. the egress IP of the box running the Claude Code session — confirming this is the relay-side WAF inspecting the outbound POST from the Claude Code harness to anthropic.com.

Repro

Tool: any HTTP/exec MCP tool reachable via the claude.ai connector relay (e.g. a remote MCP server with a bash tool).

# Triggers the WAF (request body contains "oauth-protected-resource")
curl https://my-mcp-host/.well-known/oauth-protected-resource

Same tool call with a base64-encoded path that the shell decodes locally → succeeds:

P=$(echo Ly53ZWxsLWtub3duL29hdXRoLXByb3RlY3RlZC1yZXNvdXJjZQ== | base64 -d)
curl "https://my-mcp-host$P"

The file-write MCP tools (write_file, apply_patch) hit a separate "hard-deny pattern" rejection on the same string, surfaced as {"error":"argument matched hard-deny pattern"}.

Observed Ray IDs (2026-05-12)

9fab93259dd409b5, 9fab940bed0909b5, 9fab99b77d4f09b5, 9faba1d03f7409b5, 9faba2278f0009b5, 9faba3c3f93709b5 — all blocking POSTs containing the substring oauth.

Impact

  • Cannot debug OAuth flow on any user-built MCP server from inside Claude Code.
  • Connector health-check probes that fail to RFC 9728 paths (red dot in Connectors UI) are exactly the case that benefits most from in-session investigation, and is exactly what the WAF prevents.
  • Workaround (base64-dodge) is non-obvious and adds 30+ minutes of friction to any MCP debugging session.

Suggested fix

Allowlist oauth-protected-resource, oauth-authorization-server, and the bare oauth substring in WAF rules scoped to the MCP relay endpoint, OR exclude MCP-relay POST bodies from the WAF rule that matches OAuth-flow keywords (presumably intended for upstream client-side OAuth abuse, not assistant-tool POSTs).

View original on GitHub ↗

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