gemini-cli resume: session/load succeeds but context is not restored

[omridevk]

Summary

geminiCli declares capabilities.resume: true, so on resume conciv sends only the latest user message — correct behaviour, since the harness is meant to hold the conversation. gemini-cli accepts the session load and keeps the same session ID, but never feeds the prior turns to the model.

Net effect: every gemini turn after the first loses all context in real conciv usage. packages/core/test/gemini-tanstack.it.test.ts has been catching this; it is skipped in CI (!process.env.CI) so it only shows up locally with the real CLI installed.

Evidence

Check	Result
gemini initialize → agentCapabilities	{"loadSession":true, ...} — so session/load is attempted, not skipped
Session ID across both turns	identical (c2510aba-…) — the load succeeded, no silent fallback to newSession
gemini's own session file on disk	contains PLUM42 — gemini did persist the history
Model reply on turn 2	"I do not have a token in my current context. This is the first message in our conversation."
Same helper, claude harness (claude-tanstack.it.test.ts)	passes in 9.8s

So the conciv side is behaving correctly end to end:

1. acpChatConfig passes modelOptions: {sessionId} (packages/harness/src/_shared/acp.ts)
2. @tanstack/ai-acp calls connection.loadSession({sessionId, cwd, mcpServers}) when the agent advertises loadSession: true (src/session/acp-client.ts)
3. gemini returns success and the ID is reused
4. gemini does not restore the transcript into model context

Note that acp-client.ts swallows a failed load with a bare catch {} and falls back to a fresh session — but that is not what happens here; the matching session IDs prove the load succeeded.

Also worth noting: conciv spawns a new gemini --acp process per turn, so session/load must rehydrate from disk. The history is on disk, and turn two still started a new chat file.

Reproduce

Requires the real gemini CLI installed and authenticated:

cd packages/core && npx vitest run test/gemini-tanstack.it.test.ts

AssertionError: expected 'I do not have a record of a token in …' to contain 'PLUM42'

Unrelated gotcha found while diagnosing

If ~/.gemini/settings.json has security.auth.selectedType: "oauth-personal", every call fails with "This client is no longer supported for Gemini Code Assist for individuals" — Google discontinued that tier. Switching to "gemini-api-key" (with GEMINI_API_KEY set) gets past auth. This is separate from the resume bug above.

Options

1. Set resume: false for gemini so conciv replays the transcript preamble each turn. Fixes user-facing context loss; costs tokens per turn, and assertTurnAndResume would need a transcript-based variant for this harness.
2. File upstream with gemini-cli and wait.
3. Investigate whether session/load needs additional params, or whether restoration works under a different auth mode or CLI flag.

Test is marked it.todo until this is resolved.

[omridevk]

This appears to have been fixed upstream and released.

google-gemini/gemini-cli#27913 reproduces the same ACP restart → session/load → lost-context symptom on v0.46.0. PR #27770, merge commit 3a13b8eeb65dc9177c07af814aa7411744ab0b1b, changed session discovery to reject internal-context-only recordings by checking hasResumableContent, preventing an empty newer recording from shadowing the real transcript. An upstream reporter verified the full prompt → SIGKILL → load → recall flow on the fixed code, then reproduced the failure by reverting only #27770.

The fix first shipped in stable v0.47.0. The current stable v0.51.0 tag also contains that commit (behind_by: 0 in GitHub's compare API), its source contains the hasResumableContent guard, and @google/gemini-cli@0.51.0 is currently npm latest.

Conciv still declares resume: true in packages/harness/src/gemini-cli/index.ts, while packages/core/test/gemini-tanstack.it.test.ts remains it.todo for this issue. I could not run the fixed-version live test because no Gemini CLI containing the fix resolved on the active PATH. The remaining confirmation is to install Gemini CLI v0.47.0 or newer, confirm gemini --version in the same shell that will run the test, convert that it.todo to the repository's normal live-test gating, and then run the test. A todo or skipped result is not confirmation because it does not execute the prompt/resume assertion.

Upstream issue #27913 remains open, so the local live assertion—not upstream issue status—should be the closure evidence. If that assertion passes, no conciv-side resume workaround is needed and I recommend closing this issue as fixed upstream.

[omridevk]

Closing: fixed upstream in gemini-cli (google-gemini/gemini-cli#27913 → PR #27770, merged 3a13b8ee) and released; our side needed no change. Triage label agent:already-resolved concurs.