Skip to content

Plan Mode

Plan Mode is a read-only environment for architecting robust solutions before implementation. With Plan Mode, you can:

  • Research: Explore the project in a read-only state to prevent accidental changes.
  • Design: Understand problems, evaluate trade-offs, and choose a solution.
  • Plan: Align on an execution strategy before any code is modified.

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:

  1. Use the /settings command.
  2. Set Default Approval Mode to Plan.

To launch Gemini CLI in Plan Mode once:

  1. Use 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).

    Note: Plan Mode is automatically removed from the rotation when Gemini CLI is actively processing or showing confirmation dialogs.

  • Command: Type /plan in the input box.

  • Natural Language: Ask Gemini CLI to “start a plan for
”. Gemini CLI calls the enter_plan_mode tool to switch modes.

    Note: 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.

  1. 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.

  2. Review research and provide input: As Gemini CLI analyzes your codebase, it may ask you questions or present different implementation options using ask_user. Provide your preferences to help guide the design.

  3. Review the plan: Once Gemini CLI has a proposed strategy, it creates a detailed implementation plan as a Markdown file in your plans directory.

    • View: You can open and read this file to understand the proposed changes.
    • Edit: Press Ctrl+X to open the plan directly in your configured external editor.
  4. Approve or iterate: Gemini CLI will present the finalized plan for your approval.

    • Approve: If you’re satisfied with the plan, approve it to start the implementation immediately: Yes, automatically accept edits or Yes, manually accept edits.
    • Iterate: If the plan needs adjustments, provide feedback in the input box or edit the plan file directly. Gemini CLI will refine the strategy and update the plan.
    • Cancel: You can cancel your plan with 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.

  1. Open the plan: Press Ctrl+X when Gemini CLI presents a plan for review.
  2. Edit or comment: The plan opens in your configured external editor (for example, VS Code or Vim). You can:
    • Modify steps: Directly reorder, delete, or rewrite implementation steps.
    • Leave comments: Add inline questions or feedback (for example, “Wait, shouldn’t we use the existing Logger class here?”).
  3. Save and close: Save your changes and close the editor.
  4. Review and refine: Gemini CLI automatically detects the changes, reviews your comments, and adjusts the implementation strategy. It then presents the refined plan for your final approval.

You can exit Plan Mode at any time, whether you have finalized a plan or want to switch back to another mode.

  • Approve a plan: When Gemini CLI presents a finalized plan, approving it automatically exits Plan Mode and starts the implementation.
  • Keyboard shortcut: Press Shift+Tab to cycle to the desired mode.
  • Natural language: Ask Gemini CLI to “exit plan mode” or “stop planning.”

Plan Mode enforces strict safety policies to prevent accidental changes.

These are the only allowed tools:

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:

  • A “Database Migration” skill could ensure the plan includes data safety checks and rollback strategies.
  • A “Security Audit” skill could prompt Gemini CLI to look for specific vulnerabilities during codebase exploration.
  • A “Frontend Design” skill could guide Gemini CLI to use specific UI components and accessibility standards in its proposal.

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.

If you want a rule to apply 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]]
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.

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 path from the tool input JSON
plan_path=$(jq -r '.tool_input.plan_path // empty')
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:

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:

Note: 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:

  1. Planning Phase: While in Plan Mode, the CLI routes requests to a high-reasoning Pro model to ensure robust architectural decisions and high-quality plans.
  2. Implementation Phase: Once a plan is approved and you exit Plan Mode, the CLI detects the existence of the approved plan and automatically switches to a high-speed Flash model. This provides a faster, more responsive experience during the implementation of the plan.

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.

  • Default behavior: Sessions (and their plans) are retained for 30 days.
  • Configuration: You can customize this behavior via the /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:

  • Command Line: Use gemini --delete-session <index|id>.
  • Session Browser: Press /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.