Summary
Auto Memory is documented as a Gemini CLI feature that "runs as a background task on session startup", but ACP session startup does not invoke the memory service.
As a result, users can enable experimental.autoMemory = true and use Gemini CLI through ACP/IDE flows, yet never get background extraction because the service is only started from the TUI/AppContainer path.
Repro
- Enable Auto Memory in settings:
{
"experimental": {
"autoMemory": true
}
}
- Start Gemini CLI in ACP mode or via an ACP client / IDE integration.
- Use the tool normally across multiple sessions.
- Wait for the usual idle / eligibility conditions that Auto Memory expects.
Actual
ACP session creation succeeds, but Auto Memory startup is never invoked, so extraction never begins from that surface.
Expected
If experimental.autoMemory = true is supported generally, ACP sessions should also start the memory service on session boot.
If ACP is intentionally unsupported, the docs / settings surface should say so clearly, because the current documentation describes Auto Memory generically as a Gemini CLI session-start feature.
Verified Locally
I reproduced this by exercising GeminiAgent.newSession(...) with:
- a config mock where
isAutoMemoryEnabled() returned true
- a spy on
startMemoryService
The ACP session was created successfully and startMemoryService was never called.
Why This Matters
This surfaces for users who primarily work through IDE / ACP sessions:
- they enable Auto Memory in settings
- they expect background skill extraction to run on session startup
- inbox items never appear because extraction never starts on that client path
From the user perspective, the feature looks nonfunctional or inconsistent across Gemini CLI surfaces.
Relevant Code
- TUI startup path starts Auto Memory:
packages/cli/src/ui/AppContainer.tsx:490
- ACP session startup does not:
packages/cli/src/acp/acpClient.ts:266-356, packages/cli/src/acp/acpClient.ts:368-412
- Auto Memory docs describe generic session-start behavior:
docs/cli/auto-memory.md:61
Summary
Auto Memory is documented as a Gemini CLI feature that "runs as a background task on session startup", but ACP session startup does not invoke the memory service.
As a result, users can enable
experimental.autoMemory = trueand use Gemini CLI through ACP/IDE flows, yet never get background extraction because the service is only started from the TUI/AppContainer path.Repro
{ "experimental": { "autoMemory": true } }Actual
ACP session creation succeeds, but Auto Memory startup is never invoked, so extraction never begins from that surface.
Expected
If
experimental.autoMemory = trueis supported generally, ACP sessions should also start the memory service on session boot.If ACP is intentionally unsupported, the docs / settings surface should say so clearly, because the current documentation describes Auto Memory generically as a Gemini CLI session-start feature.
Verified Locally
I reproduced this by exercising
GeminiAgent.newSession(...)with:isAutoMemoryEnabled()returnedtruestartMemoryServiceThe ACP session was created successfully and
startMemoryServicewas never called.Why This Matters
This surfaces for users who primarily work through IDE / ACP sessions:
From the user perspective, the feature looks nonfunctional or inconsistent across Gemini CLI surfaces.
Relevant Code
packages/cli/src/ui/AppContainer.tsx:490packages/cli/src/acp/acpClient.ts:266-356,packages/cli/src/acp/acpClient.ts:368-412docs/cli/auto-memory.md:61