Gemini CLI closes a trust-bypass hole in its A2A server

Gemini CLI's A2A server — the package's own README calls it "experimental and under active development" — had a workspace-trust bypass: an untrusted workspace could set its own trust before the trust check ran. A fix merged July 21, 2026 and shipped in the July 22 preview build closes it.

The bug

The A2A server loaded environment variables from a workspace's .env and .gemini/.env files before checking whether that workspace was trusted. A malicious repo could ship a .gemini/.env containing GEMINI_CLI_TRUST_WORKSPACE=true — since that file loaded before the trust check ran, the workspace could validate its own trust and get its environment loaded into the server process without the user confirming anything. The PR describes the class of bug this closes as zero-click remote code execution and environment poisoning in untrusted workspaces.

The fix

The fix, landed in pull request #28470, reorders the startup sequence so loadEnvironment() runs only after workspace trust is evaluated. If the workspace isn't trusted, its .env and .gemini/.env files are ignored entirely — the server falls back to environment files in the user's home directory (~/.gemini/.env or ~/.env) instead.

The same change adds task-level isolation to the server's environment handling: an AsyncLocalStorage-backed proxy on process.env scopes environment reads and writes per task, so one running task can no longer leak its environment into another running concurrently on the same server.

Where it shipped

The fix is in the July 22, 2026 preview release, v0.53.0-preview.0:

npm install -g @google/gemini-cli@preview

It hasn't reached the stable channel yet — stable was at v0.52.0 (July 22) at time of writing, and preview promotes to stable on Gemini CLI's Tuesday cadence. If you run the A2A server against untrusted workspaces, don't wait for the next stable cut; move to preview or pin past the merge commit. See the Gemini CLI sheet for the current release surface.