`gh auth login` doesn't poll for success unless you press enter to open web

[david-crespo]

Describe the bug

I ran gh auth login and when I got to the web login step, I cmd+clicked the link (ghostty) to open it in my browser and enter the code. After a successful login on the web, the CLI never changed state to reflect my successful login. Eventually it occurred to me to do what it actually says and try pressing Enter to open the browser for the login step, and that time it worked.

$ gh auth login
? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations on this host? HTTPS
? How would you like to authenticate GitHub CLI? Login with a web browser

! First copy your one-time code: XXXX-XXXX
Press Enter to open https://github.com/login/device in your browser...

To me this suggested the CLI doesn't poll for successful login until you press enter. I was able to confirm this by running GH_DEBUG=api gh auth login — if I press enter, I see the polling requests go through every 10 seconds or so. If I don't press enter, nothing happens.

Affected version

$ gh version
gh version 2.88.1 (2026-03-12)
https://github.com/cli/cli/releases/tag/v2.88.1

Expected vs actual behavior

I expect the login to work whether I click the link or press enter to open it. Maybe this is developer brain but I think of the Enter key as merely a shortcut to open the site, not as a load-bearing event in the login process.

[david-crespo]

I had CC with Opus 4.6 confirm what's going on in the code and that it's not new. The text below was drafted by Claude and then heavily edited by me.

---

The issue spans two repos: cli/cli provides callbacks, and cli/oauth orchestrates the device flow.

cli/cli: BrowseURL blocks on stdin

gh provides a BrowseURL callback that calls waitForEnter(), blocking on a line read from stdin:

cli/internal/authflow/flow.go

Lines 61 to 84 in 37800dd

	BrowseURL: func(authURL string) error {
	if u, err := url.Parse(authURL); err == nil {
	if u.Scheme != "http" && u.Scheme != "https" {
	return fmt.Errorf("invalid URL: %s", authURL)
	}
	} else {
	return err
	}
	if !isInteractive {
	fmt.Fprintf(w, "%s to continue in your web browser: %s\n", cs.Bold("Open this URL"), authURL)
	return nil
	}
	fmt.Fprintf(w, "%s to open %s in your browser... ", cs.Bold("Press Enter"), authURL)
	_ = waitForEnter(IO.In)
	if err := b.Browse(authURL); err != nil {
	fmt.Fprintf(w, "%s Failed opening a web browser at %s\n", cs.Red("!"), authURL)
	fmt.Fprintf(w, " %s\n", err)
	fmt.Fprint(w, " Please try entering the URL in your browser manually\n")
	}
	return nil
	},

cli/oauth: sequential flow with no concurrent polling

The oauth library's DeviceFlow() calls that callback synchronously — polling cannot begin until it returns:

1. L42–46: Request a device code from GitHub.
2. L48–57: Call DisplayCode callback (prints the one-time code).
3. L64: Call BrowseURL callback — blocks here until the callback returns.
4. L68–71: device.Wait() begins polling — only reachable after step 3.

History

The code has worked this way since the auth flow was first written. The waitForEnter call inside BrowseURL dates back to at least January 2022, and the waitForEnter helper itself was added in September 2020. The cli/oauth library's DeviceFlow has always been sequential — polling was never started concurrently with the browser prompt.

Possible fix approach

In cli/oauth, start device.Wait() polling in a goroutine before calling BrowseURL, so polling runs concurrently with the callback regardless of whether it blocks. Trying to fix it on the gh side (e.g., spawning waitForEnter + browser open in a goroutine) would leave a goroutine blocked on stdin that can swallow input meant for later prompts.

[BagToad]

Thanks for the issue @david-crespo. This is intended behavior, so I'll correct the label and leave this open as an enhancement request.

[github-actions]

Thank you for your issue! We have categorized it as an enhancement (feature or improvement) request, and it has been added to our backlog. In doing so, we are not committing to implementing this feature at this time, but, we will consider it for future releases based on community feedback and our own product roadmap.

Unless you see the help wanted Contributions welcome label, we are not currently looking for external contributions for this feature.

If you come across this issue and would like to see it implemented, please add a thumbs up! This will help us prioritize the feature. Please only comment if you have additional information or viewpoints to contribute.

[a-lebedzeu-e]

Ran into this as well (clicked the link from an IDE) and had to google to overcome the issue.