ACP: session file written with agent-generated sessionId instead of the client-established one — session/load fails with "Invalid session identifier" (Zed as ACP client) #29288

What happened?

Gemini CLI 0.59.0 as ACP agent (--experimental-acp) under Zed 1.19.2+stable, Windows. Sessions never resume: session/load fails "Invalid session identifier". Cause: client and agent generate different sessionIds for the same conversation.

• Zed starts new chat. Session file written with agent's own ID: 5efa4992-15fe-4a64-97bb-382c6f09bfe0 (projectHash 375e9d..., startTime 2026-09-10T23:00:32.975Z). Conversation content intact in file.

• Zed later calls session/load with a different ID: 11977fe0-a2de-45d5-aa55-ab3ccc02e3a5. Response:

  {"code":-32603,"message":"Internal error","data":{"details":"Invalid session identifier "11977fe0-a2de-45d5-aa55-ab3ccc02e3a5".\n Searched for sessions in C:\Users<username>.gemini\tmp<project>\chats.\n Use --list-sessions..."}}

• Grepped session file for requested ID (11977fe0...): no match anywhere. File only ever had the agent's own ID.

• gemini --list-sessions (same project dir) does not list this session, despite the file existing and parsing. Only shows an older session which was done in a terminal.

• Tested on both Zed's managed ACP-registry install and a separate bun-installed gemini-cli 0.59.0. Same result. Same store: C:\Users<username>.gemini, GEMINI_CLI_HOME unset.

• Reproduces consistently, every Zed agent-panel chat with gemini-cli fails to resume after the thread closes.

What did you expect to happen?

Both sides to agree on the same ID

Session file on disk to contain the same ID passed to session/load.

session/load with that ID to restore the conversation.

Client information

Platform: Windows 10.0.26200 Build 26200
ACP client: Zed 1.19.2+stable (agent panel, external agent via gemini.exe --experimental-acp)

Login information

Logged in with Vertex AI. GOOGLE_GENAI_USE_VERTEXAI

Anything else we need to know?

• Possibly related, same underlying bug class (session ID tracked independently in two places and diverging), different code path: Inconsistent session ID in logs.json when resuming a session #22604 , CLI's logger uses a process-generated session ID instead of the one being resumed, causing the same "ID that was never written to the store" failure. That's plain CLI resume; this report is the ACP/Zed equivalent of the same problem.
• Steps/IDs in Field 2 sufficient to reproduce.