`claude mcp login` fails with OAuth `invalid_client` against Snowflake-managed MCP server, despite verified-valid credentials

Having a similar issue on mac with a similar connector type.

Hitting this exact same issue independently — Snowflake-managed MCP server, custom OAuth security integration, invalid_client at token exchange despite a successful browser consent. Adding what we found in case it helps narrow it down further, since some of it goes a bit beyond what's in the report above.

Environment: Custom OAuth security integration (OAUTH_CLIENT = CUSTOM), tested as both OAUTH_CLIENT_TYPE = PUBLIC and with real secrets generated for that same PUBLIC integration (OAUTH_CLIENT_SECRET/OAUTH_CLIENT_SECRET_2). Snowflake-managed MCP server resource under api/v2/.../mcp-servers/.... Federated SSO (non-Snowflake IdP) in front of Snowflake's own native OAuth authorization server.

Additional isolation we ran, on top of what's already reported here:

Same asymmetry as reported: a garbage/never-issued code returns invalid_grant; a real, freshly-issued code from a completed browser consent returns invalid_client instead — every time, sub-second exchange (rules out code expiry).

Tried every combination of: no secret / OAUTH_CLIENT_SECRET / OAUTH_CLIENT_SECRET_2, client_secret_post / client_secret_basic, scope=session:role:all / scope=session:role:<specific pre-authorized role>, RFC 8707 resource parameter present/absent, and all three of the integration's allowed authorization/token hostnames. All produce the identical invalid_client.

Confirmed the role active during every attempt was not on BLOCKED_ROLES_LIST.

Reproduced it with Snowflake's own official snowflake-connector-python (v4.7.1), using its native authenticator="OAUTH_AUTHORIZATION_CODE" support with PKCE — completely independent of Claude Code or any MCP client. Its own debug log shows the browser/consent leg completing successfully (step 2: received OAuth callback, requesting token), then the token request itself getting back the identical body:

{"data":null,"error":"invalid_client","code":null,"message":"This is an invalid client.","success":false,"headers":null}

The connector's own top-level exception (Invalid HTTP request from web browser...) is a misleading wrapper — the debug log makes clear the real cause is this invalid_client response, not a local listener problem.

Between this and the "not stale config" test already reported above (fresh integration, same failure), plus this now reproducing through Snowflake's own connector, it seems hard to explain by anything on the client side — Claude Code, a from-scratch curl/PKCE implementation, and Snowflake's own Python driver all hit the same wall against a real, validly-issued code.

We also checked SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY for any record of these attempts, same idea as reported above, and got the same result: no row anywhere shows authorizing_integration_name matching our integration — not a success, not a failure — despite multiple real, successfully-completed browser consents within the same hour we ran the query (and we confirmed this isn't just ACCOUNT_USAGE ingestion lag; the most recent unrelated login rows were from the same few minutes as the query itself). Whatever rejects the token exchange happens at a point this view doesn't track at all.

Filing this as our own internal Snowflake support case too, but wanted to add it here in case Anthropic engineering has visibility into anything shared between our two setups.

Following up — we hit this exact same invalid_client symptom (real, validly-issued code from a completed browser consent, invalid_grant only for a garbage code, reproduced identically through Snowflake's own snowflake-connector-python independent of Claude Code) and eventually got it fully resolved. Posting the root cause and fix in case it saves someone else the same multi-week detour.

Root cause: network-policy precedence, not client auth. OAuth token exchange for a custom security integration is only evaluated against an account-level or integration-level network policy — never the user-level one that governs interactive/browser logins. Our integration was silently inheriting a restrictive account-level policy (effectively a deny-all for anything not explicitly listed) that had never been updated for this use case. Every symptom we chased — different scopes, different client-secret variants, different auth methods, different hostnames, zero rows in SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY for the attempts — was consistent with a network-layer block happening before the request ever reached application logic, which is also why it never showed up in that view at all.

Fix, allow Claude's actual egress IPs on the network policy attached to the integration:

ALTER NETWORK POLICY <policy_name>
  SET ALLOWED_IP_LIST = ('<your corporate egress IP/CIDR>', '<Claude egress IP/CIDR>', ...);

ALTER SECURITY INTEGRATION <integration_name>
  SET NETWORK_POLICY = <policy_name>;

Anthropic publishes their current outbound IP ranges here: https://platform.claude.com/docs/en/api/ip-addresses

Also needed, to get Claude Code itself (not just a manual script) authenticating: even after the network fix, Claude Code's own claude mcp login still failed against a CONFIDENTIAL client. Claude Code currently has no mechanism to supply a client secret to an already-configured MCP server entry — MCP_CLIENT_SECRET is only ever read at claude mcp add time, not at login, and a policy-managed entry can't be locally re-added to trigger that path. So the actual fix that got everything working end to end was switching the integration to OAUTH_CLIENT_TYPE = PUBLIC (keeping OAUTH_ENFORCE_PKCE = TRUE) — Claude Code's built-in OAuth flow needs no secret and just works once the network policy above is in place.

Worth being explicit: PUBLIC here isn't a weaker/less-secure fallback — access is still gated by the network policy (only allowed IPs can reach the token endpoint at all), PKCE, and your existing SSO/IdP login requirement. Switching to PUBLIC just removes a secret Claude Code had no way to supply anyway; it doesn't expose the integration any further.

Two things worth knowing if you go this route: OAUTH_CLIENT_TYPE is immutable on an existing integration — switching requires CREATE OR REPLACE SECURITY INTEGRATION, which issues a new client_id you'll need to update in your MCP config. And if Claude Code was already running, it caches the resolved MCP server config in memory — a config file edit alone won't be picked up until you fully quit and restart the CLI process, not just reconnect within the same session.

(If you need to stay on CONFIDENTIAL for policy reasons, a headersHelper script — a newer Claude Code MCP config option — can mint/refresh a bearer token server-side using a securely stored refresh token + the client secret, but it's meaningfully more setup and per-user renewal overhead than the above.)

Hope this closes the loop for anyone else stuck on the same wall we were.

— Vinod Madigatla

Resolved on our end (root cause + fix in the comment above) — closing since this seems to have been dormant. Feel free to reopen if others are still hitting it.