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
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
geminito enter the interactive CLI, then run the/aboutcommand.Login information
No response
Anything else we need to know?
No response