Gemini CLI supports several built-in commands to help you manage your session, customize the interface, and control its behavior. These commands are prefixed with a forward slash (/
), an at symbol (@
), or an exclamation mark (!
).
/
)Slash commands provide meta-level control over the CLI itself.
/bug
/bug
will become the headline for the bug being filed. The default /bug
behavior can be modified using the advanced.bugCommand
setting in your .gemini/settings.json
files./chat
save
<tag>
for identifying the conversation state./chat save <tag>
~/.gemini/tmp/<project_hash>/
C:\Users\<YourUsername>\.gemini\tmp\<project_hash>\
/chat list
, the CLI only scans these specific directories to find available checkpoints.resume
/chat resume <tag>
list
delete
/chat delete <tag>
share
/chat share file.md
or /chat share file.json
. If no filename is provided, then the CLI will generate one./clear
/compress
/copy
xclip
or xsel
. You can typically install them using your system’s package manager.pbcopy
, and on Windows, it requires clip
. These tools are typically pre-installed on their respective systems./directory
(or /dir
)
add
:
/directory add <path1>,<path2>
--include-directories
when starting the session instead.show
:
/directory add
and --include-directories
./directory show
/editor
/extensions
/help
(or /?
)
/mcp
desc
or descriptions
:
nodesc
or nodescriptions
:
schema
:
/memory
GEMINI.md
files).add
:
/memory add <text to remember>
show
:
GEMINI.md
files. This lets you inspect the instructional context being provided to the Gemini model.refresh
:
GEMINI.md
files found in the configured locations (global, project/ancestors, and sub-directories). This command updates the model with the latest GEMINI.md
content.GEMINI.md
files contribute to hierarchical memory, see the CLI Configuration documentation./restore
/restore [tool_call_id]
--checkpointing
option or configured via settings. See Checkpointing documentation for more details./settings
.gemini/settings.json
file, but with validation and guidance to prevent errors./settings
and the editor will open. You can then browse or search for specific settings, view their current values, and modify them as desired. Changes to some settings are applied immediately, while others require a restart./stats
/theme
/auth
/about
/tools
/tools [desc]
desc
or descriptions
:
nodesc
or nodescriptions
:
/privacy
/quit
(or /exit
)
/vim
h
, j
, k
, l
; jump by words with w
, b
, e
; go to line start/end with 0
, $
, ^
; go to specific lines with G
(or gg
for first line)x
, change with c
, insert with i
, a
, o
, O
; complex operations like dd
, cc
, dw
, cw
3h
, 5w
, 10G
).
to repeat the last editing operation~/.gemini/settings.json
and restored between sessions[NORMAL]
or [INSERT]
in the footer/init
GEMINI.md
file, this command analyzes the current directory and generates a tailored context file, making it simpler for them to provide project-specific instructions to the Gemini agent.For a quick start, see the example below.
Custom commands allow you to save and reuse your favorite or most frequently used prompts as personal shortcuts within Gemini CLI. You can create commands that are specific to a single project or commands that are available globally across all your projects, streamlining your workflow and ensuring consistency.
Gemini CLI discovers commands from two locations, loaded in a specific order:
~/.gemini/commands/
. These commands are available in any project you are working on.<your-project-root>/.gemini/commands/
. These commands are specific to the current project and can be checked into version control to be shared with your team.If a command in the project directory has the same name as a command in the user directory, the project command will always be used. This allows projects to override global commands with project-specific versions.
The name of a command is determined by its file path relative to its commands
directory. Subdirectories are used to create namespaced commands, with the path separator (/
or \
) being converted to a colon (:
).
~/.gemini/commands/test.toml
becomes the command /test
.<project>/.gemini/commands/git/commit.toml
becomes the namespaced command /git:commit
.Your command definition files must be written in the TOML format and use the .toml
file extension.
prompt
(String): The prompt that will be sent to the Gemini model when the command is executed. This can be a single-line or multi-line string.description
(String): A brief, one-line description of what the command does. This text will be displayed next to your command in the /help
menu. If you omit this field, a generic description will be generated from the filename.Custom commands support two powerful methods for handling arguments. The CLI automatically chooses the correct method based on the content of your command’s prompt
.
If your prompt
contains the special placeholder ``, the CLI will replace that placeholder with the text the user typed after the command name.
The behavior of this injection depends on where it is used:
A. Raw Injection (Outside Shell Commands)
When used in the main body of the prompt, the arguments are injected exactly as the user typed them.
Example (git/fix.toml
):
# Invoked via: /git:fix "Button is misaligned"
description = "Generates a fix for a given issue."
prompt = "Please provide a code fix for the issue described here: ."
The model receives: Please provide a code fix for the issue described here: "Button is misaligned".
B. Using Arguments in Shell Commands (Inside !{...}
Blocks)
When you use `` inside a shell injection block (!{...}
), the arguments are automatically shell-escaped before replacement. This allows you to safely pass arguments to shell commands, ensuring the resulting command is syntactically correct and secure while preventing command injection vulnerabilities.
Example (/grep-code.toml
):
prompt = """
Please summarize the findings for the pattern ``.
Search Results:
!{grep -r .}
"""
When you run /grep-code It's complicated
:
!{...}
.It's complicated
."It's complicated"
).grep -r "It's complicated" .
.If your prompt
does not contain the special placeholder ``, the CLI uses a default behavior for handling arguments.
If you provide arguments to the command (e.g., /mycommand arg1
), the CLI will append the full command you typed to the end of the prompt, separated by two newlines. This allows the model to see both the original instructions and the specific arguments you just provided.
If you do not provide any arguments (e.g., /mycommand
), the prompt is sent to the model exactly as it is, with nothing appended.
Example (changelog.toml
):
This example shows how to create a robust command by defining a role for the model, explaining where to find the user’s input, and specifying the expected format and behavior.
# In: <project>/.gemini/commands/changelog.toml
# Invoked via: /changelog 1.2.0 added "Support for default argument parsing."
description = "Adds a new entry to the project's CHANGELOG.md file."
prompt = """
# Task: Update Changelog
You are an expert maintainer of this software project. A user has invoked a command to add a new entry to the changelog.
**The user's raw command is appended below your instructions.**
Your task is to parse the `<version>`, `<change_type>`, and `<message>` from their input and use the `write_file` tool to correctly update the `CHANGELOG.md` file.
## Expected Format
The command follows this format: `/changelog <version> <type> <message>`
- `<type>` must be one of: "added", "changed", "fixed", "removed".
## Behavior
1. Read the `CHANGELOG.md` file.
2. Find the section for the specified `<version>`.
3. Add the `<message>` under the correct `<type>` heading.
4. If the version or type section doesn't exist, create it.
5. Adhere strictly to the "Keep a Changelog" format.
"""
When you run /changelog 1.2.0 added "New feature"
, the final text sent to the model will be the original prompt followed by two newlines and the command you typed.
!{...}
You can make your commands dynamic by executing shell commands directly within your prompt
and injecting their output. This is ideal for gathering context from your local environment, like reading file content or checking the status of Git.
When a custom command attempts to execute a shell command, Gemini CLI will now prompt you for confirmation before proceeding. This is a security measure to ensure that only intended commands can be run.
How It Works:
!{...}
syntax.!{...}
must have balanced braces ({
and }
). If you need to execute a command containing unbalanced braces, consider wrapping it in an external script file and calling the script within the !{...}
block.[Shell command exited with code 1]
. This helps the model understand the context of the failure.Example (git/commit.toml
):
This command gets the staged git diff and uses it to ask the model to write a commit message.
# In: <project>/.gemini/commands/git/commit.toml
# Invoked via: /git:commit
description = "Generates a Git commit message based on staged changes."
# The prompt uses !{...} to execute the command and inject its output.
prompt = """
Please generate a Conventional Commit message based on the following git diff:
```diff
!{git diff --staged}
```
"""
When you run /git:commit
, the CLI first executes git diff --staged
, then replaces !{git diff --staged}
with the output of that command before sending the final, complete prompt to the model.
@{...}
You can directly embed the content of a file or a directory listing into your prompt using the @{...}
syntax. This is useful for creating commands that operate on specific files.
How It Works:
@{path/to/file.txt}
is replaced by the content of file.txt
.@{path/to/dir}
is traversed and each file present within the directory and all subdirectories are inserted into the prompt. This respects .gitignore
and .geminiignore
if enabled.@{...}
is processed before shell commands (!{...}
) and argument substitution (``).@{...}
(the path) to have balanced braces ({
and }
).Example (review.toml
):
This command injects the content of a fixed best practices file (docs/best-practices.md
) and uses the user’s arguments to provide context for the review.
# In: <project>/.gemini/commands/review.toml
# Invoked via: /review FileCommandLoader.ts
description = "Reviews the provided context using a best practice guide."
prompt = """
You are an expert code reviewer.
Your task is to review .
Use the following best practices when providing your review:
@{docs/best-practices.md}
"""
When you run /review FileCommandLoader.ts
, the @{docs/best-practices.md}
placeholder is replaced by the content of that file, and `` is replaced by the text you provided, before the final prompt is sent to the model.
Let’s create a global command that asks the model to refactor a piece of code.
1. Create the file and directories:
First, ensure the user commands directory exists, then create a refactor
subdirectory for organization and the final TOML file.
mkdir -p ~/.gemini/commands/refactor
touch ~/.gemini/commands/refactor/pure.toml
2. Add the content to the file:
Open ~/.gemini/commands/refactor/pure.toml
in your editor and add the following content. We are including the optional description
for best practice.
# In: ~/.gemini/commands/refactor/pure.toml
# This command will be invoked via: /refactor:pure
description = "Asks the model to refactor the current context into a pure function."
prompt = """
Please analyze the code I've provided in the current context.
Refactor it into a pure function.
Your response should include:
1. The refactored, pure function code block.
2. A brief explanation of the key changes you made and why they contribute to purity.
"""
3. Run the Command:
That’s it! You can now run your command in the CLI. First, you might add a file to the context, and then invoke your command:
> @my-messy-function.js
> /refactor:pure
Gemini CLI will then execute the multi-line prompt defined in your TOML file.
These shortcuts apply directly to the input prompt for text manipulation.
@
)At commands are used to include the content of files or directories as part of your prompt to Gemini. These commands include git-aware filtering.
@<path_to_file_or_directory>
@path/to/your/file.txt Explain this text.
@src/my_project/ Summarize the code in this directory.
What is this file about? @README.md
@My\ Documents/file.txt
).read_many_files
tool internally. The content is fetched and then inserted into your query before being sent to the Gemini model.node_modules/
, dist/
, .env
, .git/
) are excluded. This behavior can be changed via the context.fileFiltering
settings.read_many_files
tool to ensure performance and relevance. The tool indicates if files were skipped.read_many_files
was used, along with a message detailing the status and the path(s) that were processed.@
(Lone at symbol)
@
symbol without a path, the query is passed as-is to the Gemini model. This might be useful if you are specifically talking about the @
symbol in your prompt.@
commands@
is not found or is invalid, an error message will be displayed, and the query might not be sent to the Gemini model, or it will be sent without the file content.read_many_files
tool encounters an error (e.g., permission issues), this will also be reported.!
)The !
prefix lets you interact with your system’s shell directly from within Gemini CLI.
!<shell_command>
<shell_command>
using bash
on Linux/macOS or cmd.exe
on Windows. Any output or errors from the command are displayed in the terminal.!ls -la
(executes ls -la
and returns to Gemini CLI)!git status
(executes git status
and returns to Gemini CLI)!
(Toggle shell mode)
!
on its own toggles shell mode.
Caution for all !
usage: Commands you execute in shell mode have the same permissions and impact as if you ran them directly in your terminal.
!
or in shell mode, the GEMINI_CLI=1
environment variable is set in the subprocess’s environment. This allows scripts or tools to detect if they are being run from within the Gemini CLI.