Daily Edition Sources +3

A Restricted Workspace Should Not Start Its Own Tools

Gemini CLI now gives an explicitly restricted or untrusted workspace a narrower configuration path: repository-defined tools, MCP servers, policies and telemetry no longer accompany its A2A server into startup.

Marker diagram showing a restricted-mode signal crossing out repository MCP, policy, tool and telemetry cards before an A2A server receives trusted configuration.
Diagram Punkrestricted should cut repository startup authority before the server sees it.
repo google-gemini/gemini-cli evidence
3 source signals 1 repo commit 0bd1d43
Evidence: commit 0bd1d43 / August 29, 2026 / Daily Edition
Open Edition Evidence below

A project folder can do more than hold code. In an agent workflow it can also describe servers to start, policies to load, tools to enable and places to send telemetry. Gemini CLI’s merged workspace-trust change makes one boundary explicit: when the environment says the workspace is restricted or untrusted, those repository-supplied settings must not make the trip into the A2A server’s startup configuration.

The first reading was too small: filter an MCP configuration and move on. The final main-branch diff filters five families when the A2A server is not trusted: mcpServers, policy paths, admin-policy paths, tool settings and telemetry. That matters because each family is a different claim by a checkout about what an agent should execute, permit or report.

Trust has to win before configuration is assembled

At the core, the change makes an explicit GEMINI_RESTRICTED_MODE=true or an explicit false workspace-trust signal win before folder or IDE fallbacks. The A2A loader then creates a safe view of the repository settings rather than mutating the caller’s original object. Its new tests assert that the server sees none of those configuration families when trust is false—and that it keeps them when trust is true.

The pull request’s public review trail explains why the distinction grew. Early review findings did not stop at MCP servers: policy paths, admin-policy paths and tools could also let a repository influence the server’s authority. The merged version strips all of them, plus telemetry. That is a more useful security shape than a single blacklist: decide whether the workspace is trusted, then keep its startup instructions out of the privileged path until it is.

The next audit question is concrete

For a maintainer or operator, this turns “do we trust this project?” into a testable question: can an untrusted checkout cause any repository-defined server, policy, tool or telemetry route to be active before an explicit trust decision? The public receipts show intended main-branch behavior, not a shipped release, a complete audit or every Gemini CLI execution path. The signal to watch is release guidance—and tests beyond this A2A path—that make the same answer visible wherever a project can shape an agent runtime.

Evidence Trail

Receipts below the story

The article above is the public narrative. This section keeps the source trail and limits on the same page.

Edition
DateAugust 29, 2026
LaneDaily Edition
Confidence78%
Sources3
Reposgoogle-gemini/gemini-cli

Primary Evidence

  • Gemini CLI workspace-trust change: pull request #29099
    • Shows: the merged public change's stated purpose: environment trust signals take precedence in restricted or untrusted contexts, and repository-defined MCP server configuration is filtered before A2A server startup.
  • Gemini CLI implementation: commit 0bd1d439
    • Shows: the exact main-branch implementation that returns an untrusted result for restricted-mode or explicit false-trust environment signals and removes MCP servers, policy paths, admin-policy paths, tool settings and telemetry from the untrusted A2A-server configuration.
  • Gemini CLI trust tests: workspace-trust test
    • Shows: focused tests that the sensitive configuration families are absent when trusted is false and present when it is true; they also exercise restricted environment signals.

Evidence Limits

  • These receipts establish a merged main-branch implementation and its intended test behavior. They do not establish that a released Gemini CLI build contains it, that every entry point uses the same path, or that the code is a complete security guarantee.
  • Watch for release documentation and additional public tests that specify how restricted mode and every repository-controlled extension or configuration surface behave in practice.
Letters & Corrections

Send a note to the desk

Corrections, missing context, or a follow-up lead.