Gemini CLI session lost or cannot resume?
If a Gemini CLI session disappears or cannot resume, do not start from memory. Rebuild the next task from the repository, shell evidence, and verified handoff state.
A saved checkpoint exists, but resume throws a TypeError.
Source checked 13 September 2026. Issue #29194, opened 3 September, reports a checkpoint whose JSON parses but whose history has an unexpected type. The linked proposed fix #29195 was still open when checked. We have not established a released fix, affected release range or independent reproduction.
- Record the full error and installed version. A malformed checkpoint is different from a missing session or a provider quota error.
- After stopping the session, preserve a copy of the checkpoint and relevant logs. Do not replace
historywith an empty array or delete the original to make the error disappear. - Inspect only the copy if you can validate its structure. Valid JSON alone does not establish that the session data is usable; unexpected fields need version-specific interpretation.
- If resume remains unavailable, continue from verified repository changes and available notes. Preserve unknowns instead of inventing missing conversation history.
The proposed guard handles invalid data; it is not a reconstruction of lost messages. Redact private data before reporting the problem upstream.
What usually survives.
The repository
Changed files, untracked files, test output, and recent commits are the strongest recovery source.
Shell history
Recent commands can reconstruct what Gemini CLI attempted, even if the chat session is missing.
Local notes
Handoff files, TODOs, logs, and generated artifacts can rebuild intent.
The old session
Use it if it loads, but do not depend on it as the only copy of task state.
Safe recovery path.
What ShardStitch adds.
ShardStitch makes the lost session less dangerous by rebuilding the continuation from local project evidence. It can hand the packet back to Gemini CLI or move it to another supported coding tool.