mirror of
https://github.com/google-gemini/gemini-cli.git
synced 2026-05-01 15:34:29 -07:00
fix(agent): prevent exit_plan_mode from being called via shell (#26230)
This commit is contained in:
Abhijit Balaji
@@ -118,7 +118,7 @@ The following tools are available in Plan Mode:
|
||||
- **Inquiries:** If the request is an **Inquiry** (e.g., "How does X work?"), answer directly. DO NOT create a plan.
|
||||
- **Directives:** If the request is a **Directive** (e.g., "Fix bug Y"), follow the workflow below.
|
||||
5. **Plan Storage:** Save plans as Markdown (.md) using descriptive filenames.
|
||||
6. **Direct Modification:** If asked to modify code, explain you are in Plan Mode and use \`exit_plan_mode\` to request approval.
|
||||
6. **Direct Modification:** If asked to modify code, explain you are in Plan Mode and use the built-in \`exit_plan_mode\` tool to request approval. **CRITICAL: NEVER attempt to call this tool via \`run_shell_command\`.**
|
||||
7. **Presenting Plan:** When seeking informal agreement on a plan, or any time the user asks to see the plan, you MUST output the full content of the plan in the chat response. This overrides the "Minimal Output" guideline.
|
||||
|
||||
## Planning Workflow
|
||||
@@ -143,7 +143,7 @@ Write the implementation plan to \`../plans/\`. The plan's structure adapts to t
|
||||
- **Alignment Check:** After drafting the plan, you MUST present it to the user in the chat (adhering to Rule 7 for presenting plans) to ensure alignment on the specific details. Ask for feedback or confirmation, and proceed to Step 4 (Review & Approval) once the user agrees with the detailed plan.
|
||||
|
||||
### 4. Review & Approval
|
||||
ONLY use the \`exit_plan_mode\` tool to present the plan for formal approval AFTER you have reached an informal agreement with the user in the chat regarding the proposed strategy. When called, this tool will present the plan and formally request approval.
|
||||
ONLY use the built-in \`exit_plan_mode\` tool to present the plan for formal approval AFTER you have reached an informal agreement with the user in the chat regarding the proposed strategy. **CRITICAL: NEVER attempt to call this tool via \`run_shell_command\`.** When called, this tool will present the plan and formally request approval.
|
||||
|
||||
# Operational Guidelines
|
||||
|
||||
@@ -298,7 +298,7 @@ The following tools are available in Plan Mode:
|
||||
- **Inquiries:** If the request is an **Inquiry** (e.g., "How does X work?"), answer directly. DO NOT create a plan.
|
||||
- **Directives:** If the request is a **Directive** (e.g., "Fix bug Y"), follow the workflow below.
|
||||
5. **Plan Storage:** Save plans as Markdown (.md) using descriptive filenames.
|
||||
6. **Direct Modification:** If asked to modify code, explain you are in Plan Mode and use \`exit_plan_mode\` to request approval.
|
||||
6. **Direct Modification:** If asked to modify code, explain you are in Plan Mode and use the built-in \`exit_plan_mode\` tool to request approval. **CRITICAL: NEVER attempt to call this tool via \`run_shell_command\`.**
|
||||
7. **Presenting Plan:** When seeking informal agreement on a plan, or any time the user asks to see the plan, you MUST output the full content of the plan in the chat response. This overrides the "Minimal Output" guideline.
|
||||
|
||||
## Planning Workflow
|
||||
@@ -323,7 +323,7 @@ Write the implementation plan to \`../plans/\`. The plan's structure adapts to t
|
||||
- **Alignment Check:** After drafting the plan, you MUST present it to the user in the chat (adhering to Rule 7 for presenting plans) to ensure alignment on the specific details. Ask for feedback or confirmation, and proceed to Step 4 (Review & Approval) once the user agrees with the detailed plan.
|
||||
|
||||
### 4. Review & Approval
|
||||
ONLY use the \`exit_plan_mode\` tool to present the plan for formal approval AFTER you have reached an informal agreement with the user in the chat regarding the proposed strategy. When called, this tool will present the plan and formally request approval.
|
||||
ONLY use the built-in \`exit_plan_mode\` tool to present the plan for formal approval AFTER you have reached an informal agreement with the user in the chat regarding the proposed strategy. **CRITICAL: NEVER attempt to call this tool via \`run_shell_command\`.** When called, this tool will present the plan and formally request approval.
|
||||
|
||||
## Approved Plan
|
||||
An approved plan is available for this task at \`../plans/feature-x.md\`.
|
||||
@@ -599,7 +599,7 @@ The following tools are available in Plan Mode:
|
||||
- **Inquiries:** If the request is an **Inquiry** (e.g., "How does X work?"), answer directly. DO NOT create a plan.
|
||||
- **Directives:** If the request is a **Directive** (e.g., "Fix bug Y"), follow the workflow below.
|
||||
5. **Plan Storage:** Save plans as Markdown (.md) using descriptive filenames.
|
||||
6. **Direct Modification:** If asked to modify code, explain you are in Plan Mode and use \`exit_plan_mode\` to request approval.
|
||||
6. **Direct Modification:** If asked to modify code, explain you are in Plan Mode and use the built-in \`exit_plan_mode\` tool to request approval. **CRITICAL: NEVER attempt to call this tool via \`run_shell_command\`.**
|
||||
7. **Presenting Plan:** When seeking informal agreement on a plan, or any time the user asks to see the plan, you MUST output the full content of the plan in the chat response. This overrides the "Minimal Output" guideline.
|
||||
|
||||
## Planning Workflow
|
||||
@@ -624,7 +624,7 @@ Write the implementation plan to \`plans/\`. The plan's structure adapts to the
|
||||
- **Alignment Check:** After drafting the plan, you MUST present it to the user in the chat (adhering to Rule 7 for presenting plans) to ensure alignment on the specific details. Ask for feedback or confirmation, and proceed to Step 4 (Review & Approval) once the user agrees with the detailed plan.
|
||||
|
||||
### 4. Review & Approval
|
||||
ONLY use the \`exit_plan_mode\` tool to present the plan for formal approval AFTER you have reached an informal agreement with the user in the chat regarding the proposed strategy. When called, this tool will present the plan and formally request approval.
|
||||
ONLY use the built-in \`exit_plan_mode\` tool to present the plan for formal approval AFTER you have reached an informal agreement with the user in the chat regarding the proposed strategy. **CRITICAL: NEVER attempt to call this tool via \`run_shell_command\`.** When called, this tool will present the plan and formally request approval.
|
||||
|
||||
# Operational Guidelines
|
||||
|
||||
|
||||
@@ -477,7 +477,7 @@ ${options.planModeToolsList}
|
||||
- Save the implementation plan to the designated plans directory
|
||||
|
||||
### Phase 4: Review & Approval
|
||||
- Present the plan and request approval for the finalized plan using the \`${EXIT_PLAN_MODE_TOOL_NAME}\` tool
|
||||
- Present the plan and request approval for the finalized plan using the built-in \`${EXIT_PLAN_MODE_TOOL_NAME}\` tool. **CRITICAL: NEVER attempt to call this tool via \`${SHELL_TOOL_NAME}\`.**
|
||||
- If plan is approved, you can begin implementation
|
||||
- If plan is rejected, address the feedback and iterate on the plan
|
||||
|
||||
|
||||
@@ -604,7 +604,7 @@ ${options.planModeToolsList}
|
||||
- **Inquiries:** If the request is an **Inquiry** (e.g., "How does X work?"), answer directly. DO NOT create a plan.
|
||||
- **Directives:** If the request is a **Directive** (e.g., "Fix bug Y"), follow the workflow below.
|
||||
5. **Plan Storage:** Save plans as Markdown (.md) using descriptive filenames.
|
||||
6. **Direct Modification:** If asked to modify code, explain you are in Plan Mode and use ${formatToolName(EXIT_PLAN_MODE_TOOL_NAME)} to request approval.
|
||||
6. **Direct Modification:** If asked to modify code, explain you are in Plan Mode and use the built-in ${formatToolName(EXIT_PLAN_MODE_TOOL_NAME)} tool to request approval. **CRITICAL: NEVER attempt to call this tool via ${formatToolName(SHELL_TOOL_NAME)}.**
|
||||
7. **Presenting Plan:** When seeking informal agreement on a plan, or any time the user asks to see the plan, you MUST output the full content of the plan in the chat response. This overrides the "Minimal Output" guideline.
|
||||
|
||||
## Planning Workflow
|
||||
@@ -628,7 +628,7 @@ Write the implementation plan to \`${options.plansDir}/\`. The plan's structure
|
||||
- **Complex Tasks:** Include **Background & Motivation**, **Scope & Impact**, **Proposed Solution**, **Alternatives Considered**, a phased **Implementation Plan**, **Verification**, and **Migration & Rollback** strategies.${options.interactive ? '\n- **Alignment Check:** After drafting the plan, you MUST present it to the user in the chat (adhering to Rule 7 for presenting plans) to ensure alignment on the specific details. Ask for feedback or confirmation, and proceed to Step 4 (Review & Approval) once the user agrees with the detailed plan.' : ''}
|
||||
|
||||
### 4. Review & Approval
|
||||
ONLY use the ${formatToolName(EXIT_PLAN_MODE_TOOL_NAME)} tool to present the plan for formal approval AFTER you have reached an informal agreement with the user in the chat regarding the proposed strategy. When called, this tool will present the plan and ${options.interactive ? 'formally request approval.' : 'begin implementation.'}
|
||||
ONLY use the built-in ${formatToolName(EXIT_PLAN_MODE_TOOL_NAME)} tool to present the plan for formal approval AFTER you have reached an informal agreement with the user in the chat regarding the proposed strategy. **CRITICAL: NEVER attempt to call this tool via ${formatToolName(SHELL_TOOL_NAME)}.** When called, this tool will present the plan and ${options.interactive ? 'formally request approval.' : 'begin implementation.'}
|
||||
|
||||
${renderApprovedPlanSection(options.approvedPlanPath)}`.trim();
|
||||
}
|
||||
|
||||
Reference in New Issue
Block a user