fix(core): remove OAuth check from handleFallback and clean up stray file (#21962)

packages/core/src/fallback/handler.test.ts

@@ -59,7 +59,6 @@ vi.mock('../utils/debugLogger.js', () => ({
 const MOCK_PRO_MODEL = DEFAULT_GEMINI_MODEL;
 const FALLBACK_MODEL = DEFAULT_GEMINI_FLASH_MODEL;
 const AUTH_OAUTH = AuthType.LOGIN_WITH_GOOGLE;
-const AUTH_API_KEY = AuthType.USE_GEMINI;
 
 const createMockConfig = (overrides: Partial<Config> = {}): Config =>
   ({
@@ -129,16 +128,6 @@ describe('handleFallback', () => {
       );
     });
 
-    it('should return null immediately if authType is not OAuth', async () => {
-      const result = await handleFallback(
-        policyConfig,
-        MOCK_PRO_MODEL,
-        AUTH_API_KEY,
-      );
-      expect(result).toBeNull();
-      expect(policyHandler).not.toHaveBeenCalled();
-    });
-
     it('uses availability selection with correct candidates when enabled', async () => {
       // Direct mock manipulation since it's already a vi.fn()
       vi.mocked(policyConfig.getModel).mockReturnValue(

packages/core/src/fallback/handler.ts

@@ -5,7 +5,6 @@
  */
 
 import type { Config } from '../config/config.js';
-import { AuthType } from '../core/contentGenerator.js';
 import {
   openBrowserSecurely,
   shouldLaunchBrowser,
@@ -29,10 +28,6 @@ export async function handleFallback(
   authType?: string,
   error?: unknown,
 ): Promise<string | boolean | null> {
-  if (authType !== AuthType.LOGIN_WITH_GOOGLE) {
-    return null;
-  }
-
   const chain = resolvePolicyChain(config);
   const { failedPolicy, candidates } = buildFallbackPolicyContext(
     chain,

pr-description.md

@@ -1,65 +0,0 @@
-## Summary
-
-This PR implements a seamless migration path for extensions to move to a new
-repository and optionally change their name without stranding existing users.
-
-When an extension author sets the `migratedTo` field in their
-`gemini-extension.json` and publishes an update to their old repository, the CLI
-will detect this during the next update check. The CLI will then automatically
-download the extension from the new repository, explicitly warn the user about
-the migration (and any renaming) during the consent step, and seamlessly migrate
-the installation and enablement status while cleaning up the old installation.
-
-## Details
-
-- **Configuration:** Added `migratedTo` property to `ExtensionConfig` and
-  `GeminiCLIExtension` to track the new repository URL.
-- **Update checking & downloading:** Updated `checkForExtensionUpdate` and
-  `updateExtension` to inspect the `migratedTo` field. If present, the CLI
-  queries the new repository URL for an update and swaps the installation source
-  so the update resolves from the new location.
-- **Migration & renaming logic (`ExtensionManager`):**
-  - `installOrUpdateExtension` now fully supports renaming. It transfers global
-    and workspace enablement states from the old extension name to the new one
-    and deletes the old extension directory.
-  - Added safeguards to block renaming if the new name conflicts with a
-    different, already-installed extension or if the destination directory
-    already exists.
-  - Exposed `getEnablementManager()` to `ExtensionManager` for better typing
-    during testing.
-- **Consent messaging:** Refactored `maybeRequestConsentOrFail` to compute an
-  `isMigrating` flag (by detecting a change in the installation source). The
-  `extensionConsentString` output now explicitly informs users with messages
-  like: _"Migrating extension 'old-name' to a new repository, renaming to
-  'new-name', and installing updates."_
-- **Documentation:** Documented the `migratedTo` field in
-  `docs/extensions/reference.md` and added a comprehensive guide in
-  `docs/extensions/releasing.md` explaining how extension maintainers can
-  transition users using this feature.
-- **Testing:** Added extensive unit tests across `extension-manager.test.ts`,
-  `consent.test.ts`, `github.test.ts`, and `update.test.ts` to cover the new
-  migration and renaming logic.
-
-## Related issues
-
-N/A
-
-## How to validate
-
-1. **Unit tests:** Run all related tests to confirm everything passes:
-   ```bash
-   npm run test -w @google/gemini-cli -- src/config/extensions/github.test.ts
-   npm run test -w @google/gemini-cli -- src/config/extensions/update.test.ts
-   npm run test -w @google/gemini-cli -- src/config/extensions/consent.test.ts
-   npm run test -w @google/gemini-cli -- src/config/extension-manager.test.ts
-   ```
-2. **End-to-end migration test:**
-   - Install a local or git extension.
-   - Update its `gemini-extension.json` to include a `migratedTo` field pointing
-     to a _different_ test repository.
-   - Run `gemini extensions check` to confirm it detects the update from the new
-     source.
-   - Run `gemini extensions update <extension>`.
-   - Verify that the consent prompt explicitly mentions the migration.
-   - Verify that the new extension is installed, the old directory is deleted,
-     and its enablement status carried over.