Claude Desktop (macOS): SSO/login flow opens Safari instead of the system default browser

Description

On macOS, the SSO / authentication flow launched from Claude Desktop always opens Safari, ignoring the system default browser setting.

This breaks SSO for anyone whose identity-provider sessions (Google Workspace, Okta, etc.) live in their actual default browser. Safari is a cold profile with no active sessions, so the user is forced to either re-authenticate from scratch in a browser they don't use, or log into their corporate/Google account in Safari just to satisfy this one app. Neither is acceptable — the whole point of SSO is reusing an existing session.

Steps to reproduce

1. On macOS, set the default web browser to something other than Safari (System Settings → Desktop & Dock → Default web browser). In this case: Firefox.
2. Open Claude Desktop and trigger a sign-in / SSO flow.
3. Observe which browser opens.

Expected behavior

The auth URL is handed to the system default handler for https (e.g. via NSWorkspace.open(_:) / open <url>), so it opens in whatever browser the user has chosen — carrying their existing logged-in sessions.

Actual behavior

Safari opens, regardless of the default browser setting. The user lands on a login page with no active session.

Environment

• Claude Desktop 1.46388.4 (com.anthropic.claudefordesktop)
• macOS 26.0.1 (build 26A434), Apple silicon
• Default https handler confirmed as Firefox:

LSHandlerRoleAll = "org.mozilla.firefox";
LSHandlerURLScheme = https;

(from defaults read com.apple.LaunchServices/com.apple.launchservices.secure)

Notes

Likely causes worth checking: an SFSafariViewController / ASWebAuthenticationSession with prefersEphemeralWebBrowserSession, or a hardcoded Safari bundle ID rather than deferring to Launch Services. ASWebAuthenticationSession in particular uses Safari's web context on macOS and will not see Firefox/Chrome cookies — if that's the implementation, it should be swapped for opening the URL in the default browser with a loopback or custom-scheme redirect.

If this behavior is intentional (e.g. for security isolation), it should at minimum be configurable, since it makes SSO unusable for users whose sessions aren't in Safari.