ACP: session/load in the same UTC minute as session/new fails with "No previous sessions found" — and durably destroys the session's resumability

[realtonyyoung]

Note

Updated 2026-08-09 — root cause identified; original framing corrected. The original report claimed a crashed session is "never persisted". That's wrong: persistence is fine (every record is written synchronously, and the conversation file survives any kill). The real defect is in the load path: session/load eagerly re-initializes chat recording for the requested session id before resolving it, appending a fresh metadata header + $set {messages: [<session_context>]} checkpoint to session-<UTC-minute>-<id[0:8]>.jsonl. When the load runs in the same UTC minute the session was created, that append lands in the session's own conversation file; the checkpoint buries the conversation in the fold, hasResumableContent flips false, the session is filtered from the listing, and the load fails with No previous sessions found for this project — after durably destroying the session's resumability. No crash is required (it reproduces after a clean exit). Full mechanism with source refs at cf22ac7, a three-variant repro on 0.54.0, and the likely unification with #27913: see this comment.

What happened

When gemini runs as an ACP agent, initialize advertises agentCapabilities.loadSession: true — but a session/load issued in the same UTC minute as the session's session/new fails with:

No previous sessions found for this project

and durably poisons the session file, so every later session/load for that id fails too. Automated ACP clients (an editor reconnecting right after a crash, scripted harnesses) land in this window routinely; a human retrying minutes later lands in a different minute and sees loads succeed, which makes the failure look intermittent or environment-dependent.

Version

• Originally observed on gemini 0.53.0; root-caused and reproduced on 0.54.0, macOS/arm64, driven over stdio by a minimal ACP client. Mechanism present in source at cf22ac7.

Steps to reproduce (no crash or kill required)

1. Start gemini in ACP mode; initialize → loadSession: true.
2. session/new ({ cwd, mcpServers: [] }) → sessionId.
3. Run one or more session/prompt turns to completion.
4. End the process — cleanly (close stdin, exit 0) or by SIGKILL of the process tree; both reproduce.
5. Spawn a fresh gemini ACP process; initialize; session/load ({ sessionId, cwd, mcpServers: [] }) — within the same UTC minute as step 2.

Expected

session/load finds the session (its file is on disk with all turns) and replays the conversation per the ACP spec — and, being a read operation, does not modify the session it is resolving.

Actual

Step 5 fails with No previous sessions found for this project, and the session's session-<minute>-<id8>.jsonl gains a trailing metadata header + $set {messages: [<session_context>]} checkpoint written by the load call itself, permanently burying the conversation in the fold (the turn records remain physically present in the file, before the poison pair). Later session/load calls — in any minute — keep failing, each leaving an additional context-only junk file.

Historical note on the original report

The original report reproduced this via SIGKILL of the whole process tree mid-turn and framed it as missing crash persistence. The tree-kill observation itself stands — each launch self-re-execs a sandbox wrapper, so killing only the spawned pid orphans the real agent, and probes must kill the tree — but neither the kill nor its timing is load-bearing for this bug: the probe's new → turns → kill → load sequence simply always landed inside one minute.

Related

#27913 is very likely the same root cause observed one release earlier: it was filed against 0.46.0, before 3a13b8eeb (#27770, first shipped in v0.47.0) added the hasResumableContent filter. Pre-filter, the poisoned fold still lists, so session/load "succeeds" — replaying exactly one user_message_chunk (the <session_context>, which streamHistory doesn't filter) while the model's restored history is empty (convertSessionToClientHistory filters it out). Post-filter, the identical on-disk state reports No previous sessions found instead.

[gemini-cli]

