Gemini CLI trusted folders: keep a cloned repo from configuring your agent

The short answer

Turn on folder trust in your user settings ("security": { "folderTrust": { "enabled": true } }); it’s disabled by default.¹ After that, opening Gemini CLI in a folder you haven’t trusted runs it in a restricted mode: the project’s .gemini/settings.json is ignored, its .env isn’t loaded, its MCP servers don’t connect, its custom commands don’t load, tool auto-acceptance is off, and extensions can’t be installed or changed.¹ You decide per folder, and can revisit with /permissions.¹

One context note: Gemini CLI’s docs say it was replaced by Antigravity CLI on 18 June 2026 for unpaid-tier and Google One users.¹

Why a repository can be an attack

When you clone a project and start a coding agent in it, the agent reads files that the project’s authors wrote. Some of those files aren’t code; they’re agent configuration:

A pull request that adds an MCP server or loosens auto-approval is a change to your machine’s behaviour the moment you open the branch. That’s the risk folder trust addresses: the agent shouldn’t take configuration from a folder you haven’t vouched for.

What an untrusted folder loses

From the docs:¹

The auto-acceptance row means a trusted user setting like auto-approval doesn’t carry into an untrusted folder either. In practice, a repository you’re only reviewing gets a careful agent, not your everyday one.

Turning it on

In ~/.gemini/settings.json:¹

Code Data in JSON, the format software uses to pass records and settings.

{
  "security": {
    "folderTrust": {
      "enabled": true
    }
  }
}

Trust decisions are stored in ~/.gemini/trustedFolders.json; GEMINI_CLI_TRUSTED_FOLDERS_PATH moves the file.¹ For a team, put the setting in the system overrides file (/etc/gemini-cli/settings.json on Linux, /Library/Application Support/GeminiCli/settings.json on macOS), which has the final say over user and workspace settings.²

The trusted folders file is worth backing up and reviewing occasionally. Every entry is a folder whose configuration your agent will obey.

The three choices, and which to pick

When you open an untrusted folder, the dialog offers:¹

• Trust folder: fully trusts this folder.
• Trust parent folder: trusts the parent directory and everything under it.
• Don’t trust: restricted safe mode.

Our rule of thumb:

“Trust parent folder” is the convenient option that quietly widens over time. A repository you clone next month into a trusted parent gets full trust without a dialog.

Reviewing a repository safely

Opening a stranger’s repository with an agent is a normal part of code review now. A short routine keeps it boring:

1. Open it untrusted. Choose “Don’t trust” in the dialog.
2. Read the agent files first. Look at .gemini/, .mcp.json, .claude/, .cursor/, .codex/ and .github/hooks/ before anything else. They tell you what the project wants your agent to do.
3. Ask the agent questions, not for changes. In restricted mode every tool call prompts anyway; keep it to reading.
4. Trust only when it’s yours. If you fork it and start working, trust your fork, not the original clone.

CI and headless runs

In headless environments such as CI, there’s no one to answer the dialog. Without a decision, an untrusted folder makes the CLI exit with a FatalUntrustedWorkspaceError. --skip-trust, or GEMINI_CLI_TRUST_WORKSPACE=true, trusts the workspace for that session only.¹

That flag is safe when the workspace is your own code at a commit you chose. It’s not safe when CI runs on pull requests from forks: the fork’s .gemini/settings.json and MCP servers become trusted for the run. In that case, run the agent on a checkout that excludes agent configuration, or don’t run it on untrusted branches at all. The same reasoning applies to any CI job that runs untrusted code with credentials, as our Amazon Q extension post shows from AWS’s own bulletins.

The same idea in other agents

Folder trust isn’t unique to Gemini CLI. Codex loads a project’s .codex/ hooks only when the project is trusted³, and in Claude Code a committed .claude/settings.json applies its permissions.allow rules only after each person trusts the folder, while its deny and ask rules apply right away.⁴ Our hooks across agents post covers where each agent reads project files from. The common lesson: agent configuration in a repository is code, and should be reviewed and trusted like code.

A checklist

• security.folderTrust.enabled: true in user or system settings.
• Repositories under review opened with “Don’t trust.”
• No “trust parent” on folders that collect clones.
• ~/.gemini/trustedFolders.json reviewed now and then.
• --skip-trust used only in CI on code you control.
• Pull requests that add or change agent configuration reviewed like CI changes.
• A sandbox and deny rules for the folders you do trust; see Gemini CLI yolo mode.

To check a repository’s agent configuration before you trust it, paste its MCP config into the check page or run npx deedglass scan in the folder (how the grade works); the scan Action does the same on pull requests. To try tool-call rules in your browser, open the playground.

Written with AI assistance and checked against our claims register.