Prompt for folder trust before slow startup auth

[Alvin0412]

Describe the bug

When Gemini CLI starts in an interactive workspace whose folder trust state is still unknown, startup can perform slow initialization work before asking the user whether to trust the folder. In practice this makes the CLI look stuck before the folder trust prompt appears, especially when auth or remote account checks take several seconds.

The trust decision is local and determines whether project settings, hooks, MCP servers, skills, and context files may be loaded. It should be resolved before slow auth/network startup work.

Steps to reproduce

1. Use a fresh Gemini CLI home so the current directory has no trust rule.
2. Start Gemini CLI interactively from that directory.
3. Observe that the trust prompt may be delayed by startup/auth work instead of appearing immediately.

Example shape of the reproduction:

GEMINI_CLI_HOME=$(mktemp -d) gemini

Expected behavior

For an interactive, non-headless launch with an unknown trust state, Gemini CLI should ask for the folder trust decision before starting auth or other slow initialization.

If the user chooses to trust the folder, the CLI can save the decision and relaunch so workspace settings and local configuration are loaded under the new trust state. If the user chooses not to trust it, startup can continue with project-local configuration disabled.

Additional context

This is especially noticeable when auth/account checks take multiple seconds. The terminal appears idle even though the next required action is a local trust decision.

[gemini-cli]

This issue requires reordering the CLI's startup sequence to perform workspace trust checks before authentication, involving cross-component refactoring and process relaunching logic.

This issue reports a UX delay during startup. Please provide your CLI version to help us investigate.

Effort Analysis:
The current startup sequence in packages/cli/src/gemini.tsx performs loadSettings() and then proceeds to initializeApp(), which executes slow authentication work via performInitialAuth(). The folder trust prompt is currently implemented as a React component triggered by the useFolderTrust hook in packages/cli/src/ui/AppContainer.tsx, which renders only after initializeApp() completes. Resolving this requires moving the trust prompt logic to the early bootstrap phase in gemini.tsx. This involves: 1) Executing FolderTrustDiscoveryService.discover() (from packages/core/src/services/FolderTrustDiscoveryService.ts) to scan for project-local assets before auth; 2) Implementing a terminal-based interactive prompt using the prompts library within gemini.tsx; and 3) Utilizing the RELAUNCH_EXIT_CODE mechanism (defined in packages/cli/src/utils/processUtils.js and handled by relaunchOnExitCode) to restart the CLI process once trust is granted, ensuring all project-local configurations are correctly re-loaded. This level of asynchronous reordering and cross-component state management maps to effort/medium.

[Alvin0412]

Thanks. The affected CLI version I reproduced this with is:

• gemini --version: 0.46.0
• binary path: /opt/homebrew/bin/gemini
• local checkout/package version used for the fix: 0.48.0-nightly.20260609.g3a13b8eeb

I also opened PR #27845 with the startup reordering described here: resolve unknown folder trust before auth/slow startup work, save the selected trust level, and use the existing relaunch path after trust is granted so local project configuration is reloaded.

[gemini-cli]

This item was marked as needing more information and has not received a response in 14 days. Closing it for now. If you still face this problem, feel free to reopen with more details. Thank you!