Fix login hang on Linux when the browser isn't already running#3859
Open
Kuenec wants to merge 1 commit into
Open
Fix login hang on Linux when the browser isn't already running#3859Kuenec wants to merge 1 commit into
Kuenec wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
q login (and downstream kiro-cli login) hangs forever on Linux when the browser isn't already running. The login flow awaits open_url_async before it starts accepting connections on the OAuth callback server, and open_url_async uses .output(), which pipes stdout/stderr and waits for the child to exit. On desktops xdg-open doesn't recognize (Hyprland, sway, etc) it runs the browser in the foreground, so a freshly launched browser inherits those pipes and never exits. Result: the CLI waits for the browser to close while the browser tab waits for the callback response.
I hit this with kiro-cli 2.10.0 on Arch Linux under Hyprland and traced it on a live hang: the callback request was sitting unread in the listener's accept backlog (Recv-Q 760) while the freshly started browser held the write ends of the CLI's stdout/stderr pipes. With the browser already running the opener hands off and exits, which is why login normally works.
Fix: spawn the opener with stdin/stdout/stderr on /dev/null and wait for exit with a 5 second cap. A quick non-zero exit (no handler available, headless box) is still reported as a failure so the device flow fallback keeps working. If the opener is still running after 5 seconds it's fronting the browser, which means the URL was opened, so we treat it as success. cargo check passes.