Editorial status: Human-reviewed and checked against official Gemini CLI documentation on August 24, 2026. Recheck the configuration schema and defaults before applying them.

Gemini CLI can read and edit files, execute shell commands, and load project-specific settings. Two important protections—folder trust and sandboxing—are documented as disabled by default, so a secure setup should enable them deliberately.

In ~/.gemini/settings.json, enable folder trust and sandboxing using the current configuration schema:

{
  "security": {
    "folderTrust": {
      "enabled": true
    }
  },
  "tools": {
    "sandbox": true
  }
}

Verify this example against the current Gemini CLI configuration reference because the settings format has changed before.

1. Enable Trusted Folders

Folder Trust prevents an untrusted project from automatically loading project settings, .env files, extensions, auto-accept rules, and additional memory sources. When prompted, trust the narrowest directory possible. Avoid “Trust parent folder” for a general downloads, home, or source-code directory containing repositories from different owners.

For an untrusted folder, Gemini CLI uses a restricted mode and asks before tool calls. That is a useful inspection state: review project instructions, .gemini/settings.json, extensions, package scripts, and documentation before granting trust.

2. Enable sandboxing

Gemini CLI supports macOS Seatbelt and container-based sandboxing with Docker or Podman. The command-line flag is --sandbox or -s, and the GEMINI_SANDBOX environment variable can also select a mode.

On macOS, choose a profile based on network needs. A closed profile is safer for local analysis and editing. Open or proxied profiles should be used only when the task needs network access.

Sandboxing reduces risk but does not eliminate it. Custom Docker flags can weaken isolation, and mounted project files remain accessible within the allowed boundary.

3. Avoid YOLO mode as a default

Gemini CLI documentation notes that sandboxing is enabled with YOLO approval mode, but automatic tool acceptance still expands risk inside the sandbox. A sandbox can limit blast radius; it does not make generated shell commands, dependency installs, or file deletions correct.

Use normal approvals for unfamiliar repositories, new extensions, MCP servers, authentication changes, and external actions.

4. Restrict tools with an allowlist

For managed environments, Google documents tools.core as the more secure approach compared with trying to block known-dangerous commands. Begin with read-only file and search tools, then add specific shell commands needed by the workflow.

Blocklists are easier to bypass because a dangerous action may have multiple command forms. A system-level configuration can enforce a baseline that project and user settings cannot weaken.

5. Protect credentials

Google warns that API keys and service-account paths exported into the shell can be read by processes launched from that shell. Prefer interactive account login where appropriate, short-lived credentials, minimal IAM roles, and disposable development projects.

Never commit .gemini/.env, application-default credentials, service-account JSON, or API keys. Remember that ignored files may still be readable by a tool unless filesystem access excludes them.

6. Review privacy and telemetry

Gemini CLI terms and data use depend on the authentication method and account type. The official privacy page states that personal-account usage may be used for product improvement or model training under the applicable notice. Teams handling proprietary code should select an account type and policy that match their requirements and configure usage-statistics preferences deliberately.

Secure-use checklist

  • Folder Trust enabled.
  • Only the specific repository trusted.
  • Sandbox enabled with network closed unless required.
  • No automatic acceptance for arbitrary tools.
  • Tool allowlist preferred over a blocklist.
  • Credentials scoped, uncommitted, and unavailable to unnecessary subprocesses.
  • Project .gemini configuration reviewed before trust.
  • Extensions and MCP servers verified and minimally scoped.
  • Git diff and tests reviewed before commit or deployment.

Official sources