Wrong session id shown after resuming a session

[seekskyworld]

What happened?

Description:
When using gemini --resume to resume a specific session, the session appears to resume correctly. However, executing /stats session afterwards shows a different Session ID, generated at startup, rather than the resumed session's ID.
Steps to Reproduce:
Start Gemini CLI with a resumed session:
gemini --resume 3faa310e-642a-4861-8115-942be8c6c9a0
Run the command:
/stats session
Observe that the displayed Session ID is different, e.g.:
Session ID: 93edc14b-cbef-4e90-b671-b9e7a4d2a5bb
Expected Behavior:
The /stats session command should display the Session ID of the resumed session (3faa310e-642a-4861-8115-942be8c6c9a0), not a newly generated ID.
Actual Behavior:
The displayed Session ID is generated at program startup and does not reflect the resumed session.
Technical Details:
The root cause is that SessionStatsProvider uses a module-level global sessionId from @google/gemini-cli-core, which is generated via randomUUID() at module load time.
Even after resuming a session, this global sessionId never updates.
Config object correctly stores the resumed session ID, but SessionStatsProvider does not reference it.
/stats session ultimately reads from SessionStatsProvider state, causing the mismatch.

What did you expect to happen?

Proposed Solution:
SessionStatsProvider should retrieve the session ID from the Config object, ensuring that the correct session ID is displayed when resuming a session.

Notes:
This seems to be a design flaw rather than a runtime error, but it causes confusion when trying to track session stats across resumed sessions.

Client information

Client Information

Run gemini to enter the interactive CLI, then run the /about command.

> /about
# paste output here

Login information

No response

Anything else we need to know?

No response

[siddanth-6365]

Hi, I'd like to work on this issue.

[bluelight773]

I've sometimes encountered the issue where both the session ID shown in the footer, and the session ID shown when exiting gemini appear to be wrong as well as multiple sessions getting assigned the same session ID.

I think this occurred when I used /clear to start a new session.

To reliably determine the correct session ID and to be able to resume the desired session, I had to search for the summary name or a unique string from the session in ~/.gemini/tmp/*/chats/*.json. The matching file will have the correct session ID. However, if there are other files that use the same session ID, then one has to rename those files (e.g., add .bak) so that they don't conflict with the file of interest.