Summary

With Safari as the default browser, the sign-in flow now completes successfully (post #7776), but when Safari deep-links back into cmux (cmux://auth-callback), a zombie black window appears for about a second and then disappears before focus lands back on the real cmux window.

User report (verbatim): "the sign in with safari as default browser works now but whats weird is when we deeplink back in the cmux there is an zombie black window that appears for a second and then disappears before going back to the cmux app for some reason."

Environment

• Observed on the dev build from branch issue-7728-safari-signin-followup (PR Clear stuck sign-in state after Safari browser handoff #7776, merged 2026-07-10), i.e. current sign-in flow behavior.
• macOS, Safari set as the system default browser.

Steps to reproduce

1. Set Safari as the macOS default browser.
2. Start sign-in from cmux; the flow hands off to Safari (per Clear stuck sign-in state after Safari browser handoff #7776 the ASWebAuthenticationSession completes with the non-auth HTTPS handoff URL and the attempt is parked while the sign-in continues in Safari).
3. Complete sign-in in Safari so it deep-links back via cmux://auth-callback?....

Expected

Focus returns directly to the existing cmux window. No extra window appears.

Actual

A black, empty window flashes on screen for ~1 second, disappears, and only then does the real cmux window come to the front. Sign-in itself succeeds.

Leads (unverified, from code reading)

1. AuthPresentationContextProvider.resolveAnchor() (Packages/Shared/CmuxAuthRuntime/Sources/CmuxAuthRuntime/Presentation/AuthPresentationContextProvider.swift) has a macOS fallback that constructs a bare NSWindow() and calls makeKey() on it when NSApplication.shared.keyWindow and windows.first are both unavailable — plausibly the state while the user is off in Safari and cmux is background. A bare NSWindow() made key is exactly a small black zombie window. Any anchor re-resolution during the parked-attempt/late-callback path added in Clear stuck sign-in state after Safari browser handoff #7776 could hit this.
2. The ASWebAuthenticationSession window teardown when the parked attempt is resumed/cancelled by the incoming cmux://auth-callback (see HostBrowserSignInFlow.runBrowserSession non-auth completion handling and completeCallback) may briefly re-show the session window before dismissal.
3. URL-open reactivation path: macOS delivering the cmux:// URL may route through a reopen/untitled-window path that creates a window the app then immediately closes.

auth.* unified log lines (auth.browser.session.*, auth.callback.*) around the flash should narrow which of these it is.

Related

• macOS sign-in fails on first attempt when default browser is not Chrome (Safari); 'Open in default browser' needed every time (recurrence of #5849) #7728 (Safari default-browser sign-in failure; closed)
• PR Clear stuck sign-in state after Safari browser handoff #7776 (Clear stuck sign-in state after Safari browser handoff — the flow this flash occurs in)
• Sign-in fails when default browser is not Chrome (e.g. Safari) — auth callback never completes #5849 (earlier recurrence)