google-gemini / google-gemini/gemini-cli

[Bug]: Latest chat session permanently lost from /chat list after using gemini --resume

Open
#27,368 9 comments 1 reaction 0 assignees View on GitHub
area/agent kind/bug priority/p1 status/bot-triaged status/possible-duplicate
Dominant language
TypeScript
Stars
107k
Forks
14.6k
Avg merge
2d 3h
Merged PRs (30d)
45

Description

## Description

Using `gemini --resume` causes the most recent chat session to permanently disappear from the `/chat` list on the subsequent normal launch. The data appears to be lost or the session index corrupted by the `--resume` flow.

## Steps to Reproduce

1. Open Gemini normally.
2. Run `/chat` and confirm all existing sessions are visible.
3. Close Gemini.
4. Run `gemini --resume` in the terminal. The CLI auto-loads into the most recent chat session.
5. Run `/chat` inside the resumed session and verify all sessions are still visible at this point.
6. Close Gemini.
7. Open Gemini normally (without any flags).
8. Run `/chat` again.

https://github.com/user-attachments/assets/392257d3-ab7a-45c7-90d4-e7bb8cd4e399

### Actual Behavior

The most recent chat session is permanently gone from the `/chat` list. The session does not reappear on subsequent launches.

### Expected Behavior

All chat sessions should persist regardless of how the CLI was previously closed. Using `gemini --resume` must not affect the integrity of the session list. The most recent chat session should remain visible and accessible in `/chat` after any combination of normal and `--resume` launches.

---

## Client Environment

* **CLI Version:** `0.43.0`
* **Git Commit:** `c0775c38b`
* **Model:** `gemini-3.1-pro-preview`
* **Sandbox:** `no sandbox`
* **OS:** `win32 (Windows)`
* **Tier:** Gemini Code Assist in Google One AI Pro

## Authentication & Login

* **Method:** Signed in with Google Account via standard OAuth flow.

---

## Additional Information

* The bug is consistently reproducible following the exact steps above.
* Sessions created and closed without utilizing the `--resume` flag do not exhibit this behavior.
* The issue appears isolated to the interaction between the `--resume` flag and session index management, specifically affecting the serialization or state persistence of the active session during the `--resume` execution path.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.