Effort Analysis:
The architectural failure involves the interaction between packages/cli/src/acp/acpSession.ts and packages/core/src/core/geminiChat.ts. Specifically, GeminiChat.sendMessageStream (lines 435–450) skips recording user messages when isContextManagementEnabled is true, assuming the caller has already added them to history. In ACP mode, AcpSession.prompt initiates the model turn without first ensuring the user prompt is durably recorded in the session's agentHistory via setHistory. If the process tree is killed mid-turn (as described in the repro), the session file on disk contains only initial metadata but no 'resumable' messages. Consequently, SessionSelector.resolveSession (via getSessionFiles and getAllSessionFiles in packages/cli/src/utils/sessionUtils.ts) filters out the session because hasResumableContent (calculated in packages/core/src/services/chatRecordingService.ts) returns false. Fixing this requires ensuring atomic persistence of the user message at the start of the turn in the ACP RPC handler. The estimation is 'medium' due to the cross-package state synchronization requirements and the complexity of reproducing signal-based process termination in an ACP-integrated environment.

[PranavMishra28]

spent a while trying to find the mechanism in source and could not substantiate the "never persisted" framing. posting the eliminations rather than a fix, since each one is checkable and they narrow it — all against main at cf22ac7.

writes are synchronous and per-message, not buffered until exit. ChatRecordingService.appendRecord does fs.appendFileSync (chatRecordingService.ts:564). there's no flush-on-shutdown to miss.

the ACP new-session path does initialize recording. newSession calls geminiClient.startChat() (acpSessionManager.ts), and Client.startChat calls chat.initialize(resumedSessionData, 'main'). with resumedSessionData undefined it takes the fresh branch and names the file from the session id, so a new ACP session gets a conversation file before the first turn.

a truncated trailing line does not poison the file. i expected a SIGKILL mid-appendFileSync to leave a partial JSON line and take the whole session down through the catch { sessionInfo: null } in getAllSessionFiles. it doesn't — the reader catches per line: } catch { // ignore parse errors on individual lines } in loadConversationRecord. so a half-written last record costs you that record, not the session.

a user-only turn is still resumable. the other candidate was hasResumableContent filtering out a session whose last turn has a user message but no assistant reply, since the kill happens mid-stream. isResumableMessageRecord returns true for type === 'user' on any non-ignored content (chatRecordingService.ts:107-124), and your repro runs several turns to completion first, so the file has resumable content regardless.

so the four mechanisms i'd have bet on are all ruled out, which makes me think this is environmental rather than a missing checkpoint — the lookup directory, not the write.

session/load resolves through SessionSelector(config.storage), and listSessions reads path.join(storage.getProjectTempDir(), 'chats'). getProjectTempDir is path.join(Storage.getGlobalTempDir(), this.getProjectIdentifier()) (storage.ts:181-185), derived from the target dir. both newSession and loadSession build that from the cwd in the client request, so they agree only if the second process sends a cwd that normalizes identically.

that would fit everything you observed, including why #27913 sees session/load resolve — different client, possibly a different cwd string.

worth checking, and it's cheap: after the tree-kill, look for the file directly.

