What happened?

Summary

When using gemini-cli, the /chat save command saves conversation checkpoints even when there are no actual user messages, only the initial system context messages. This creates empty or meaningless saved conversations that waste storage and clutter the checkpoint list.

Steps to Reproduce

1. Open gemini-cli in any terminal
2. Start a new chat session (this automatically adds initial system context)
3. Run the save command without any user interaction:
   ╭────────────────────────╮
   │ > /chat save default
   ╰────────────────────────╯

Observed: The command successfully saves a "conversation" with tag "default" even though no actual user conversation exists.

4. List saved conversations:
   ╭────────────────────────╮
   │ > /chat list
   ╰────────────────────────╯

Observed: The "default" checkpoint appears in the list, but when loaded, it contains only system context messages (environment info, directory structure, etc.) and no actual user conversation.

Impact

• Users can accidentally save empty conversations that serve no purpose
• Storage is wasted on meaningless checkpoints
• The checkpoint list becomes cluttered with non-functional saves
• When users try to resume these "conversations," they find no actual content to work with
• This creates confusion about what constitutes a valid conversation to save

What did you expect to happen?

The /chat save command should only save conversations that contain actual user messages beyond the initial system context. If only system context messages exist, the command should return "No conversation found to save" instead of creating an empty checkpoint.

Client information

CLI Version: 0.1.20
Git Commit: 214800cf
Operating System: win32
Sandbox: no sandbox
Model Version: gemini-2.5-pro
Terminals: Any terminal
Auth Method: OAuth

Login information

OAuth (but I think it affects all authentication methods)

Anything else we need to know?

The issue occurs because the save logic checks history.length > 0 instead of checking for actual user content. The initial system context always consists of exactly 2 messages (user context + model acknowledgment), so checking history.length > 2 would ensure only conversations with real user interaction are saved.

The resume command already has logic to filter out these system messages for display, but the save command doesn't apply similar filtering before saving.