fix(auth): prevent re-triggering Google login after ESC cancellation

[Red-Asuka]

TLDR

Fixed authentication dialog ESC key handling issues including Google login re-triggering and infinite retry loops. Implemented deferred auth settings persistence to preserve user configuration during cancellations, and enhanced error message handling to prevent ESC exit when errors are present.

Dive Deeper

Multiple ESC key handling issues were identified and resolved:

1. Auth cancellation bug: When user cancels Google authentication with ESC, subsequent ESC presses would incorrectly re-trigger the auth flow instead of showing proper error message.

2. Configuration corruption: The original approach of immediately saving selectedAuthType would break users' existing auth configurations in their settings.json when authentication fails or gets cancelled.

3. Infinite retry loops: When authentication fails with errors (e.g., missing environment variables), pressing ESC would cause infinite loops between "Waiting for auth" and error dialog.

The solution implements a deferred authentication pattern with the following improvements:

• Pending Auth Selection: Introduced pendingAuthSelection state to track auth choices without immediately persisting them to settings
• Deferred Persistence: Auth settings are now only saved after successful authentication, preventing configuration corruption during failures/cancellations
• Enhanced ESC Handling: ESC exit is blocked when error messages are present (|| errorMessage condition), requiring users to resolve issues before proceeding
• Automatic Retry: Existing saved auth methods are automatically loaded as pending selections for seamless re-authentication

Reviewer Test Plan

Test Case 1: Auth Cancellation (Updated)

1. Select "Login with Google" in the auth dialog
2. Wait for "Waiting for auth..." message to appear
3. Press ESC to cancel authentication
4. Verify you return to the auth dialog with your original settings intact
5. Press ESC again
6. Verify it shows "You must select an auth method to proceed" error message instead of re-opening Google login

Test Case 2: Configuration Preservation (Enhanced)

1. Ensure you have selectedAuthType configured in .gemini/settings.json
2. Follow Test Case 1 steps but let authentication fail
3. Verify your settings.json still contains the original selectedAuthType (not the failed attempt)
4. Restart the application and verify auto-authentication still works with your saved settings

Test Case 3: Error Message Handling (Enhanced)

1. Select "Login with Google" but ensure you have an account that will cause auth errors (e.g., missing GOOGLE_CLOUD_PROJECT)
2. Complete authentication but let it fail with error message
3. Press ESC in the auth dialog with error message displayed
4. Verify it shows "You must select an auth method to proceed" instead of creating infinite retry loop
5. Verify no invalid auth settings were saved to your configuration

Test Case 4: Deferred Persistence (New)

1. Start with no saved auth configuration
2. Select an auth method and intentionally cause authentication to fail
3. Verify no auth settings were written to settings.json
4. Select the same auth method and complete authentication successfully
5. Verify auth settings are now properly saved to settings.json

Testing Matrix

	🍏	🪟	🐧
npm run	❓	❓	❓
npx	❓	❓	❓
Docker	❓	❓	❓
Podman	❓	-	-
Seatbelt	❓	-	-

Linked issues / bugs

#1735 (comment)

[umairidris]

/gemini review

[gemini-code-assist]

Code Review

The pull request aims to fix a bug where cancelling Google authentication could lead to an infinite loop of auth prompts. The proposed change correctly clears the selected auth type from user settings. My review identifies a scenario where this fix is incomplete—if the auth type is set in workspace settings—and suggests a more robust state-based approach to fully resolve the issue.

[scidomino]

I think there's probably a more elegant way to do this that doesn't involve introducing new state to pass between files. The whole problem stems from the fact that we are saving the auth method to the settings before we know that they work. We shouldn't do that. Instead of handleAuthSelect just saving changes to settings we should change it to be a useState that simply stores the user's selection. then have the Effect only save that selection to the settings if performAuthFlow succeeds.

You can make the changes or I can get to that later today.

[scidomino]

Actually. I realize I have a few bugs to fix in this area anyways. I'll take care of this today.

[Red-Asuka]

@scidomino Thanks for the feedback! I've updated the PR to only save auth settings after successful authentication and removed the wasCancelled logic as suggested. Please take another look.

[scidomino]

This issue has been fixed in another PR so I will close this.