[BUG] Click Authorize pm Claude code would like to connect, doesn't do anything

[stuaxo]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When I start Claude code it goes to claude.ai/oauth/authorize ...

When I click Authorize, nothing happens, the page still has an authorize and decline button.

If I look at the JS console in firefox while the page initially loads there are a bunch of JS errors along the lines of NetworkError while fetching resource, like the following:

What Should Happen?

I click Authorize and can use claude code

Error Messages/Logs

From firefox's JS console:
-Security-Policy: The page’s settings blocked the loading of a resource (connect-src) at https://a-api.anthropic.com/v1/m because it violates the following directive: “connect-src 'self' https://api.segment.io/ https://*.segment.io https://*.segment.com https://a-cdn.anthropic.com/ https://*.google.com https://*.facebook.com https://*.facebook.net https://*.doubleclick.net” [analytics.min.js:1:23763](https://a-cdn.anthropic.com/analytics.js/v1/LKJN8LsLERHEOXkw487o7qCTFOrGPimI/analytics.min.js)

Steps to Reproduce

Open Claude Code in a devcontainer. Click the link to authorise, open it in firefox.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.50

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

No response

[stuaxo]

Clicking Authorize does nothing.

This was my initial experience with claude code, then it worked for a bit and now the error is back.

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Claude Chrome Extension - unable to Authorize #17790
2. [BUG] Claude in Chrome: Authorize button click handler empty, oauth_callback.html missing #17786
3. [BUG] Attempting to authenticate claude-code doesn't work on FIrefox/OSX because only listens on IPV6 localhost #16521

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[stuaxo]

Firefox console shows the POST to https://a-api.anthropic.com/v1/m is blocked.

[sstklen]

I've seen this pattern come up a few times. Sharing what worked in case it helps.

What's happening: The claude.ai OAuth authorize page has a Content-Security-Policy (CSP) header whose connect-src directive does not include https://a-api.anthropic.com/. When the page tries to POST analytics/telemetry data to https://a-api.anthropic.com/v1/m, Firefox strictly enforces CSP and blocks the request. The Authorize button's click handler likely chains through or depends on this analytics call completing — when it fails due to CSP, the promise chain breaks and the actual OAuth authorization POST never fires. This is a server-side CSP misconfiguration on Anthropic's end, not a client-side bug.

What worked for us:

This is an Anthropic server-side issue — the CSP header on claude.ai/oauth/authorize needs to be updated to include https://a-api.anthropic.com/ in the connect-src directive. End users cannot fix this directly. Workarounds: (1) Use Chrome/Chromium instead of Firefox, as Chrome may handle CSP-blocked analytics more gracefully without breaking the authorization flow, (2) Use a browser extension like 'Disable Content-Security-Policy' temporarily during authorization, (3) Use a Firefox extension to modify response headers and add https://a-api.anthropic.com/ to the CSP connect-src directive.

Steps:

1. SERVER-SIDE (Anthropic must fix): Add 'https://a-api.anthropic.com/' to the connect-src directive in the Content-Security-Policy header on claude.ai/oauth/authorize
2. SERVER-SIDE (better fix): Ensure the Authorize button's click handler does not depend on analytics requests succeeding — fire-and-forget analytics should not block the critical OAuth flow
3. USER WORKAROUND 1: Try using Chrome or Edge instead of Firefox for the authorization step
4. USER WORKAROUND 2: Install a Firefox extension like 'Disable CSP' or 'Header Editor', temporarily disable/modify CSP for claude.ai, complete authorization, then re-enable
5. USER WORKAROUND 3: In Firefox about:config, temporarily set security.csp.enable to false, authorize, then re-enable (not recommended for general browsing)

<!-- Anthropic server-side CSP header fix -->
<!-- Current (broken): -->
Content-Security-Policy: connect-src 'self' https://api.segment.io/ https://*.segment.io https://*.segment.com https://a-cdn.anthropic.com/ https://*.google.com https://*.facebook.com https://*.facebook.net https://*.doubleclick.net

<!-- Fixed: add https://a-api.anthropic.com/ -->
Content-Security-Policy: connect-src 'self' https://api.segment.io/ https://*.segment.io https://*.segment.com https://a-cdn.anthropic.com/ https://a-api.anthropic.com/ https://*.google.com https://*.facebook.com https://*.facebook.net https://*.doubleclick.net

<!-- Additionally, the authorize button handler should be resilient: -->
// Bad: authorization depends on analytics completing
// async onClick() { await sendAnalytics(); await submitAuth(); }

// Good: analytics is fire-and-forget
// async onClick() { sendAnalytics().catch(() => {}); await submitAuth(); }

📊 We found 1 similar case in our knowledge base with the same pattern — this gives us medium confidence in this analysis.

Let me know if this works for your setup — happy to help troubleshoot further. 🦞

Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying.

---

_{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}

[stuaxo]

security.csp.enable is not available since firefox 99.

Using chrome does work. It's probably not good it listens on localhost, it should probably be listening on something like 0.0.0.0 if it's in a container.

Could be a port issue.

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.