Issue Station
Sign In
Tools hereToolbox

gemini-cli - ✅(Solved) Fix Strict auth consent throws opaque error due to startup race [2 pull requests, 1 comments, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
google-gemini/gemini-cli#25458•Fetched 2026-04-16 07:06:11
View on GitHub
Comments
1
Participants
1
Timeline
6
Reactions
0
Author
nbardynbardy
Participants
nbardynbardy
Timeline (top)
cross-referenced ×2commented ×1labeled ×1mentioned ×1

Error Message

Users in certain auth states see an opaque error on startup with no path forward. Non-interactive / headless environments hit this consistently. 2. Observe generic "Authentication consent could not be obtained" error

Root Cause

Proposal

  • Guard emitConsentRequest on listenerCount > 0 (load-bearing — naive drainBacklogs approach deadlocks because UI doesn't mount until refreshAuth returns)
  • Throw FatalAuthenticationError with a clear message pointing to interactive use or NO_BROWSER=true
  • Let the UI's ValidationDialog handle re-auth after mounting
  • Fix related credential-clearing issues that compound the problem

Fix Action

Fixed

PR fix notes

PR #23232: fix(core): resolve strict auth consent and credential clearing issues

Description (problem / solution / changelog)

This PR resolves a microtask race condition during early authentication that caused the UI to throw an opaque 'Authentication consent could not be obtained' error. By leveraging coreEvents.drainBacklogs(), the event is queued safely until the UI listener finishes mounting.

Additionally, this pipes the actual underlying error into the emitFeedback payload when clearCredentials fails, ensuring users and telemetry capture why file deletion or keychain eviction failed rather than returning a generic message.

Changed files

  • packages/core/src/code_assist/oauth-credential-storage.test.ts (modified, +16/-16)
  • packages/core/src/code_assist/oauth-credential-storage.ts (modified, +3/-3)
  • packages/core/src/utils/authConsent.test.ts (modified, +16/-4)
  • packages/core/src/utils/authConsent.ts (modified, +2/-9)

PR #25463: fix(core): resolve strict auth consent and credential clearing issues

Description (problem / solution / changelog)

Fixes #25458

Summary

Resolves two related auth-path issues:

  1. Opaque "Authentication consent could not be obtained" on startup. A naive "queue the event and await" approach deadlocks because refreshAuth() runs before the Ink UI mounts its ConsentRequest listener — the UI never gets to mount. Keep the listenerCount > 0 guard (documented in code), and when no listener is present throw FatalAuthenticationError with a clear message pointing to interactive use or NO_BROWSER=true. The error is caught upstream; the UI's ValidationDialog handles re-auth after mounting.
  2. Credential-clearing swallowed underlying errors. clearCredentials now pipes the actual underlying error into emitFeedback so users and telemetry see why file deletion / keychain eviction failed instead of a generic message.

Changes

  • packages/core/src/utils/authConsent.ts — listenerCount guard with explanatory comment; throw FatalAuthenticationError on missing listener
  • packages/core/src/code_assist/oauth-credential-storage.ts — propagate underlying error into feedback
  • Tests updated to reflect new throw-behavior

Test plan

  • vitest run packages/core/src/utils/authConsent.test.ts — all pass
  • Manual: start in a state that requires re-auth and confirm clear error → ValidationDialog path
  • Manual: corrupt a credential file and confirm the real error surfaces in feedback

Replaces #23232 (auto-closed per contribution policy). Supersedes the earlier drainBacklogs approach in that PR, which we found deadlocks at startup.

Changed files

  • packages/core/src/code_assist/oauth-credential-storage.test.ts (modified, +16/-16)
  • packages/core/src/code_assist/oauth-credential-storage.ts (modified, +3/-3)
  • packages/core/src/utils/authConsent.ts (modified, +8/-0)
RAW_BUFFERClick to expand / collapse

Bug

On startup, refreshAuth() runs before the Ink UI mounts its ConsentRequest listener. The auth consent path emits the event into a void and throws a generic "Authentication consent could not be obtained" with no actionable guidance.

Impact

Users in certain auth states see an opaque error on startup with no path forward. Non-interactive / headless environments hit this consistently.

Repro

  1. Start CLI in a state requiring OAuth re-consent
  2. Observe generic "Authentication consent could not be obtained" error

Proposal

  • Guard emitConsentRequest on listenerCount > 0 (load-bearing — naive drainBacklogs approach deadlocks because UI doesn't mount until refreshAuth returns)
  • Throw FatalAuthenticationError with a clear message pointing to interactive use or NO_BROWSER=true
  • Let the UI's ValidationDialog handle re-auth after mounting
  • Fix related credential-clearing issues that compound the problem

Related

Fix proposed in #23232 (closed per contribution policy).

extent analysis

TL;DR

Guarding emitConsentRequest on listenerCount > 0 and throwing a FatalAuthenticationError with clear guidance may resolve the authentication consent issue.

Guidance

  • Verify that the ConsentRequest listener is mounted before calling refreshAuth() to ensure the event is not emitted into a void.
  • Consider implementing a check for listenerCount > 0 before emitting the consent request to prevent the generic error.
  • Review the proposed fix in #23232 for additional guidance on handling related credential-clearing issues.
  • Test the changes in both interactive and non-interactive environments to ensure the fix works as expected.

Example

if (listenerCount > 0) {
  emitConsentRequest();
} else {
  throw new FatalAuthenticationError("Authentication consent could not be obtained. Please run in interactive mode or set NO_BROWSER=true.");
}

Notes

The proposed fix assumes that the listenerCount variable accurately reflects the number of mounted listeners. Additional testing may be necessary to ensure this fix works in all scenarios.

Recommendation

Apply the proposed workaround by guarding emitConsentRequest on listenerCount > 0 and throwing a FatalAuthenticationError with clear guidance, as this approach addresses the root cause of the issue and provides a clear path forward for users.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#prompt formatting#chain error#conversation history#tool integration#LLM response

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING