feat(cli): add full-access approval controls

[emersonbusson]

Summary

• Add --full-access as the preferred privileged approval flag while keeping --yolo as a deprecated alias.
• Accept full_access and full-access approval mode aliases in CLI parsing.
• Enable sandbox defaults for privileged approval mode and update user-facing copy away from YOLO wording.

Validation

• npx vitest run packages/cli/src/config/config.test.ts packages/cli/src/config/sandboxConfig.test.ts packages/cli/src/ui/hooks/useApprovalModeIndicator.test.ts
• npm test -w @google/gemini-cli -- src/config/config.test.ts src/config/sandboxConfig.test.ts src/ui/hooks/useApprovalModeIndicator.test.ts
• npm run typecheck --workspace @google/gemini-cli
• npm run lint --workspace @google/gemini-cli
• npm run build --workspace @google/gemini-cli
• git diff --check origin/main...HEAD

Related Issues

Related to #21432

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request standardizes the CLI's privileged approval controls by introducing a formal '--full-access' flag. It improves the user experience by deprecating the informal 'YOLO' terminology in favor of clearer language, while maintaining backward compatibility for existing scripts. Additionally, it enhances security by defaulting to sandbox mode when these privileged modes are active.

Highlights

• Approval Mode Renaming: Introduced '--full-access' as the primary flag for privileged approval, while marking '--yolo' as a deprecated alias.
• CLI Configuration: Updated CLI argument parsing to support 'full_access' and 'full-access' as valid approval mode values.
• Sandbox Defaults: Enabled sandbox mode by default when using privileged approval modes, ensuring safer execution for auto-approved tool calls.
• User-Facing Copy: Refactored UI and error messages to replace 'YOLO' terminology with 'Full Access' for a more professional tone.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize the Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counterproductive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request rebrands "YOLO mode" to "Full Access mode" across the CLI, documentation, and UI. It introduces a new --full-access flag, deprecates the --yolo flag (treating it as an alias), and adds support for full_access and full-access values in the --approval-mode option. Additionally, the changes include logic to automatically enable the sandbox when a privileged approval mode is active and improve error reporting when multiple conflicting approval flags are provided. I have no feedback to provide.

[emersonbusson]

Rebased this PR onto current origin/main and reran the validation from the PR description.

Root cause: the privileged approval mode is still exposed primarily through --yolo / YOLO terminology, and the CLI does not provide a clearer preferred --full-access spelling for the same compatibility-preserving behavior.

Approach: add --full-access as the preferred flag, keep --yolo as a deprecated alias for backward compatibility, accept full_access / full-access approval-mode aliases, update user-facing copy toward Full Access wording, and preserve the existing underlying approval-mode semantics.

Validation after rebase:

• npx vitest run packages/cli/src/config/config.test.ts packages/cli/src/config/sandboxConfig.test.ts packages/cli/src/ui/hooks/useApprovalModeIndicator.test.ts
• npm test -w @google/gemini-cli -- src/config/config.test.ts src/config/sandboxConfig.test.ts src/ui/hooks/useApprovalModeIndicator.test.ts
• npm run typecheck --workspace @google/gemini-cli
• npm run lint --workspace @google/gemini-cli
• npm run build --workspace @google/gemini-cli
• git diff --check origin/main...HEAD

I kept the issue reference as Related to #21432 rather than Fixes, because this PR is scoped to adding the preferred Full Access spelling and compatibility aliases, not necessarily closing the broader roadmap item. Since this PR has the 🔒 maintainer only label and is currently priority/p3, could a maintainer confirm whether this external contribution is acceptable, or whether this should be handled as an issue/discussion first?