ls -la ~/.gemini/tmp/*/chats/ | tail

if the session-*.jsonl for that id is there with your turns in it, the write side is fine and this is a resolution bug, which is a much smaller fix than durable checkpointing. if it is genuinely absent, one of my four eliminations is wrong and i'd want to know which.

happy to write the fix once it's clear which half is broken — i didn't want to send a patch for a mechanism i couldn't reproduce.

[realtonyyoung]

@PranavMishra28 I ran your ls check — all four of your eliminations hold, and it is a resolution bug, but of an unexpected kind. Answering your question directly first:

after the tree-kill, look for the file directly. if the session-*.jsonl for that id is there with your turns in it, the write side is fine

It is there, with every turn intact. And it stays findable — until session/load runs. The load path itself appends records to the very file it is about to search for, and that write is what makes the reader blind. The kill turns out to be entirely incidental: I can now reproduce the exact reported error with a cleanly exited session (details below). The load-bearing condition is embarrassingly small: session/load in the same UTC minute as session/new.

Mechanism (refs at cf22ac7, identical on v0.53.0)

1. AcpSessionManager.loadSession builds the session config before resolving: initializeSessionConfig(sessionId, cwd, …) (packages/cli/src/acp/acpSessionManager.ts:168), whose step 4 is await config.initialize() (:279).
2. Config._initialize() eagerly initializes the client: await this._geminiClient.initialize() (packages/core/src/config/config.ts:1560) → this.chat = await this.startChat() (packages/core/src/core/client.ts:263) → chat.initialize(undefined, 'main') (client.ts:411).
3. GeminiChat.initialize (packages/core/src/core/geminiChat.ts:350–360) runs ChatRecordingService.initialize with no resumedSessionData — the fresh-create branch — which appends an initialMetadata header to session-<UTC-timestamp-to-the-minute>-<sessionId[0:8]>.jsonl (chatRecordingService.ts:514,539), then updateMessagesFromHistory writes a $set {messages: […]} checkpoint whose only entry is the bootstrap <session_context> user message. Note the session id used here is the requested one.
4. Only then does sessionSelector.resolveSession(sessionId) list the chats dir (acpSessionManager.ts:178).

The filename is stamped to the minute, so when steps 3 and the original session/new fall in the same UTC minute, the "fresh create" appends to the existing conversation file. loadConversationRecord folds a $set{messages} checkpoint as clear-and-rebuild (messagesMap.clear(), chatRecordingService.ts:255), so the fold now ends at "one <session_context> message" — which isIgnoredUserContent ignores (packages/core/src/utils/sessionUtils.ts:102) → hasResumableContent is false → getAllSessionFiles nulls the entry (packages/cli/src/utils/sessionUtils.ts:284) → the valid list is empty → findSession throws at :462: "No previous sessions found for this project."

Your cwd hypothesis was reasonable but is ruled out here: my client passes the byte-identical cwd string to both processes (and spawns both with that working directory), and the failing loader demonstrably writes into the same chats dir it then reports empty.

Reproduced today on 0.54.0 — three variants

Variant	Kill?	Load timing	Result
A	SIGKILL whole tree after a completed turn	same minute	No previous sessions found for this project. — and the file gains a header + context-only checkpoint stamped at the load call's own timestamp
A2	— (re-load of A's session)	next minute	still fails, permanently; each attempt drops another context-only session-<minute>-<id8>.jsonl junk file
B (control)	SIGKILL whole tree after a completed turn	next minute	load succeeds and replays — proving the writes were durable all along
C	none — clean exit, rc=0	same minute	same failure, same poisoning

The decisive artifact, variant A (session 6609361f…, created 14:08:07, loaded 14:08:21). Before the load, 8 records; after the failed load, 10:

line 4: MSG      type=user   'Reply with exactly: alpha'
line 6: MSG      type=gemini 'alpha'
line 7: CHECKPT  $set [lastUpdated]  14:08:16.423Z   ← last write before the kill
line 8: HEADER   startTime=14:08:21.643Z             ← appended BY the session/load call
line 9: CHECKPT  $set messages[1] = [<session_context>]  ← buries lines 0–7 in the fold

Two side observations from the dumps:

• Every session file starts with two header+checkpoint pairs a few ms apart — newSession initializes a chat twice (config.initialize()'s eager GeminiClient.initialize(), then the explicit geminiClient.startChat()). Harmless there, but it's the same eagerness that fires on the load path.
• The user's turns are still physically present in a poisoned file (everything before the trailing checkpoint), so a heal/migration that strips trailing context-only header+checkpoint pairs could recover affected sessions.

Why nobody could find it, and the #27913 connection

A human retrying a resume lands in a later minute and sees it work; an automated ACP client (an editor reconnecting after a crash, a scripted repro, our probe harness) does new→turns→load inside one minute and hits it every time. Worse than the failed load: the poisoning is durable, so the one client that most needs crash recovery destroys the session by asking for it.

I believe this is also #27913's mechanism, seen from the other side of one commit. That report is against 0.46.0; 3a13b8eeb ("Avoid persisting empty resume sessions", #27770) shipped the hasResumableContent filter in v0.47.0. Before the filter, the poisoned fold still lists, so session/load "succeeds" — and replays exactly one user_message_chunk, because Session.streamHistory doesn't filter <session_context> while convertSessionToClientHistory (which seeds the model) does, leaving the model with empty history. That is verbatim what #27913 reports: load resolves, { "user_message_chunk": 1 }, model remembers nothing. Same root cause; the filter just flipped the symptom from "loads but restores nothing" to "no sessions found".

Fix shape

Two independent layers, either of which kills the failure mode; both seem worth having:

1. Order: in loadSession, resolve the session before any code path initializes a fresh chat/recording for the requested id — i.e. don't let config.initialize()'s eager GeminiClient.initialize() run ahead of resolveSession; the subsequent resumeChat(...) already re-initializes recording correctly against the resolved file.
2. Invariant: ChatRecordingService.initialize's fresh-create branch should never append a header+checkpoint onto an existing file (uniquify the name or refuse) — that protects every current and future caller from the same collision.

Happy to re-run the harness against a fix branch. I'll also amend this issue's title/body: "never persisted" was wrong — persistence is fine; the advertised loadSession capability is broken by the load path itself, plus destructive.

Repro script (python, stdlib only; phases A/A2/B — for C, close stdin instead of killpg)

#!/usr/bin/env python3
# usage: python3 g28693_repro.py /tmp/g28693-work
import asyncio, json, os, signal, sys, glob, datetime, random, string

ARGV = ["gemini", "--experimental-acp", "--skip-trust",
        "--allowed-mcp-server-names", "__unmatchable__"]
CHATS_GLOB = os.path.expanduser("~/.gemini/tmp/*/chats/*.jsonl")

def log(m): print(f"[{datetime.datetime.now(datetime.timezone.utc).strftime('%H:%M:%S.%f')[:-3]}] {m}", flush=True)
def files_for(sid): return sorted(p for p in glob.glob(CHATS_GLOB) if sid[:8] in os.path.basename(p))

def dump_file(path, label):
    lines = [l for l in open(path, errors="replace").read().splitlines() if l.strip()]
    log(f"  {label}: {os.path.basename(path)} — {len(lines)} records")
    for i, ln in enumerate(lines):
        try: r = json.loads(ln)
        except Exception: continue
        if "sessionId" in r and "projectHash" in r: log(f"    line {i}: HEADER   startTime={r.get('startTime')}")
        elif "$set" in r:
            m = r["$set"].get("messages")
            log(f"    line {i}: CHECKPT  " + (f"$set messages[{len(m)}]" if isinstance(m, list) else f"$set {list(r['$set'])}"))
        elif "id" in r:
            c = r.get("content"); t = c if isinstance(c, str) else (c[0].get("text", "") if isinstance(c, list) and c else "")
            log(f"    line {i}: MSG      type={r.get('type')} {str(t)[:50]!r}")

class Client:
    def __init__(self, label, cwd):
        self.label, self.cwd, self.pending, self.next_id, self.updates = label, cwd, {}, 0, {}
        self.lock = asyncio.Lock()
    async def start(self):
        self.proc = await asyncio.create_subprocess_exec(*ARGV, cwd=self.cwd, env=dict(os.environ),
            start_new_session=True, stdin=asyncio.subprocess.PIPE, stdout=asyncio.subprocess.PIPE,
            stderr=asyncio.subprocess.DEVNULL)
        asyncio.create_task(self._read())
    async def _read(self):
        while True:
            line = await self.proc.stdout.readline()
            if not line: break
            try: obj = json.loads(line)
            except Exception: continue
            if "id" in obj and ("result" in obj or "error" in obj) and "method" not in obj:
                f = self.pending.pop(obj["id"], None)
                if f and not f.done(): f.set_result(obj)
            elif obj.get("method") == "session/update":
                k = (obj.get("params", {}).get("update") or {}).get("sessionUpdate", "?")
                self.updates[k] = self.updates.get(k, 0) + 1
            elif "method" in obj and "id" in obj:
                opts = obj.get("params", {}).get("options", []) or []
                allow = next((o for o in opts if o.get("kind", "").startswith("allow")), None)
                await self._write({"jsonrpc": "2.0", "id": obj["id"],
                    "result": {"outcome": {"outcome": "selected", "optionId": allow["optionId"]}} if allow else {}})
        for f in self.pending.values():
            if not f.done(): f.set_exception(ConnectionError("EOF"))
    async def _write(self, frame):
        async with self.lock:
            self.proc.stdin.write((json.dumps(frame) + "\n").encode()); await self.proc.stdin.drain()
    async def request(self, method, params, timeout=120):
        self.next_id += 1; rid = self.next_id
        fut = asyncio.get_event_loop().create_future(); self.pending[rid] = fut
        await self._write({"jsonrpc": "2.0", "id": rid, "method": method, "params": params})
        return await asyncio.wait_for(fut, timeout)
    def tree_kill(self):
        try: os.killpg(os.getpgid(self.proc.pid), signal.SIGKILL)
        except ProcessLookupError: pass

async def init(c):
    r = await c.request("initialize", {"protocolVersion": 1,
        "clientCapabilities": {"fs": {"readTextFile": False, "writeTextFile": False}, "terminal": False}}, 60)
    log(f"{c.label}: initialize ok; loadSession={(r.get('result') or {}).get('agentCapabilities', {}).get('loadSession')}")

def minute(): return datetime.datetime.now(datetime.timezone.utc).strftime("%Y-%m-%dT%H-%M")
async def wait_past(m):
    while minute() <= m: await asyncio.sleep(2)

async def phase(name, workdir, wait_next, recheck=False):
    os.makedirs(workdir, exist_ok=True)
    log(f"===== {name} =====")
    if not wait_next:
        while datetime.datetime.now(datetime.timezone.utc).second > 20: await asyncio.sleep(1)
    c1 = Client(f"{name}-c1", workdir); await c1.start(); await init(c1)
    sid = (await c1.request("session/new", {"cwd": workdir, "mcpServers": []}, 90))["result"]["sessionId"]
    m0 = minute(); log(f"{name}: session/new sid={sid} minute={m0}")
    tr = await c1.request("session/prompt", {"sessionId": sid, "prompt": [{"type": "text", "text": "Reply with exactly: alpha"}]}, 120)
    log(f"{name}: turn stopReason={(tr.get('result') or {}).get('stopReason')}")
    c1.tree_kill(); await asyncio.sleep(1)
    for p in files_for(sid): dump_file(p, "after kill")
    if wait_next: await wait_past(m0)
    c2 = Client(f"{name}-c2", workdir); await c2.start(); await init(c2)
    lr = await c2.request("session/load", {"sessionId": sid, "cwd": workdir, "mcpServers": []}, 180)
    tag = "SAME" if minute() == m0 else "DIFFERENT"
    log(f"{name}: session/load ({tag} minute) → " + (f"FAILED {json.dumps(lr['error'])[:200]}" if "error" in lr else f"OK replayed={c2.updates}"))
    await asyncio.sleep(1.5); c2.tree_kill(); await asyncio.sleep(0.5)
    for p in files_for(sid): dump_file(p, "after load")
    if recheck:
        await wait_past(minute())
        c3 = Client(f"{name}-c3", workdir); await c3.start(); await init(c3)
        lr3 = await c3.request("session/load", {"sessionId": sid, "cwd": workdir, "mcpServers": []}, 180)
        log(f"{name}: next-minute re-load → " + ("FAILED (permanent)" if "error" in lr3 else f"OK {c3.updates}"))
        c3.tree_kill(); await asyncio.sleep(0.5)
        for p in files_for(sid): dump_file(p, "after re-load")

async def main():
    base = sys.argv[1]; tag = "".join(random.choices(string.ascii_lowercase, k=4))
    await phase("A-same-minute", os.path.join(base, f"a{tag}"), wait_next=False, recheck=True)
    await phase("B-next-minute-control", os.path.join(base, f"b{tag}"), wait_next=True)

asyncio.run(main())