Claude Code MCP behind a proxy: 403 now fails fast, allow Sume's host

If Claude Code runs behind a corporate proxy and Sume's MCP server will not connect, ask the proxy admin to allow the host in your server URL, https://mcp.sume.com/mcp. As of Claude Code 2.1.290 and 2.1.292, a server the proxy blocks with HTTP 403 is no longer retried three times, so a blocked Sume entry now fails at once instead of after a pause. That is a clearer signal, and the fix is a proxy rule, not a Sume setting.

This post covers what the changelog says, what the failure looks like, and what to put in the allow request.

What changed in Claude Code?

The Claude Code changelog lists the same behavior twice. Version 2.1.290 (October 5, 2026) says MCP startup behind a network proxy was improved so that a server the proxy blocks with 403 is no longer retried three times. Version 2.1.292 (October 6, 2026) lists it as a fix with the same wording.

The changelog does not say anything else about proxies, and the Claude Code MCP documentation page I read has no section on proxy variables or firewall allow lists. So treat the 403 behavior as the only documented change, and test your own proxy setup rather than assuming more.

Which host does Sume's hosted MCP need?

The Sume docs give the production URL as https://mcp.sume.com/mcp. In the Sume server code, the MCP route, the OAuth protected-resource metadata, the authorization-server metadata, the dynamic registration, token and revoke routes, and the consent route are all registered on the same MCP server app. The practical consequence is that one host name covers the JSON-RPC endpoint and the OAuth discovery paths.

Ask for the host, not just the path. A proxy rule that allows only /mcp can still block the well-known metadata documents a client reads first, and an OAuth connection then fails before any tool is listed.

• Host: mcp.sume.com over HTTPS (port 443).
• Endpoint your client config points at: /mcp.
• Discovery paths a client reads when you sign in with OAuth: /.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server.
• OAuth routes on the same app: /oauth/register, /oauth/authorize, /oauth/token and /oauth/revoke.
• Sign-in may also pass through your identity provider's pages, which your proxy policy treats separately.

How do I tell a proxy block from a Sume problem?

A proxy block is usually a 403 with a body that comes from the proxy, not from Sume. Check it from the same machine and network that Claude Code uses. A request to the metadata path should return JSON if the host is reachable:

If that returns an HTML block page or a proxy-branded 403, the host is not allowed yet. If it returns JSON but the client still cannot sign in, the problem is elsewhere, for example a scope or token issue, which the Sume OAuth docs describe.

curl -sS -i https://mcp.sume.com/.well-known/oauth-protected-resource | head -20

What should the allow request say?

Keep it narrow so a security team can approve it quickly. Name the single host, say the traffic is JSON-RPC over HTTPS from developer machines, and say that spending is still gated on the Sume side by the credential you use. With OAuth, paid tools need the write scope; with an API key, paid calls need an idempotency key, and an optional max spend can cap each call.

Because a blocked server now fails on the first attempt, you will see the failure sooner in a fresh session. If your team scripts Claude Code in CI behind the same proxy, run the curl check in the job first and fail with a clear message when the host is not reachable.