Device-code sign-in never completes on Linux app under WSL (browser shows "device is now connected", app keeps waiting)
- Dominant language
- No language data
- Stars
- 2.1k
- Forks
- 153
- PR merge metrics
- No merged PRs in 30d
Description
**Short summary**
Device-code sign-in never completes when the Linux desktop app runs inside WSL:
the browser shows "Your device is now connected" but the app stays on "waiting
for authentication" forever and never signs in.
**Affected version or release**
GitHub Copilot app `1.0.5` (Linux `.deb`, x64).
**Installation context**
Linux `.deb` (`github` 1.0.5) running **inside WSL2 (Ubuntu 24.04) via WSLg** on
Windows 11 (10.0.26200). WSLg is healthy and the app launches/renders normally;
the only problem is sign-in. WSL 2.6.3.0 / WSLg 1.0.71. Bundled Copilot CLI 1.0.64.
**What happened?**
Starting sign-in shows a device code and opens the (Windows) browser. After
entering the code and authorizing, the browser
shows **"Your device is now connected"**, but the app **stays on "waiting for
authentication" indefinitely** and never signs in. `~/.copilot/data.db`
`github_accounts` stays at **0 rows**; the app keeps polling but never obtains a
token.
The device flow, the account, and the network are all fine — I confirmed by
reproducing the flow manually with the app's own client_id
via `curl`: the `/login/device/code` request and the `/login/oauth/access_token`
poll both succeed and return a valid token for the same account within seconds
of authorizing. So the failure is in the **app's in-app poll**, not
GitHub/account/network.
Likely cause: a mismatch between the `device_code` the app polls and the
`user_code` it presented/copied. The app log shows the WSL clipboard fallback
failing: `arboard ... wayland data control ... failed ... Falling back to the X11
clipboard protocol`. (Separately, the keychain is unavailable in WSL —
`org.freedesktop.secrets ... not provided` → "DB fallback storage" — but that is
post-token storage, not the cause; the token never reaches the app.)
The **native Windows build signs in fine with the same account**, which is why
this only reproduces in WSL.
**Steps to reproduce**
1. On Windows 11 with WSL2 (Ubuntu 24.04) + WSLg, install the Linux `.deb`
(`github` 1.0.5) and launch the app inside WSL (it renders normally).
2. Click sign in → the app shows a device code and opens the browser
(`wslview` → Windows browser).
3. Enter the code at https://github.com/login/device and authorize the app.
4. Browser shows "Your device is now connected".
5. The app stays on "waiting for authentication" and never completes.
**Expected behavior**
After authorizing in the browser, the app's device-flow poll picks up the token
and signs in — as it does on the Windows build, and as a manual `curl`
device-flow does with the same client_id and account.
**Additional context**
- Manual reproduction (proves the flow + account + network work):
```
POST https://github.com/login/device/code client_id=Ov23ctr1Udn5GokVCVJf -> user_code
POST https://github.com/login/oauth/access_token client_id + device_code + grant_type=...:device_code
-> returns a valid access_token within seconds of authorizing
```
- App log excerpts (redacted): `start_github_device_auth`; repeated
`reqwest::connect: starting new connection: https://github.com/` (the polls)
with no token/sign-in; `System keychain unavailable; ... DB fallback storage`;
`arboard ... wayland data control ... failed`.
- The redacted log excerpts above are provided in lieu of a full
`/collect-debug-logs` bundle; happy to provide more detail on request.
- Related (different but adjacent): #56 (closed, macOS — same "Waiting for
authentication" symptom after authorizing), #62 (closed, Linux — Enterprise
SSO callback launches a new instance).
- Workaround that confirms the diagnosis: running the device flow manually and
injecting the resulting account row into `~/.copilot/data.db` `github_accounts`
makes the app sign in (`has_auth_token=true`) — i.e. the only missing piece is
the in-app poll consuming the already-granted authorization.
Contributor guide
Research direction
Start at `start_github_device_auth` and the device-flow polling path; compare the `device_code` used by the poll with the code presented in the WSL flow, using the reported arboard/Wayland fallback logs as context. Done means authorization completes in WSL, a token is consumed by the app, and `~/.copilot/data.db` contains a row in `github_accounts`.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux
- Domain
- authentication, desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100