github / github/app

Device-code sign-in never completes on Linux app under WSL (browser shows "device is now connected", app keeps waiting)

Open
#1,319 0 comments 0 reactions 0 assignees View on GitHub
Bugs
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.