Gemini CLI: Trust, Env Loading, Memory Patches, and Release Channels Matter

What Changed

Gemini CLI v0.41.0, published May 5, 2026, added secure .env loading and workspace trust behavior in headless mode, shell command validation and core tool allowlisting, Gemma 4 experimental support, and boot-performance work.

The nearby preview and nightly releases added safeguards around automatic updates and release channels, NODE_OPTIONS propagation during relaunch, workspace trust documentation, ACP modularization, MCP client lifecycle fixes, default timeout/retry changes, and an Auto Memory inbox flow with a canonical-patch contract.

Operator Consequence

Gemini is making workspace trust, local environment handling, tool allowlists, and memory changes explicit. Those are exactly the kinds of hidden assumptions that can make agent work dangerous or non-reproducible if they are not recorded.

Release-channel behavior also matters. Stable, preview, and nightly Gemini surfaces may differ enough that a Bitter run receipt should not simply say "Gemini CLI"; it should record version, channel, trust state, env policy, and memory behavior.

Bitter Implication

Bitter should probe and record:

• workspace trust state
• whether local .env values were loaded or ignored
• shell/tool allowlist configuration
• release channel and exact CLI version
• MCP/extension client lifecycle behavior
• whether memory changes were proposed as reviewable patches

Gemini's Auto Memory canonical-patch direction is especially relevant to BitterLearn: memory that changes future work should be reviewable, diffable, and settleable.

Signal

Authority and memory are becoming explicit in worker CLIs, but the semantics are fragmented. Bitter should normalize the receipts, not flatten the differences.