[BUG] macOS desktop app "Continue with SSO" hangs — app cancels its own OAuth network connection right after opening the browser

Preflight Checklist

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

What's Wrong?

Environment

• Claude desktop app version: 1.49585.0 (Electron 44.2.0)
• Claude Code CLI version: 2.1.236 (works fine, see below)
• macOS version: 26.6.2 (Build 25G83)
• Browsers tested: Safari and Chrome (both as default browser) — same result with both
• Not MDM-enrolled (profiles status -type enrollment → "MDM enrollment: No"), so this is not related to an Enterprise/Platform SSO extension

Summary

Clicking "Continue with SSO" in the Claude macOS desktop app opens a browser window/tab, but the tab stays blank (no URL, no loading indicator, no content) and the login never completes. claude login via the CLI works correctly on the same machine, so this appears to be specific to the desktop app's SSO flow.

Steps to reproduce

1. Open the Claude desktop app (macOS, signed out).
2. Click "Continue with SSO".
3. Observe: default browser opens, but the resulting tab/window is blank — no URL populated, no page loads.
4. Meanwhile claude login in the terminal, on the same machine, completes normally.

Diagnostic detail (from log stream --predicate 'process == "Claude"' while reproducing)

• 14:22:45.819 — app calls into macOS's AppSSO framework: (AppSSOCore) canPerformAuthorizationWithURL → SOAuthorizationCore ... result = NO (expected/normal on a non-MDM-managed Mac, confirmed not the cause).
• 14:22:45.820 — app activates the com.apple.SafariLaunchAgent XPC connection (i.e. it asks the system to open the default browser).
• 14:22:47.346–14:22:47.383 — the browser briefly becomes the frontmost app, then loses frontmost status back to Claude ~37ms later.
• 14:22:48.557–14:22:48.567 — the Claude app itself opens an HTTPS/TLS connection ("Connection 1", CFNetwork, attribution: developer) and then actively cancels it: cancel() → BoringSSL SSL_shutdown (clean close_notify) → TCP FIN. This is a self-initiated cancel by the app process, not a server reset or a network/proxy failure.

This suggests the desktop app's OAuth handshake starts a request (possibly polling/waiting for the browser callback, or fetching the actual auth URL to hand to the browser) and cancels it prematurely — before the browser ever receives a valid URL to render, which is consistent with the browser tab staying blank.

Expected behavior

"Continue with SSO" should open the browser to a valid authorization URL and complete the login, as it does via claude login in the CLI.

Workaround

Using claude login in the terminal works reliably. (Note: this does not appear to authenticate the desktop app — it uses a separate credential store.)

What Should Happen?

Browser should be opened with a website to login and/or a redirect back to the Claude desktop app

Error Messages/Logs

Steps to Reproduce

1. Open the Claude desktop app (macOS, signed out).
2. Click "Continue with SSO".
3. Observe: default browser opens, but the resulting tab/window is blank — no URL populated, no page loads.
4. Meanwhile claude login in the terminal, on the same machine, completes normally.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude 1.49585.0 (41ad1d) 2026-09-08T05:21:03.000Z

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_