Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix MCP relay WAF (anthropic.com) blocks tool calls whose body contains the literal string "oauth"

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

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.

Error Message

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

Root Cause

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.

Fix Action

Fix / Workaround

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"}.

  • 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.

Code Example

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

---

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

---

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

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).

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#agent execution#callback error#memory management#API rate limit#retriever error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING