Copilot CLI `/login` hangs after device code approval in VS Code Dev Container (Debian 12, WSL2 host)

[andliang]

Describe the bug

When I run copilot inside a VS Code Dev Container and use /login, the CLI prints a device code and URL. I approve the code at https://github.com/login/device (the page confirms it), but the CLI never completes and stays stuck.

Observed output:

Waiting for authorization...
Failed to open browser (exit code 4). Please visit https://github.com/login/device
 and enter the code <CODE> manually.

After approving the code in the browser, the terminal continues to show “Waiting for authorization…” indefinitely until I Ctrl-C.

Affected version

0.0.394

Steps to reproduce the behavior

1. VS Code → “Dev Containers: Reopen in Container”.
2. In the container terminal, run: copilot
3. At the interactive prompt, type: /login
4. Copy the device code shown and open https://github.com/login/device on the host; paste the code and approve.
5. Return to the terminal: it remains on “Waiting for authorization…” indefinitely (never finishes).

Expected behavior

After approving the device coAfter approving the device code in the browser, the CLI completes login and I can use Copilot.
de in the browser, the CLI completes login and I can use Copilot.

Additional context

Container:

• Debian GNU/Linux 12 (bookworm)
• Kernel: Linux 6.6.87.2-microsoft-standard-WSL2
• No proxy (HTTP(S)_PROXY/NO_PROXY unset)
• DNS: /etc/resolv.conf → nameserver 192.168.65.7 (Docker Desktop)
• Reachability from container:
  • https://github.com/login/device → 302
  • https://api.github.com → 200
  • https://api.githubcopilot.com → 404 (HEAD), resolves and connects
• VS Code server env present (e.g., TERM_PROGRAM=vscode, DISPLAY=:9)

Copilot CLI:

• Version: 0.0.394 (Commit 3d79feb)
• Two binaries on PATH:
  • ~/.vscode-server/data/User/globalStorage/github.copilot-chat/copilotCli/copilot (243 bytes)
  • ~/.local/bin/copilot (138,284,224 bytes)
• node v20.20.0, npm 11.7.0
• gh not installed in the container

Host:

• Windows 11 + WSL2 + Docker Desktop
• VS Code 1.108.1

Tried:

• Multiple codes and attempts; restarts of container, VS Code, and Docker Desktop
• Reinstalled CLI (local binary exists), but the extension-provided shim is first on PATH
• Verified time, DNS, and HTTPS connectivity from the container

[williammartin]

Could you try to reproduce this again in a new session that you start with --log-level all, and check the output of the /session command for the location of that log file. In particular, I'm interested to see whether there are any Received slow_down messages.

[MaxDNG]

I am experiencing a similar issue on WSL2/Ubuntu 22.04. Copilot 0.0.394, node 22.16.0, npm 11.6.1, gh installed VS Code 1.108.2

Here are the logs I have (I see several slow_down as you suggest)

[DEBUG] [loginUI] Starting access token polling for host=https://github.com, expires_in=899s, interval=5s
[DEBUG] [loginUI] Poll attempt 1, elapsed=0s/899s, interval=5s
[DEBUG] [fetchAccessToken] Requesting access token from https://github.com/login/oauth/access_token
[DEBUG] [fetchAccessToken] Response status: 200 
[DEBUG] [fetchAccessToken] Response body: {"error":"authorization_pending","error_description":"The authorization request is still pending.","error_uri":"https://docs.github.com/developers/apps/authorizing-oauth-apps#error-codes-for-the-device-flow"}
[DEBUG] [fetchAccessToken] Authorization pending - user has not yet authorized
[DEBUG] [loginUI] Sleeping for 5s before next poll
[DEBUG] [loginUI] Poll attempt 2, elapsed=5s/899s, interval=5s
[DEBUG] [fetchAccessToken] Requesting access token from https://github.com/login/oauth/access_token
[DEBUG] [fetchAccessToken] Response status: 200 
[DEBUG] [fetchAccessToken] Response body: {"error":"slow_down","error_description":"Too many requests have been made in the same timeframe.","error_uri":"https://docs.github.com","interval":10}
[DEBUG] [fetchAccessToken] Slow down response received - polling too frequently
[DEBUG] [loginUI] Received slow_down, increasing interval to 10s
[DEBUG] [loginUI] Sleeping for 10s before next poll
[DEBUG] [loginUI] Poll attempt 3, elapsed=15s/899s, interval=10s
[DEBUG] [fetchAccessToken] Requesting access token from https://github.com/login/oauth/access_token
[DEBUG] [fetchAccessToken] Response status: 200 
[DEBUG] [fetchAccessToken] Response body: {"error":"slow_down","error_description":"Too many requests have been made in the same timeframe.","error_uri":"https://docs.github.com","interval":15}
[DEBUG] [fetchAccessToken] Slow down response received - polling too frequently
[DEBUG] [loginUI] Received slow_down, increasing interval to 15s
[DEBUG] [loginUI] Sleeping for 15s before next poll

[MaxDNG]

Probably same as #503 BTW.

[williammartin]

Yeh so recently I got to the bottom of a long running issue on gh, and it turns out that the monotonic clock on WSL VMs can tick faster than real world time, so while we're trying to respect the slow down interval, we're always polling too fast. The easy solution is to add a margin of error, so will probably get that shipped and then see whether anything else is going on.