The Signal Said Untrusted. The Configuration Answered Anyway.

A workspace trust check exists to answer one question before anything else runs: should this environment be treated as trusted, or not. Google Gemini CLI's own v0.59.0 changelog and the pull request behind it describe a version of that check that could return the right answer, untrusted, and still not have that answer control what happened next.

What the two sources each state

Google Gemini CLI's own v0.59.0 changelog, published 8 September 2026 and read at a rolling latest-release URL this record pins to that specific entry rather than to whatever the same page shows after a later release, lists two hardening bullets under headings of their own: Fail-Closed Workspace Trust, "Enforced a fail-closed workspace trust model to ensure security by default when accessing untrusted workspaces," and Restricted Mode MCP Filtering, "Filtered available Model Context Protocol (MCP) servers under restricted execution modes to minimize potential attack surfaces." Each bullet, read on its own, names a security-default improvement without stating the mechanism it replaces.

google-gemini/gemini-cli pull request 29099, merged 28 August 2026 and titled by its own author "fix(core): enforce fail-closed workspace trust and filter mcpServers in restricted mode," supplies that mechanism directly. Its own description states that the fix works by "immediately returning { isTrusted: false, source: 'env' } when an untrusted signal is present," and that "When !trusted, strips repository-scoped mcpServers definitions" from the A2A server's own configuration. The same description states the fix "prevents unintended process execution during server startup and ensures that environment trust signals take precedence over configuration fallbacks." Read together with the changelog's own two headings, the pull request names what those headings summarize: a workspace trust resolution step that previously did not always give an untrusted or restricted environment signal the final word over a more permissive configuration fallback, and an A2A server configuration path that could still carry a repository's own mcpServers entries, an executable process definition, independently of that unresolved trust question.

Reading the prior condition precisely, without inventing a mechanism

Neither source states the exact prior code path that let an untrusted signal fall through, whether that path was an explicit fallback branch, a default value, or an ordering defect among several trust sources, or how long the prior behavior shipped before this fix. This record treats that mechanism as unknown rather than reconstructing it from the fix's own one-line description, the same discipline this desk applies to a terse vendor changelog bullet elsewhere in this corpus. What the pull request's own words do establish, plainly, is the shape of the prior gap: workspace trust is meant to be the authority-relevant fact deciding what a repository's own configuration is allowed to keep running, and before this fix, that fact did not always win against configuration inherited from elsewhere.

What this record does not claim

This record does not claim the prior condition was ever reached in a real deployment, exploited, or produced a downstream consequential effect; no CVE, advisory, affected version range, or reported incident accompanies either source. It does not claim that every mcpServers entry a repository could configure is inherently unsafe, or that MCP server configuration is itself the failure; a repository legitimately configuring its own MCP servers is ordinary, intended behavior once a workspace is actually trusted. It does not claim per-server human authorization was ever missing for any specific MCP server an operator actually ran; that fact, like exploitation, is unknown from material available to this record. What it does claim, resting on the vendor's own two sources, is narrower and precise: a resolved workspace trust state, the provenance of a repository's own configuration, and a bootstrap-added MCP server's own capability to execute are each authority-relevant execution state, and none of resource readability, configuration presence, process capability, or a successful prior startup is evidence that continuing legitimate authority existed for what ran.

Where this sits in the pattern

This desk's own base case for execution authority failure, capability substituting for authorization because nothing else does, already carries a structurally identical known example: Claude Code v2.1.259 fixed managed settings silently going unenforced when a policy source could not be parsed, previously letting a session continue as though no policy applied, and now refuses to start and names the failing source instead. Gemini CLI's own fix reaches the same shape through a different mechanism: not a policy source failing to parse, but an environment trust signal not reliably taking precedence over a configuration fallback, and a repository's own already-configured MCP servers not being removed once that signal applied. Both are the same corrective, described in this desk's own terms as deny by default when the applicable authority decision cannot be established, applied at two different points in two different agent runtimes' own bootstrap sequences.

This record also distinguishes the gap from two adjacent, better-known shapes it does not resemble. It is not a model-controllable switch deciding whether its own control applies, the shape this desk already tracks separately: the trust signal here is an environment-supplied fact about the workspace, not an input traveling in the same call as the action it gates. It is also not reachability mistaken for authority: the prior condition was not that a discoverable or reachable MCP server was treated as authorized because an agent could reach it; it is that a repository's own MCP server configuration was not reliably removed from consideration at all once the workspace's own trust state should have removed it, a configuration-provenance question this record keeps separate from a reachability question.