Add /rename slash command

[bl-ue]

Summary

Adds a /rename slash command to rename the current session.

Details

Only works in interactive sessions with at least one user message sent.

Related Issues

How to Validate

Pre-Merge Checklist

• Updated relevant documentation and README (if needed)
• Added/updated tests (if needed)
• Noted breaking changes (if any)
• Validated on required platforms/methods:
  • MacOS
    • npm run
    • npx
    • Docker
    • Podman
    • Seatbelt
  • Windows
    • npm run
    • npx
    • Docker
  • Linux
    • npm run
    • npx
    • Docker

[gemini-code-assist]

Summary of Changes

Hello @bl-ue, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a new /rename slash command, empowering users to easily customize the display names of their interactive sessions. This enhancement improves session organization and clarity by allowing more descriptive titles than just the initial message. The change is supported by a significant refactoring of the underlying session data model, moving away from firstUserMessage to a more flexible displayName field, and updating all relevant components to reflect this new naming convention.

Highlights

• New Slash Command: /rename: Introduced a new /rename slash command that allows users to set a custom display name for their current interactive session. This command requires a name argument and will update the session's metadata.
• Session Naming Refactor: The internal session naming logic has been refactored. The firstUserMessage field has been deprecated and removed from SessionInfo and related utilities. Session display names now primarily rely on a new displayName field, with fallbacks to the session summary or the first user message if a custom displayName is not set.
• Chat Recording Service Enhancements: The ChatRecordingService now includes a setDisplayName method to persist custom session names. Its initialize method has also been updated to accept simplified parameters for resuming existing sessions.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces a new /rename slash command to rename the current session. The implementation is mostly correct and includes appropriate tests and refactoring. However, I've found a critical race condition in the renameCommand implementation. Instantiating a new ChatRecordingService can lead to data loss if the command is executed while a model response is being streamed and recorded. My review comment details this issue and suggests an architectural change to resolve it by using a single shared service instance.

[bl-ue]

/gemini review

[gemini-code-assist]

Code Review

This pull request adds a /rename command to allow users to rename the current session. The implementation looks good, introducing a new displayName field in the session record and updating various parts of the CLI to use it. I've found one issue where the new command fails silently if the chatRecordingService is not available, which I've commented on with a suggestion for a fix.

[jackwotherspoon]

@bl-ue looks like some merge conflicts due to my optimizations to session summary.

mind resolving them? 😄

[jackwotherspoon]

Can sessions be resumed via display name?

Would it make sense to also allow resuming via name if the user has explicitly renamed it?

[bl-ue]

Currently no, sessions can only be resumed by ID or index via --resume, but resuming by name is an interesting idea. However, I didn't implement any validation to prevent a user from assigning the same name to two different sessions, so in that scenario identifying the session to resume would be ambiguous.

[linegel]

@bl-ue its possible to show them as

some-name-set-by-user (id: actual-id)

[bl-ue]

Hi @linegel, I'm not sure what you're asking—will you please clarify?

@jackwotherspoon Conflicts resolved.

[linegel]

Hi @linegel, I'm not sure what you're asking—will you please clarify?

@jackwotherspoon Conflicts resolved.

It was suggestion following resuming by name discussion, so that if name is shared by more than one session, the choice can be made based on id/time of last interaction

[bl-ue]

@linegel Okay, I see what you mean. When you run gemini --list-sessions, it already shows both display name (which, after this PR is merged, will be the manual name, for sessions that are manually named) and the session UUID, e.g.

$ gemini --list-sessions

Available sessions for this project (1):

  1. custom-title (Just now) [332afe8c-84a3-489e-a057-509b9088f07c]

So if I'm understanding you correctly, it already works like you're suggesting.

I guess we can make it possible to resume a session by its manually-set title, and if there happens to be multiple sessions with the specified title, we'll just resume the most recent one. Now that I think about it, if session names are short slugs like auth or bug-fix, it would definitely make sense to be able to resume them by name.

[jackwotherspoon]

Now that I think about it, if session names are short slugs like auth or bug-fix, it would definitely make sense to be able to resume them by name.

@bl-ue this is the exact scenario i was invisioning 😄

I often bounce between multiple features/branchess for Gemini CLI at once. I would love to name my sessions the same thing as my branches. That way whatever branch i am on i can just gemini --resume my-branch and pick up my session where i left off without even having to think 😆

[bl-ue]

@jackwotherspoon @linegel Implement and ready for review. It's now possible to resume a session by index, ID, and manually-assigned name. If there are multiple sessions with the same manual ID, the most recent one is selected.

[bdmorgan]

Hi @bl-ue, thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this.

We're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: Improving Our Contribution Process & Introducing New Guidelines.

Key Update: Starting January 26, 2026, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed.

Thank you for your understanding and for being a part of our community!

[gemini-cli]

Hi there! Thank you for your contribution to Gemini CLI.

To improve our contribution process and better track changes, we now require all pull requests to be associated with an existing issue, as announced in our recent discussion and as detailed in our CONTRIBUTING.md.

This pull request is being closed because it is not currently linked to an issue. You can easily reopen this PR once you have linked it to an issue.

How to link an issue:
Add a keyword followed by the issue number (e.g., Fixes #123) in the description of your pull request. For more details, see the GitHub Documentation.

Thank you for your understanding and for being a part of our community!

[gemini-cli]

Hi there! Thank you for your contribution to Gemini CLI. We really appreciate the time and effort you've put into this pull request.

To keep our backlog manageable and ensure we're focusing on current priorities, we are closing pull requests that haven't seen maintainer activity for 30 days. Currently, the team is prioritizing work associated with 🔒 maintainer only or help wanted issues.

If you believe this change is still critical, please feel free to comment with updated details. Otherwise, we encourage contributors to focus on open issues labeled as help wanted. Thank you for your understanding!