docs/cli/plan-mode.md
Plan Mode is a read-only environment for architecting robust solutions before implementation. With Plan Mode, you can:
Plan Mode is enabled by default. You can manage this setting using the
/settings command.
Plan Mode integrates seamlessly into your workflow, letting you switch between planning and execution as needed.
You can either configure Gemini CLI to start in Plan Mode by default or enter Plan Mode manually during a session.
To start Gemini CLI directly in Plan Mode by default:
/settings command.Plan.To launch Gemini CLI in Plan Mode once:
gemini --approval-mode=plan when launching Gemini CLI.To start Plan Mode while using Gemini CLI:
Keyboard shortcut: Press Shift+Tab to cycle through approval modes
(Default -> Auto-Edit -> Plan). Plan Mode is automatically removed from
the rotation when Gemini CLI is actively processing or showing confirmation
dialogs.
Command: Type /plan [goal] in the input box. The [goal] is optional;
for example, /plan implement authentication will switch to Plan Mode and
immediately submit the prompt to the model.
Natural Language: Ask Gemini CLI to "start a plan for...". Gemini CLI
calls the
enter_plan_mode tool
to switch modes. This tool is not available when Gemini CLI is in
YOLO mode.
Plan Mode lets you collaborate with Gemini CLI to design a solution before Gemini CLI takes action.
Provide a goal: Start by describing what you want to achieve. Gemini CLI will then enter Plan Mode (if it's not already) to research the task.
Discuss and agree on strategy: As Gemini CLI analyzes your codebase, it
will discuss its findings and proposed strategy with you to ensure
alignment. It may ask you questions or present different implementation
options using ask_user. Gemini CLI will stop and
wait for your confirmation before drafting the formal plan. You should
reach an informal agreement on the approach before proceeding.
Review the plan: Once you've agreed on the strategy, Gemini CLI creates a detailed implementation plan as a Markdown file in your plans directory.
Ctrl+X to open the plan directly in your configured
external editor.Approve or iterate: Gemini CLI will present the finalized plan for your formal approval.
Esc.For more complex or specialized planning tasks, you can customize the planning workflow with skills.
You can collaborate with Gemini CLI by making direct changes or leaving comments in the implementation plan. This is often faster and more precise than describing complex changes in natural language.
Ctrl+X when Gemini CLI presents a plan for
review.Logger class here?").You can exit Plan Mode at any time, whether you have finalized a plan or want to switch back to another mode.
Shift+Tab to cycle to the desired mode.Plan Mode enforces strict safety policies to prevent accidental changes.
These are the only allowed tools:
read_file,
list_directory,
globgrep_search,
google_web_search,
web_fetch (requires explicit confirmation),
get_internal_docscodebase_investigator,
cli_helpask_usergithub_read_issue, postgres_read_schema) and core
MCP resource tools (list_mcp_resources,
read_mcp_resource) are allowed.write_file and
replace only allowed for .md
files in the ~/.gemini/tmp/<project>/<session-id>/plans/ directory or your
custom plans directory.save_memoryactivate_skill (allows loading specialized
instructions and resources in a read-only manner)Plan Mode is secure by default, but you can adapt it to fit your specific workflows. You can customize how Gemini CLI plans by using skills, adjusting safety policies, changing where plans are stored, or adding hooks.
You can use Agent Skills to customize how Gemini CLI approaches planning for specific types of tasks. When a skill is activated during Plan Mode, its specialized instructions and procedural workflows will guide the research, design, and planning phases.
For example:
To use a skill in Plan Mode, you can explicitly ask Gemini CLI to "use the
<skill-name> skill to plan..." or Gemini CLI may autonomously activate it
based on the task description.
Plan Mode's default tool restrictions are managed by the
policy engine and defined in the built-in
plan.toml file. The built-in policy (Tier 1) enforces the read-only state,
but you can customize these rules by creating your own policies in your
~/.gemini/policies/ directory (Tier 2).
As described in the
policy engine documentation, any
rule that does not explicitly specify modes is considered "always active" and
will apply to Plan Mode as well.
To maintain the integrity of Plan Mode as a safe research environment, persistent tool approvals are context-aware. Approvals granted in modes like Default or Auto-Edit do not apply to Plan Mode, ensuring that tools trusted for implementation don't automatically execute while you're researching. However, approvals granted while in Plan Mode are treated as intentional choices for global trust and apply to all modes.
If you want to manually restrict a rule to other modes but not to Plan Mode,
you must explicitly specify the target modes. For example, to allow npm test
in default and Auto-Edit modes but not in Plan Mode:
[[rule]]
toolName = "run_shell_command"
commandPrefix = "npm test"
decision = "allow"
priority = 100
# By omitting "plan", this rule will not be active in Plan Mode.
modes = ["default", "autoEdit"]
By default, read-only MCP tools require user confirmation in Plan Mode. You can
use toolAnnotations and the mcpName wildcard to customize this behavior for
your specific environment.
~/.gemini/policies/mcp-read-only.toml
[[rule]]
toolName = "*"
mcpName = "*"
toolAnnotations = { readOnlyHint = true }
decision = "allow"
priority = 100
modes = ["plan"]
For more information on how the policy engine works, see the policy engine docs.
This rule lets you check the repository status and see changes while in Plan Mode.
~/.gemini/policies/git-research.toml
[[rule]]
toolName = "run_shell_command"
commandPrefix = ["git status", "git diff"]
decision = "allow"
priority = 100
modes = ["plan"]
Built-in research subagents like
codebase_investigator and
cli_help are enabled by default in Plan
Mode. You can enable additional
custom subagents by adding a
rule to your policy.
~/.gemini/policies/research-subagents.toml
[[rule]]
toolName = "my_custom_subagent"
decision = "allow"
priority = 100
modes = ["plan"]
Tell Gemini CLI it can use these tools in your prompt, for example: "You can check ongoing changes in git."
By default, planning artifacts are stored in a managed temporary directory
outside your project: ~/.gemini/tmp/<project>/<session-id>/plans/.
You can configure a custom directory for plans in your settings.json. For
example, to store plans in a .gemini/plans directory within your project:
{
"general": {
"plan": {
"directory": ".gemini/plans"
}
}
}
To maintain the safety of Plan Mode, user-configured paths for the plans directory are restricted to the project root. This ensures that custom planning locations defined within a project's workspace cannot be used to escape and overwrite sensitive files elsewhere. Any user-configured directory must reside within the project boundary.
Using a custom directory requires updating your
policy engine configurations to allow
write_file and replace in that specific location. For example, to allow
writing to the .gemini/plans directory within your project, create a policy
file at ~/.gemini/policies/plan-custom-directory.toml:
[[rule]]
toolName = ["write_file", "replace"]
decision = "allow"
priority = 100
modes = ["plan"]
# Adjust the pattern to match your custom directory.
# This example matches any .md file in a .gemini/plans directory within the project.
argsPattern = "\"file_path\":\"[^\"]+[\\\\/]+\\.gemini[\\\\/]+plans[\\\\/]+[\\w-]+\\.md\""
You can use the hook system to automate parts of the planning workflow or enforce additional checks when Gemini CLI transitions into or out of Plan Mode.
Hooks such as BeforeTool or AfterTool can be configured to intercept the
enter_plan_mode and exit_plan_mode tool calls.
[!WARNING] When hooks are triggered by tool executions, they do not run when you manually toggle Plan Mode using the
/plancommand or theShift+Tabkeyboard shortcut. If you need hooks to execute on mode changes, ensure the transition is initiated by the agent (for example, by asking "start a plan for...").
AfterTool)If your organizational policy requires a record of all execution plans, you can
use an AfterTool hook to securely copy the plan artifact to Google Cloud
Storage whenever Gemini CLI exits Plan Mode to start the implementation.
.gemini/hooks/archive-plan.sh:
#!/usr/bin/env bash
# Extract the plan filename from the tool input JSON
plan_filename=$(jq -r '.tool_input.plan_filename // empty')
# Construct the absolute path using the GEMINI_PLANS_DIR environment variable
plan_path="$GEMINI_PLANS_DIR/$plan_filename"
if [ -f "$plan_path" ]; then
# Generate a unique filename using a timestamp
filename="$(date +%s)_$(basename "$plan_path")"
# Upload the plan to GCS in the background so it doesn't block the CLI
gsutil cp "$plan_path" "gs://my-audit-bucket/gemini-plans/$filename" > /dev/null 2>&1 &
fi
# AfterTool hooks should generally allow the flow to continue
echo '{"decision": "allow"}'
To register this AfterTool hook, add it to your settings.json:
{
"hooks": {
"AfterTool": [
{
"matcher": "exit_plan_mode",
"hooks": [
{
"name": "archive-plan",
"type": "command",
"command": "~/.gemini/hooks/archive-plan.sh"
}
]
}
]
}
}
/plan copy: Copy the currently approved plan to your clipboard.Plan Mode provides building blocks for structured research and design. These are
implemented as extensions using core planning tools
like enter_plan_mode,
exit_plan_mode, and
ask_user.
The built-in planner uses an adaptive workflow to analyze your project, consult
you on trade-offs via ask_user, and draft a plan for
your approval.
You can install or create specialized planners to suit your workflow.
Conductor is designed for spec-driven development. It organizes work into
"tracks" and stores persistent artifacts in your project's conductor/
directory:
enter_plan_mode.ask_user for
architectural choices.exit_plan_mode.Since Plan Mode is built on modular building blocks, you can develop your own custom planning workflow as an extensions. By leveraging core tools and custom policies, you can define how Gemini CLI researches and stores plans for your specific domain.
To build a custom planning workflow, you can use:
enter_plan_mode,
ask_user, and
exit_plan_mode to
manage the research and design process.[!TIP] Use Conductor as a reference when building your own custom planning workflow.
By using Plan Mode as its execution environment, your custom methodology can enforce read-only safety during the design phase while benefiting from high-reasoning model routing.
When using an auto model, Gemini CLI automatically optimizes model routing based on the current phase of your task:
If the high-reasoning model is unavailable or you don't have access to it, Gemini CLI automatically and silently falls back to a faster model to ensure your workflow isn't interrupted.
This behavior is enabled by default to provide the best balance of quality and performance. You can disable this automatic switching in your settings:
{
"general": {
"plan": {
"modelRouting": false
}
}
}
By default, Gemini CLI automatically cleans up old session data, including all associated plan files and task trackers.
/settings command
(search for Session Retention) or in your settings.json file. See
session retention for more
details.Manual deletion also removes all associated artifacts:
gemini --delete-session <index|id>./resume, navigate to a session, and press x.If you use a custom plans directory, those files are not automatically deleted and must be managed manually.
When running Gemini CLI in non-interactive environments (such as headless scripts or CI/CD pipelines), Plan Mode optimizes for automated workflows:
enter_plan_mode and exit_plan_mode tools without prompting for user
confirmation.Example:
gemini --approval-mode plan -p "Analyze telemetry and suggest improvements"