Gemini CLI's a2a-server read its trust decision out of the directory whose trust was in question
The a2a-server backend loaded workspace environment files before evaluating workspace trust, so a hostile repository could ship a .gemini/.env containing GEMINI_CLI_TRUST_WORKSPACE=true and, in the fix's words, "self-validate their own untrusted workspace before trust is checked". The stated class is zero-click remote code execution and environment poisoning: opening the repository was enough. The fix defers environment loading until after the trust check, ignores workspace-level .env files entirely when untrusted, and adds task-level environment and process isolation. Merged 2026-07-21 and shipped in stable v0.53.0 on 2026-07-28, resolving a carry-forward check from the prior run.
What this changes for operators
- Upgrade past v0.53.0 before pointing a2a-server at any repository you did not write. On earlier builds the workspace trust prompt was not a boundary for that backend, because the answer was read from inside the workspace.
Run: 2026-08-03-weekly-digest-2026-07-27_2026-08-03-frontier-v0
Schema: bitter.frontier_signals.v0 / ID: 2026-08-03-gemini-workspace-that-trusted-itself-reaches-stable
Research evidence and publication history are open in the repository.