Overview

Gemini CLI's action boundary is a sequence: workspace trust determines whether project-supplied influence enters, policy evaluates a named tool and its arguments, confirmation supplies a human decision when required, and sandboxing plus environment sanitization constrain an authorized process. This chapter explains restrictions on untrusted workspaces, approval modes, Plan Mode's limited writes, headless behavior, path and network permissions, protected and secret files, and scoped sandbox expansion. It also preserves an important release-specific boundary: the selected snapshot contains conflicting signals about some trust defaults and policy-tier examples, so effective settings and active policy must be checked. These layers reduce reach and risk without certifying project code, extensions, commands, or outcomes.

Learning outcomes

Workspace trust governs project-supplied influence; it does not certify a trusted folder's code, dependencies, or services as harmless.
Policy can allow, deny, or ask based on tools, arguments, modes, servers, and interactive state; approval is not execution.
Sandboxing and sanitization constrain paths, networks, files, mounts, and environment variables, but they reduce risk rather than eliminate it.

Keywords

Gemini CLItrustsandboxpolicyconfirmationsanitization

Where Action Stops: Trust, Policy, Confirmation, and Sandboxing

Gemini CLI's safety boundary is a sequence, not a single switch. Before a requested command or edit can affect a machine, the project may be inspected for trust, the tool call can be evaluated by policy, a person may be asked to confirm it, and the execution can be restricted by a sandbox and a sanitized environment. This chapter follows that sequence so readers can choose an operating mode deliberately and understand what each layer does—and what it cannot do.

The distinction matters in an ordinary code task. A model may receive an instruction from a repository, propose an edit, and ask to run a test. Those events do not have the same authority. The repository's instructions may or may not be loaded. The edit may be a registered capability but still require approval. The test may be allowed by policy but blocked by a sandbox path or network restriction. Gemini CLI's design is easiest to understand when each transition has a clear question: may this project influence the agent, may this tool call proceed, and where may the resulting process reach?

sequenceDiagram actor User participant CLI as Gemini CLI participant Trust as Workspace trust participant Policy participant Confirm as Confirmation participant Sandbox participant Tool User->>CLI: Request a file change or command CLI->>Trust: Discover project configuration alt Workspace is untrusted Trust-->>CLI: Restricted operation CLI-->>User: Prompt or headless failure else Workspace is trusted Trust-->>CLI: Project influence permitted end CLI->>Policy: Evaluate tool, arguments, mode, and environment alt Policy denies Policy-->>CLI: Deny without execution CLI-->>User: Explain blocked request else Policy asks Policy->>Confirm: Request approval Confirm-->>User: Show intended operation alt User cancels Confirm-->>CLI: Cancel else User approves Confirm-->>CLI: Proceed end else Policy allows Policy-->>CLI: Proceed end CLI->>Sandbox: Prepare paths, network, and environment alt Extra permission is required Sandbox-->>CLI: Expansion request CLI->>Confirm: Ask for scoped expansion Confirm-->>CLI: Approve or cancel end CLI->>Tool: Execute within prepared boundary Tool-->>CLI: Result, error, or denial

The diagram shows a typical mutating request, not a promise that every read requires approval. It also separates two kinds of trust. Workspace trust concerns project-supplied influence and configuration. Tool policy concerns a particular capability and its arguments. Sandboxing concerns the environment in which an authorized process runs. A strong workflow uses the layers together rather than asking one layer to solve every problem.

Trust decides what the project may influence

A repository is not only source code. It can contain configuration, context files, custom commands, skills, hooks, agents, MCP server definitions, and environment files. Some of those inputs can change what Gemini CLI loads or what processes it starts. Folder trust exists to keep a project from silently supplying that influence before the user has evaluated it.

When trust checking is active, Gemini CLI performs a discovery phase before the trust decision.

Published by DeepMox

FAQ

What does workspace trust control in Gemini CLI?

Workspace trust controls whether project-supplied settings, memory, MCP connections, custom commands, and related configuration may influence Gemini CLI; it does not certify the project as harmless.

What are Gemini CLI's policy decisions?

Gemini CLI's policy engine can allow a tool call, deny it, or ask the user for confirmation based on the tool, arguments, mode, environment, and other matched conditions.

Can Gemini CLI sandboxing guarantee safety?

No. Gemini CLI sandboxing limits execution reach and can sanitize environments, but it reduces risk rather than guaranteeing a wise goal, harmless command, or trustworthy external service.

Previous11 minGemini CLI Controlled System

Next14 minGemini CLI Extensions and MCP

Gemini CLI Trust and Sandboxing

Where Action Stops: Trust, Policy, Confirmation, and Sandboxing

Trust decides what the project may influence

FAQ