Sign in via browser fails to redirect back to the app on Windows (protocol handler fragility)

## Summary

On Windows, the browser-based sign-in flow occasionally fails to redirect back to GitHub Desktop after the OAuth authorization succeeds in the browser. The app stays on the "Signing in…" spinner indefinitely.

This is a longstanding environmental issue (see #11410) — not a regression in any particular release. The root cause is that the custom protocol handler (`x-github-desktop-auth://`) used to redirect from the browser back to the running app is fragile and can be disrupted by several common Windows configurations.

## How the sign-in redirect works

1. User clicks "Sign in to GitHub.com" → browser opens the OAuth page
2. After authorization, the browser redirects to `x-github-desktop-auth://...`
3. Windows looks up the registered protocol handler and launches GitHub Desktop with `--protocol-launcher`
4. Since Desktop is already running, Electron's single-instance lock delivers the URL to the existing process

Failure at **step 3** (protocol not registered / registry conflict) or **step 4** (IPC fails) causes the infinite loading.

## Symptoms

- Browser shows "OAuth application authorized" or "You are being redirected…"
- GitHub Desktop stays on the loading spinner forever

## Community-reported workarounds

The following have resolved the issue for various users over the years. **We have not been able to reliably reproduce this issue**, so these are ⚠️ **not officially verified fixes — not all of these will work for everyone**.

### 1. Disable "Run as Administrator" on GitHub Desktop (most common fix)

If GitHub Desktop runs elevated but the browser does not, the protocol redirect cannot cross the privilege boundary.

1. Open the Start menu → search for **GitHub Desktop**
2. Right-click → **Open file location**
3. Right-click the shortcut → **Properties** → **Compatibility** tab
4. **Uncheck** "Run this program as an administrator"
5. Restart GitHub Desktop and try signing in again

### 2. Change your default browser (temporarily)

Some browsers handle the `x-github-desktop-auth://` protocol redirect differently. Switching the system default browser to **Microsoft Edge** (or another browser) and retrying has resolved it for many users.

### 3. Uninstall and reinstall GitHub Desktop

A fresh install re-registers the protocol handlers. Run the installer **as administrator** to ensure the registry entries are written correctly.

### 4. Clear browser cookies/cache for github.com

Stale OAuth session state in the browser can cause the redirect to fail silently.

### 5. Manually invoke the protocol URL (advanced)

If the browser shows "click here to continue" after authorization:
1. Right-click the link → copy the URL (starts with `x-github-desktop-auth://`)
2. Open **Command Prompt**
3. Run: `start x-github-desktop-auth://THE-FULL-URL-HERE`

### 6. Verify/fix the registry entry (advanced)
> [!WARNING]
> Caution: Incorrectly modifying the Windows Registry can cause serious system problems. Only proceed if you are comfortable navigating the registry, and consider exporting a backup of the key before making changes

1. Open **Registry Editor** (`regedit`)
2. Search for `x-github-desktop-auth`
3. Confirm the `shell > open > command` value points to your GitHub Desktop executable with `--protocol-launcher "%1"`
4. If it points to a Mac version (Parallels) or an outdated path, correct it

### 7. Check for conflicting software

- **Parallels/VMware** shared app settings can hijack the protocol to the host OS
- **Antivirus / firewall** software may block IPC between processes

## Related issues

- #11410 — Original long-running thread (closed, locked)

Start by testing the Windows browser sign-in flow and tracing the custom x-github-desktop-auth:// protocol through the --protocol-launcher entry point and Electron single-instance delivery. Compare failures at protocol registration and IPC delivery, using the listed workarounds and related issue #11410 as context. Done means the failure is reproduced with a verified cause and the redirect reliably returns to the running app, or the remaining limitation is clearly documented.

Written by the indexing model from the issue text.