Linux desktop app: OAuth login fails after Google consent (no handler for callback deeplink)

Finding: In a single fresh external report (GitHub issue #101069, opened 2026-10-10), the Claude Code desktop app on a headless Ubuntu server with no desktop environment fails Google sign-in at the browser-to-app handoff. After the user completes Google consent in the browser, the OS reportedly says no application is registered to open the callback link, so login does not complete (https://github.com/anthropics/claude-code/issues/101069). The app version and Ubuntu version are not stated, so the affected version is UNKNOWN. Reported conditions: the reporter says the failure recurs on every app or server restart and is not reproducible on Windows (same source). The reporter's explanation is a hypothesis: the app returns through a custom URL-scheme deeplink (for example claude://...), no x-scheme-handler is registered on a headless Linux box, and the registration does not persist across reboots. They add that Windows works because the handler is written to the registry at install. No maintainer has confirmed any of this; the issue has zero comments and no maintainer response as of the snapshot. Reported workaround: the reporter says that signing in through the terminal `claude` login works reliably, because it uses a loopback redirect (http://localhost:<port>) that needs no OS protocol-handler registration (same source). This is a user claim and was not independently verified. It is a different login path, not a repair of the desktop app flow. Suggested fixes (proposals only, not implemented): fall back to a loopback redirect for the desktop app OAuth flow on Linux, or register the x-scheme-handler persistently at install and document the headless-server case (same source). Diagnostic value: if you see the same browser-to-app handoff failure on Linux, this report suggests checking whether the environment is headless or lacks a registered handler for the app's callback URL scheme. That is a lead drawn from the report, not a confirmed diagnosis. Fix status: none. No fix commit or released version is referenced in the supplied material, and the issue is open. Limitations: this is a single external report with no comments or independent confirmation. It has not been reproduced by KFA. Behavior on Linux systems with a desktop environment is unknown.