Web auth redirect hangs after device-code approval ("Failed to fetch user info after auth") on Windows ARM v1.0.15
- Langage dominant
- Aucune donnée de langage
- Étoiles
- 2.1k
- Forks
- 153
- Métriques de merge des PR
- Aucune PR mergée en 30 j
Description
### Summary
On the GitHub Copilot app **v1.0.15 (Windows on ARM / arm64)**, web-based authentication does not complete. After approving the device code, the browser lands on the "You are being redirected to the authorized application… if your browser does not redirect you back, please visit this setup page to continue" page, and the app stays stuck on the device code. When it does proceed, it fails with **"Failed to fetch user info after auth."**
### Environment
- App version: **1.0.15**
- OS: **Windows 11 on ARM (arm64)**
- Network: home network, **direct connection** (no VPN/proxy)
- Recently switched account sign-in to **passkey (phone)**
### Steps to reproduce
1. Launch the app and start sign-in (web/device-code flow).
2. Approve the one-time code at `github.com/login/device` (approved with phone passkey).
3. Browser shows the "redirecting to the authorized application… visit this setup page to continue" screen.
4. App remains stuck on the device code, then errors with **"Failed to fetch user info after auth."**
### Expected
App receives the token and loads the signed-in user; models become available.
### Actual
Auth never completes in-app despite GitHub reporting the app as connected.
### Diagnostics (environment ruled out)
The account, token, network, and API are all healthy — the failure is app-side:
- GitHub Status: all systems operational (incl. Copilot + AI Model Providers).
- `curl -I https://api.github.com` → 200; `api.githubcopilot.com` and `copilot-proxy.githubusercontent.com` reachable.
- Direct TLS to GitHub's real IP via schannel; **no proxy/TLS interception**.
- **`gh api user` returns the correct username** from the same machine — so `/user` and the token clearly work, but the app still reports "Failed to fetch user info."
### Workaround
**Downgrading the app** got things working again. Two notes from the process:
- Downgrading too far (to **1.0.12**) failed to launch with a DB schema incompatibility — `database schema version 50 is newer than this app supports (max 47)` — because the existing `data.db` had been migrated by a newer build. The working downgrade had to target a build that supports the current DB schema.
- Out of desperation to get *anything* working, I ended up **deleting `data.db`** (`%USERPROFILE%\.copilot\data.db`), which let the older app start with a fresh database — at the cost of losing local session history/state.
### Impact
Fresh/re-auth on Windows ARM is blocked on v1.0.15; no models load until a downgrade. Possibly related to the passkey sign-in method.
Guide de contribution
Ouvrir le guide de contribution
Piste de recherche
Start with the web/device-code sign-in flow and the user-info fetch that follows approval; reproduce the failure on Windows ARM with app v1.0.15. Use the reported %USERPROFILE%\.copilot\data.db behavior and the working gh api user result as comparison points. Done means approval returns to the app, the signed-in user loads, and models become available without downgrading.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Évaluation
- Domaine
- authentication, desktop
- Type d'issue
- Bug
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Activité
- Calme
- Clarté
- Plutôt claire
- Accessibilité débutants
- 45/100