Implement proper waiting for kwallet authentication

Describe the feature or problem you’d like to solve

When using gh cli after the kwallet has closed I need to type the password for opening it again.
For all applications I've used until this cli, the application simply waits until the wallet have either been opened or the request have been canceled.

With the gh cli it fail in what feels like 5 seconds - at least not enough for me to type the password.
This means that each time my wallet has closed I call the same command twice, once for opening the wallet and then failing the command and once for running the command.

Proposed solution

To have a way longer timeout, it doesn't have to be infinite but I think it has to be longer than seconds.
I think that most people won't be able to type the password in this short duration and I think 5 minutes should suffice.

Additional context

The flow I'm going through each time the wallet has closed:

$ gh repo view --web
HTTP 401: This endpoint requires you to be authenticated. (https://api.github.com/graphql)
Try authenticating with:  gh auth login
(1) $ gh repo view --web
Opening https://github.com/... in your browser.

Yeh at some point the previous maintainers put in a timeout of 3 seconds because it was hanging forever:

cli/internal/keyring/keyring.go

Lines 13 to 19 in e0d7ad7

    
           type TimeoutError struct { 
        
           	message string 
        
           } 
        
           func (e *TimeoutError) Error() string { 
        
           	return e.message 
        
           }

I'm actually surprised it has taken this long for someone to complain about this. I'm guessing a lot of people just have their wallets unlocked or something similar. Definitely think it would be worth us picking this up. 5 minutes feels like a long time though for those cases in which something is incorrectly configured. Maybe we could put some kind of progress indicator though, so that people have an expectation about what they should be seeing, or if they need to kill the program.

I'd love to hear a bit more about other tools that you use and how they act.

Yeh at some point the previous maintainers put in a timeout of 3 seconds because it was hanging forever:

cli/internal/keyring/keyring.go

Lines 13 to 19 in e0d7ad7
type TimeoutError struct {
message string
}

func (e *TimeoutError) Error() string {
return e.message
}

I'm actually surprised it has taken this long for someone to complain about this. I'm guessing a lot of people just have their wallets unlocked or something similar. Definitely think it would be worth us picking this up. 5 minutes feels like a long time though for those cases in which something is incorrectly configured. Maybe we could put some kind of progress indicator though, so that people have an expectation about what they should be seeing, or if they need to kill the program.

I'd love to hear a bit more about other tools that you use and how they act.

Yea well I've been using it like that for 7 month but yesterday was the day ;-)

So for Firefox, chromium or slack they just wait infinitely. I would guess that the way they do it is based on what the system does, i.e. Handle the cancel case or ok case.
You might also look into how kwalletquery does this. It is a cli tool for getting contents from the wallet, which again just waits.

However if you made this some reasonable timeout which also cover the time to write the password incorrectly I guess this is a setting that will settle well over time.

I'm hitting the same root cause here, but via a different Secret Service backend: a custom D-Bus service implementing org.freedesktop.secrets, backed by a password manager that requires interactive approval (biometric/Touch ID, or an "Allow" click in the desktop app) to release a secret.

When that approval step takes longer than the current 3-second timeout in internal/keyring/keyring.go, the request fails before the user can respond. The effect is the same as reported here, but with an extra wrinkle on the gh auth login side: a keyring write failure there doesn't just error out — it silently falls back to writing the token in plain text to hosts.yml (see #8954/#10108), so the failure mode is worse than just "have to retry the command."

+1 on making this configurable or at least meaningfully longer than 3s, ideally with some indication to the user that gh is waiting on the keyring rather than just hanging silently.

Would maintainers be open to a smaller stopgap fix — bumping the hardcoded timeout from 3s to ~60s — ahead of the larger design work here? Happy to put together a PR if that's welcome.

@kofuk

@kofuk yeah a low-code change like bumping the timeout would be fine and probably good enough. I'm not really sure what number to pick but 60s seems fine.

I'd accept a small PR for this.

@kofuk

@kofuk yeah a low-code change like bumping the timeout would be fine and probably good enough. I'm not really sure what number to pick but 60s seems fine.

I'd accept a small PR for this.

I think you should consider to have something that allows you to mistype the password and then try again. I think yes 60s might be sufficient, but looking into what fx kwalletquery does I think would be smart.

Opened #13787 with the stopgap fix (3s → 60s timeout).

On the mistype/retry point: the go-keyring interface we wrap just blocks and returns whatever the OS backend eventually returns — we can't distinguish "backend hung/broken" from "user still typing/retrying in an unlock prompt". A fixed timeout is a tradeoff between those two, and doing it properly (like kwalletquery) would need more signal from the backend or some progress/cancel UX. Worth tracking as follow-up beyond this stopgap.

Bump keyring operation timeout from 3s to 60s

This issue was auto-closed by Fixes #11005 in a PR that was only a stopgap fix, not the actual solution.
Could someone with permission please reopen it?

Merge pull request #1 from cli/trunk

Navigation Menu

Repository navigation

Implement proper waiting for kwallet authentication #11005

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	type TimeoutError struct {
	message string
	}

	func (e *TimeoutError) Error() string {
	return e.message
	}

Implement proper waiting for kwallet authentication #11005

Description

Describe the feature or problem you’d like to solve

Proposed solution

Additional context

Activity

williammartin commented on May 20, 2025

Quanalogy commented on May 21, 2025

kofuk commented on Jul 3, 2026

kofuk commented on Jul 3, 2026

BagToad commented on Jul 3, 2026

Quanalogy commented on Jul 3, 2026

kofuk commented on Jul 3, 2026

kofuk commented on Jul 18, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions