Gemini CLI v0.37 Lands With Experimental Memory Manager Agent
Gemini CLI v0.37.0-preview.1 brings an experimental memory manager agent, stateless sandbox architecture, and performance improvements — but users reported slow responses days after release.
Google shipped Gemini CLI v0.37.0-preview.1 on April 2, 2026, introducing an experimental memory manager agent that replaces the legacy save_memory tool. The release arrives alongside a broader refactoring of the CLI's core architecture — including a stateless SandboxManager with an explicit Deny interface, parallelized startup cleanup tasks, and hardened AgentSession replay semantics. If you've been running the CLI in automated workflows or CI pipelines, the changelog is worth reading carefully before your next upgrade.
The headline feature is the new memory manager agent, designed to carry context across CLI sessions — a meaningful step toward persistent state in a tool that has historically reset every invocation. The release notes cite multi-turn interactive evals for the memoryManager, which suggests Google is taking the feature seriously rather than shipping it as a proof-of-concept. Also worth noting: agents are now disabled by default, meaning you'll need to explicitly opt-in to use them. This is a sensible security posture for a CLI that executes commands on your machine.
On the performance side, the team merged parallelized startup cleanup tasks and background IDE client initialization — both targeting the cold-start latency that has been a consistent complaint. However, users reported on April 4 that the CLI was "very slow" compared to previous weeks, with responses taking significantly longer than expected. It's unclear whether this is a server-side issue, a regression in the v0.37 preview build, or unrelated infrastructure strain. If you're hitting latency problems, this predates the v0.37 release by at least a day.
For developers integrating the CLI into production workflows, the policy engine changes deserve attention. The refactored SandboxManager introduces an explicit Deny interface, and the policy config now requires toolName to be explicitly specified. These are breaking changes for anyone with custom policy configurations — the migration path is in the changelog, but budget time for testing if you rely on fine-grained tool execution policies.