Fixes #4882: Remove experimental setting for command execution in attempt_completion (#4884)

* Fixes #4882: Remove experimental setting for command execution in attempt_completion

- Remove DISABLE_COMPLETION_COMMAND from experiments system
- Permanently disable command execution in attempt_completion tool
- Update tool prompts to remove command parameter and examples
- Remove experimental UI toggle and localization entries (18+ languages)
- Update tests to reflect permanent behavior
- Remove experiment-specific test file

Command execution is now permanently disabled in attempt_completion.
Users must use execute_command tool separately before attempt_completion.

* refactor: simplify getAttemptCompletionDescription by removing unnecessary variables

* test: fix tests by regenerating snaps

---------

Co-authored-by: Daniel Riccio <[email protected]>

packages/types/src/experiment.ts

@@ -6,7 +6,7 @@ import type { Keys, Equals, AssertEqual } from "./type-fu.js"
  * ExperimentId
  */
 
-export const experimentIds = ["powerSteering", "disableCompletionCommand", "multiFileApplyDiff"] as const
+export const experimentIds = ["powerSteering", "multiFileApplyDiff"] as const
 
 export const experimentIdsSchema = z.enum(experimentIds)
 
@@ -18,7 +18,6 @@ export type ExperimentId = z.infer<typeof experimentIdsSchema>
 
 export const experimentsSchema = z.object({
 	powerSteering: z.boolean().optional(),
-	disableCompletionCommand: z.boolean().optional(),
 	multiFileApplyDiff: z.boolean().optional(),
 })
 

src/core/prompts/__tests__/__snapshots__/add-custom-instructions/architect-mode-prompt.snap

@@ -298,25 +298,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -449,7 +446,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/add-custom-instructions/ask-mode-prompt.snap

@@ -195,25 +195,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -346,7 +343,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-disabled.snap

@@ -369,25 +369,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -533,7 +530,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/add-custom-instructions/mcp-server-creation-enabled.snap

@@ -369,25 +369,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -539,7 +536,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/add-custom-instructions/partial-reads-enabled.snap

@@ -325,25 +325,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -476,7 +473,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/system-prompt/consistent-system-prompt.snap

@@ -320,25 +320,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -471,7 +468,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/system-prompt/with-computer-use-support.snap

@@ -373,25 +373,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -527,7 +524,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-false.snap

@@ -320,25 +320,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -471,7 +468,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-true.snap

@@ -408,25 +408,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -559,7 +556,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/system-prompt/with-diff-enabled-undefined.snap

@@ -320,25 +320,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -471,7 +468,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/system-prompt/with-different-viewport-size.snap

@@ -373,25 +373,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -527,7 +524,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/system-prompt/with-mcp-hub-provided.snap

@@ -369,25 +369,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -539,7 +536,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/__tests__/__snapshots__/system-prompt/with-undefined-mcp-hub.snap

@@ -320,25 +320,22 @@ Example: Requesting to ask the user for the path to the frontend-config.json fil
 </ask_followup_question>
 
 ## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. Optionally you may provide a CLI command to showcase the result of your work. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
 - result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use `open index.html` to display a created html website, or `open localhost:3000` to display a locally running development server. But DO NOT use commands like `echo` or `cat` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
 </result>
-<command>Command to demonstrate result (optional)</command>
 </attempt_completion>
 
-Example: Requesting to attempt completion with a result and command
+Example: Requesting to attempt completion with a result
 <attempt_completion>
 <result>
 I've updated the CSS
 </result>
-<command>open index.html</command>
 </attempt_completion>
 
 ## switch_mode
@@ -471,7 +468,7 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. First, analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user. You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. `open index.html` to show the website you've built.
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.
 
 

src/core/prompts/sections/objective.ts

@@ -1,4 +1,3 @@
-import { EXPERIMENT_IDS, experiments } from "../../../shared/experiments"
 import { CodeIndexManager } from "../../../services/code-index/manager"
 
 export function getObjectiveSection(
@@ -15,13 +14,6 @@ export function getObjectiveSection(
 		? "First, if the task involves understanding existing code or functionality, you MUST use the `codebase_search` tool to search for relevant code based on the task's intent BEFORE using any other search or file exploration tools. Then, "
 		: "First, "
 
-	// Check if command execution is disabled via experiment
-	const isCommandDisabled = experimentsConfig && experimentsConfig[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]
-
-	const commandInstruction = !isCommandDisabled
-		? " You may also provide a CLI command to showcase the result of your task; this can be particularly useful for web development tasks, where you can run e.g. \`open index.html\` to show the website you've built."
-		: ""
-
 	return `====
 
 OBJECTIVE
@@ -31,6 +23,6 @@ You accomplish a given task iteratively, breaking it down into clear steps and w
 1. Analyze the user's task and set clear, achievable goals to accomplish it. Prioritize these goals in a logical order.
 2. Work through these goals sequentially, utilizing available tools one at a time as necessary. Each goal should correspond to a distinct step in your problem-solving process. You will be informed on the work completed and what's remaining as you go.
 3. Remember, you have extensive capabilities with access to a wide range of tools that can be used in powerful and clever ways as necessary to accomplish each goal. Before calling a tool, do some analysis within <thinking></thinking> tags. ${codebaseSearchInstruction}analyze the file structure provided in environment_details to gain context and insights for proceeding effectively. Next, think about which of the provided tools is the most relevant tool to accomplish the user's task. Go through each of the required parameters of the relevant tool and determine if the user has directly provided or given enough information to infer a value. When deciding if the parameter can be inferred, carefully consider all the context to see if it supports a specific value. If all of the required parameters are present or can be reasonably inferred, close the thinking tag and proceed with the tool use. BUT, if one of the values for a required parameter is missing, DO NOT invoke the tool (not even with fillers for the missing params) and instead, ask the user to provide the missing parameters using the ask_followup_question tool. DO NOT ask for more information on optional parameters if it is not provided.
-4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.${commandInstruction}
+4. Once you've completed the user's task, you must use the attempt_completion tool to present the result of the task to the user.
 5. The user may provide feedback, which you can use to make improvements and try again. But DO NOT continue in pointless back and forth conversations, i.e. don't end your responses with questions or offers for further assistance.`
 }

src/core/prompts/tools/__tests__/attempt-completion.spec.ts

@@ -1,129 +1,69 @@
 import { getAttemptCompletionDescription } from "../attempt-completion"
-import { EXPERIMENT_IDS } from "../../../../shared/experiments"
 
-describe("getAttemptCompletionDescription - DISABLE_COMPLETION_COMMAND experiment", () => {
-	describe("when experiment is disabled (default)", () => {
-		it("should include command parameter in the description", () => {
-			const args = {
-				cwd: "/test/path",
-				supportsComputerUse: false,
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: false,
-				},
-			}
-
-			const description = getAttemptCompletionDescription(args)
-
-			// Check that command parameter is included
-			expect(description).toContain("- command: (optional)")
-			expect(description).toContain("A CLI command to execute to show a live demo")
-			expect(description).toContain("<command>Command to demonstrate result (optional)</command>")
-			expect(description).toContain("<command>open index.html</command>")
-		})
-
-		it("should include command parameter when experiments is undefined", () => {
-			const args = {
-				cwd: "/test/path",
-				supportsComputerUse: false,
-			}
-
-			const description = getAttemptCompletionDescription(args)
-
-			// Check that command parameter is included
-			expect(description).toContain("- command: (optional)")
-			expect(description).toContain("A CLI command to execute to show a live demo")
-			expect(description).toContain("<command>Command to demonstrate result (optional)</command>")
-			expect(description).toContain("<command>open index.html</command>")
-		})
-
-		it("should include command parameter when no args provided", () => {
-			const description = getAttemptCompletionDescription()
-
-			// Check that command parameter is included
-			expect(description).toContain("- command: (optional)")
-			expect(description).toContain("A CLI command to execute to show a live demo")
-			expect(description).toContain("<command>Command to demonstrate result (optional)</command>")
-			expect(description).toContain("<command>open index.html</command>")
-		})
+describe("getAttemptCompletionDescription", () => {
+	it("should NOT include command parameter in the description", () => {
+		const args = {
+			cwd: "/test/path",
+			supportsComputerUse: false,
+		}
+
+		const description = getAttemptCompletionDescription(args)
+
+		// Check that command parameter is NOT included (permanently disabled)
+		expect(description).not.toContain("- command: (optional)")
+		expect(description).not.toContain("A CLI command to execute to show a live demo")
+		expect(description).not.toContain("<command>Command to demonstrate result (optional)</command>")
+		expect(description).not.toContain("<command>open index.html</command>")
+
+		// But should still have the basic structure
+		expect(description).toContain("## attempt_completion")
+		expect(description).toContain("- result: (required)")
+		expect(description).toContain("<attempt_completion>")
+		expect(description).toContain("</attempt_completion>")
 	})
 
-	describe("when experiment is enabled", () => {
-		it("should NOT include command parameter in the description", () => {
-			const args = {
-				cwd: "/test/path",
-				supportsComputerUse: false,
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: true,
-				},
-			}
-
-			const description = getAttemptCompletionDescription(args)
+	it("should work when no args provided", () => {
+		const description = getAttemptCompletionDescription()
 
-			// Check that command parameter is NOT included
-			expect(description).not.toContain("- command: (optional)")
-			expect(description).not.toContain("A CLI command to execute to show a live demo")
-			expect(description).not.toContain("<command>Command to demonstrate result (optional)</command>")
-			expect(description).not.toContain("<command>open index.html</command>")
+		// Check that command parameter is NOT included (permanently disabled)
+		expect(description).not.toContain("- command: (optional)")
+		expect(description).not.toContain("A CLI command to execute to show a live demo")
+		expect(description).not.toContain("<command>Command to demonstrate result (optional)</command>")
+		expect(description).not.toContain("<command>open index.html</command>")
 
-			// But should still have the basic structure
-			expect(description).toContain("## attempt_completion")
-			expect(description).toContain("- result: (required)")
-			expect(description).toContain("<attempt_completion>")
-			expect(description).toContain("</attempt_completion>")
-		})
+		// But should still have the basic structure
+		expect(description).toContain("## attempt_completion")
+		expect(description).toContain("- result: (required)")
+		expect(description).toContain("<attempt_completion>")
+		expect(description).toContain("</attempt_completion>")
+	})
 
-		it("should show example without command", () => {
-			const args = {
-				cwd: "/test/path",
-				supportsComputerUse: false,
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: true,
-				},
-			}
+	it("should show example without command", () => {
+		const args = {
+			cwd: "/test/path",
+			supportsComputerUse: false,
+		}
 
-			const description = getAttemptCompletionDescription(args)
+		const description = getAttemptCompletionDescription(args)
 
-			// Check example format
-			expect(description).toContain("Example: Requesting to attempt completion with a result")
-			expect(description).toContain("I've updated the CSS")
-			expect(description).not.toContain("Example: Requesting to attempt completion with a result and command")
-		})
+		// Check example format
+		expect(description).toContain("Example: Requesting to attempt completion with a result")
+		expect(description).toContain("I've updated the CSS")
+		expect(description).not.toContain("Example: Requesting to attempt completion with a result and command")
 	})
 
-	describe("description content", () => {
-		it("should maintain core functionality description regardless of experiment", () => {
-			const argsWithExperimentDisabled = {
-				cwd: "/test/path",
-				supportsComputerUse: false,
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: false,
-				},
-			}
-
-			const argsWithExperimentEnabled = {
-				cwd: "/test/path",
-				supportsComputerUse: false,
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: true,
-				},
-			}
-
-			const descriptionDisabled = getAttemptCompletionDescription(argsWithExperimentDisabled)
-			const descriptionEnabled = getAttemptCompletionDescription(argsWithExperimentEnabled)
+	it("should contain core functionality description", () => {
+		const description = getAttemptCompletionDescription()
 
-			// Both should contain core functionality
-			const coreText = "After each tool use, the user will respond with the result of that tool use"
-			expect(descriptionDisabled).toContain(coreText)
-			expect(descriptionEnabled).toContain(coreText)
+		// Should contain core functionality
+		const coreText = "After each tool use, the user will respond with the result of that tool use"
+		expect(description).toContain(coreText)
 
-			// Both should contain the important note
-			const importantNote = "IMPORTANT NOTE: This tool CANNOT be used until you've confirmed"
-			expect(descriptionDisabled).toContain(importantNote)
-			expect(descriptionEnabled).toContain(importantNote)
+		// Should contain the important note
+		const importantNote = "IMPORTANT NOTE: This tool CANNOT be used until you've confirmed"
+		expect(description).toContain(importantNote)
 
-			// Both should contain result parameter
-			expect(descriptionDisabled).toContain("- result: (required)")
-			expect(descriptionEnabled).toContain("- result: (required)")
-		})
+		// Should contain result parameter
+		expect(description).toContain("- result: (required)")
 	})
 })

src/core/prompts/tools/attempt-completion.ts

@@ -1,41 +1,17 @@
-import { EXPERIMENT_IDS, experiments } from "../../../shared/experiments"
 import { ToolArgs } from "./types"
 
 export function getAttemptCompletionDescription(args?: ToolArgs): string {
-	// Check if command execution is disabled via experiment
-	const isCommandDisabled =
-		args?.experiments && experiments.isEnabled(args.experiments, EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND)
-
-	const baseDescription = `## attempt_completion
-Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user.${!isCommandDisabled ? " Optionally you may provide a CLI command to showcase the result of your work." : ""} The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
+	return `## attempt_completion
+Description: After each tool use, the user will respond with the result of that tool use, i.e. if it succeeded or failed, along with any reasons for failure. Once you've received the results of tool uses and can confirm that the task is complete, use this tool to present the result of your work to the user. The user may respond with feedback if they are not satisfied with the result, which you can use to make improvements and try again.
 IMPORTANT NOTE: This tool CANNOT be used until you've confirmed from the user that any previous tool uses were successful. Failure to do so will result in code corruption and system failure. Before using this tool, you must ask yourself in <thinking></thinking> tags if you've confirmed from the user that any previous tool uses were successful. If not, then DO NOT use this tool.
 Parameters:
-- result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.`
-
-	const commandParameter = !isCommandDisabled
-		? `
-- command: (optional) A CLI command to execute to show a live demo of the result to the user. For example, use \`open index.html\` to display a created html website, or \`open localhost:3000\` to display a locally running development server. But DO NOT use commands like \`echo\` or \`cat\` that merely print text. This command should be valid for the current operating system. Ensure the command is properly formatted and does not contain any harmful instructions.`
-		: ""
-
-	const usage = `
+- result: (required) The result of the task. Formulate this result in a way that is final and does not require further input from the user. Don't end your result with questions or offers for further assistance.
 Usage:
 <attempt_completion>
 <result>
 Your final result description here
-</result>${!isCommandDisabled ? "\n<command>Command to demonstrate result (optional)</command>" : ""}
-</attempt_completion>`
-
-	const example = !isCommandDisabled
-		? `
-
-Example: Requesting to attempt completion with a result and command
-<attempt_completion>
-<result>
-I've updated the CSS
 </result>
-<command>open index.html</command>
-</attempt_completion>`
-		: `
+</attempt_completion>
 
 Example: Requesting to attempt completion with a result
 <attempt_completion>
@@ -43,6 +19,4 @@ Example: Requesting to attempt completion with a result
 I've updated the CSS
 </result>
 </attempt_completion>`
-
-	return baseDescription + commandParameter + usage + example
 }

src/core/tools/__tests__/attemptCompletionTool.experiment.spec.ts

@@ -1,356 +0,0 @@
-// Mocks must come first, before imports
-vi.mock("../executeCommandTool", () => ({
-	executeCommand: vi.fn(),
-}))
-
-vi.mock("@roo-code/telemetry", () => ({
-	TelemetryService: {
-		instance: {
-			captureTaskCompleted: vi.fn(),
-		},
-	},
-}))
-
-// Then imports
-import type { Mock } from "vitest"
-import { attemptCompletionTool } from "../attemptCompletionTool"
-import { EXPERIMENT_IDS } from "../../../shared/experiments"
-import { executeCommand } from "../executeCommandTool"
-
-describe("attemptCompletionTool - DISABLE_COMPLETION_COMMAND experiment", () => {
-	let mockCline: any
-	let mockAskApproval: Mock
-	let mockHandleError: Mock
-	let mockPushToolResult: Mock
-	let mockRemoveClosingTag: Mock
-	let mockToolDescription: Mock
-	let mockAskFinishSubTaskApproval: Mock
-
-	beforeEach(() => {
-		vi.clearAllMocks()
-
-		mockAskApproval = vi.fn().mockResolvedValue(true)
-		mockHandleError = vi.fn()
-		mockPushToolResult = vi.fn()
-		mockRemoveClosingTag = vi.fn((tag, content) => content)
-		mockToolDescription = vi.fn().mockReturnValue("attempt_completion")
-		mockAskFinishSubTaskApproval = vi.fn()
-
-		mockCline = {
-			say: vi.fn(),
-			ask: vi.fn().mockResolvedValue({ response: "yesButtonClicked", text: "", images: [] }),
-			clineMessages: [],
-			lastMessageTs: Date.now(),
-			consecutiveMistakeCount: 0,
-			sayAndCreateMissingParamError: vi.fn(),
-			recordToolError: vi.fn(),
-			emit: vi.fn(),
-			getTokenUsage: vi.fn().mockReturnValue({}),
-			toolUsage: {},
-			userMessageContent: [],
-			taskId: "test-task-id",
-			providerRef: {
-				deref: vi.fn().mockReturnValue({
-					getState: vi.fn().mockResolvedValue({
-						experiments: {},
-					}),
-				}),
-			},
-		}
-	})
-
-	describe("when experiment is disabled (default)", () => {
-		beforeEach(() => {
-			mockCline.providerRef.deref().getState.mockResolvedValue({
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: false,
-				},
-			})
-		})
-
-		it("should execute command when provided", async () => {
-			const mockExecuteCommand = executeCommand as Mock
-			mockExecuteCommand.mockResolvedValue([false, "Command executed successfully"])
-
-			// Mock clineMessages with a previous message that's not a command ask
-			mockCline.clineMessages = [{ say: "previous_message", text: "Previous message" }]
-
-			const block = {
-				params: {
-					result: "Task completed successfully",
-					command: "npm test",
-				},
-				partial: false,
-			}
-
-			await attemptCompletionTool(
-				mockCline,
-				block as any,
-				mockAskApproval,
-				mockHandleError,
-				mockPushToolResult,
-				mockRemoveClosingTag,
-				mockToolDescription,
-				mockAskFinishSubTaskApproval,
-			)
-
-			// When there's a lastMessage that's not a command ask, it should say completion_result first
-			expect(mockCline.say).toHaveBeenCalledWith(
-				"completion_result",
-				"Task completed successfully",
-				undefined,
-				false,
-			)
-			expect(mockCline.emit).toHaveBeenCalledWith(
-				"taskCompleted",
-				mockCline.taskId,
-				expect.any(Object),
-				expect.any(Object),
-			)
-			expect(mockAskApproval).toHaveBeenCalledWith("command", "npm test")
-			expect(mockExecuteCommand).toHaveBeenCalled()
-		})
-
-		it("should not execute command when user rejects", async () => {
-			mockAskApproval.mockResolvedValue(false)
-			const mockExecuteCommand = executeCommand as Mock
-
-			// Mock clineMessages with a previous message that's not a command ask
-			mockCline.clineMessages = [{ say: "previous_message", text: "Previous message" }]
-
-			const block = {
-				params: {
-					result: "Task completed successfully",
-					command: "npm test",
-				},
-				partial: false,
-			}
-
-			await attemptCompletionTool(
-				mockCline,
-				block as any,
-				mockAskApproval,
-				mockHandleError,
-				mockPushToolResult,
-				mockRemoveClosingTag,
-				mockToolDescription,
-				mockAskFinishSubTaskApproval,
-			)
-
-			// Should say completion_result and emit before asking for approval
-			expect(mockCline.say).toHaveBeenCalledWith(
-				"completion_result",
-				"Task completed successfully",
-				undefined,
-				false,
-			)
-			expect(mockCline.emit).toHaveBeenCalledWith(
-				"taskCompleted",
-				mockCline.taskId,
-				expect.any(Object),
-				expect.any(Object),
-			)
-			expect(mockAskApproval).toHaveBeenCalledWith("command", "npm test")
-			expect(mockExecuteCommand).not.toHaveBeenCalled()
-		})
-	})
-
-	describe("when experiment is enabled", () => {
-		beforeEach(() => {
-			mockCline.providerRef.deref().getState.mockResolvedValue({
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: true,
-				},
-			})
-		})
-
-		it("should NOT execute command even when provided", async () => {
-			const mockExecuteCommand = executeCommand as Mock
-
-			const block = {
-				params: {
-					result: "Task completed successfully",
-					command: "npm test",
-				},
-				partial: false,
-			}
-
-			await attemptCompletionTool(
-				mockCline,
-				block as any,
-				mockAskApproval,
-				mockHandleError,
-				mockPushToolResult,
-				mockRemoveClosingTag,
-				mockToolDescription,
-				mockAskFinishSubTaskApproval,
-			)
-
-			expect(mockCline.say).toHaveBeenCalledWith(
-				"completion_result",
-				"Task completed successfully",
-				undefined,
-				false,
-			)
-			expect(mockAskApproval).not.toHaveBeenCalled()
-			expect(mockExecuteCommand).not.toHaveBeenCalled()
-		})
-
-		it("should complete normally without command execution", async () => {
-			const block = {
-				params: {
-					result: "Task completed successfully",
-					command: "npm test",
-				},
-				partial: false,
-			}
-
-			await attemptCompletionTool(
-				mockCline,
-				block as any,
-				mockAskApproval,
-				mockHandleError,
-				mockPushToolResult,
-				mockRemoveClosingTag,
-				mockToolDescription,
-				mockAskFinishSubTaskApproval,
-			)
-
-			expect(mockCline.say).toHaveBeenCalledWith(
-				"completion_result",
-				"Task completed successfully",
-				undefined,
-				false,
-			)
-			expect(mockCline.emit).toHaveBeenCalledWith(
-				"taskCompleted",
-				mockCline.taskId,
-				expect.any(Object),
-				expect.any(Object),
-			)
-			expect(mockAskApproval).not.toHaveBeenCalled()
-		})
-	})
-
-	describe("when no command is provided", () => {
-		it("should work the same regardless of experiment state", async () => {
-			const block = {
-				params: {
-					result: "Task completed successfully",
-				},
-				partial: false,
-			}
-
-			// Test with experiment disabled
-			mockCline.providerRef.deref().getState.mockResolvedValue({
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: false,
-				},
-			})
-
-			await attemptCompletionTool(
-				mockCline,
-				block as any,
-				mockAskApproval,
-				mockHandleError,
-				mockPushToolResult,
-				mockRemoveClosingTag,
-				mockToolDescription,
-				mockAskFinishSubTaskApproval,
-			)
-
-			expect(mockCline.say).toHaveBeenCalledWith(
-				"completion_result",
-				"Task completed successfully",
-				undefined,
-				false,
-			)
-			expect(mockAskApproval).not.toHaveBeenCalled()
-
-			// Reset mocks
-			vi.clearAllMocks()
-
-			// Test with experiment enabled
-			mockCline.providerRef.deref().getState.mockResolvedValue({
-				experiments: {
-					[EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND]: true,
-				},
-			})
-
-			await attemptCompletionTool(
-				mockCline,
-				block as any,
-				mockAskApproval,
-				mockHandleError,
-				mockPushToolResult,
-				mockRemoveClosingTag,
-				mockToolDescription,
-				mockAskFinishSubTaskApproval,
-			)
-
-			expect(mockCline.say).toHaveBeenCalledWith(
-				"completion_result",
-				"Task completed successfully",
-				undefined,
-				false,
-			)
-			expect(mockAskApproval).not.toHaveBeenCalled()
-		})
-	})
-
-	describe("error handling", () => {
-		it("should handle missing result parameter", async () => {
-			const block = {
-				params: {},
-				partial: false,
-			}
-
-			await attemptCompletionTool(
-				mockCline,
-				block as any,
-				mockAskApproval,
-				mockHandleError,
-				mockPushToolResult,
-				mockRemoveClosingTag,
-				mockToolDescription,
-				mockAskFinishSubTaskApproval,
-			)
-
-			expect(mockCline.consecutiveMistakeCount).toBe(1)
-			expect(mockCline.recordToolError).toHaveBeenCalledWith("attempt_completion")
-			expect(mockCline.sayAndCreateMissingParamError).toHaveBeenCalledWith("attempt_completion", "result")
-		})
-
-		it("should handle state retrieval errors gracefully", async () => {
-			// Mock provider ref to return null
-			mockCline.providerRef.deref.mockReturnValue(null)
-
-			// Mock clineMessages to simulate no previous messages
-			mockCline.clineMessages = []
-
-			const block = {
-				params: {
-					result: "Task completed successfully",
-					command: "npm test",
-				},
-				partial: false,
-			}
-
-			await attemptCompletionTool(
-				mockCline,
-				block as any,
-				mockAskApproval,
-				mockHandleError,
-				mockPushToolResult,
-				mockRemoveClosingTag,
-				mockToolDescription,
-				mockAskFinishSubTaskApproval,
-			)
-
-			// When state retrieval fails, it defaults to not disabled (false), so it will try to execute command
-			// Since there's no lastMessage, it goes directly to askApproval
-			expect(mockAskApproval).toHaveBeenCalledWith("command", "npm test")
-			expect(mockCline.say).not.toHaveBeenCalled()
-		})
-	})
-})

src/core/tools/attemptCompletionTool.ts

@@ -14,8 +14,6 @@ import {
 	AskFinishSubTaskApproval,
 } from "../../shared/tools"
 import { formatResponse } from "../prompts/responses"
-import { type ExecuteCommandOptions, executeCommand } from "./executeCommandTool"
-import { EXPERIMENT_IDS, experiments, experimentDefault } from "../../shared/experiments"
 
 export async function attemptCompletionTool(
 	cline: Task,
@@ -67,48 +65,11 @@ export async function attemptCompletionTool(
 
 			cline.consecutiveMistakeCount = 0
 
-			let commandResult: ToolResponse | undefined
-
-			// Check if command execution is disabled via experiment
-			const state = await cline.providerRef.deref()?.getState()
-			const experimentsConfig = state?.experiments ?? experimentDefault
-			const isCommandDisabled = experiments.isEnabled(
-				experimentsConfig,
-				EXPERIMENT_IDS.DISABLE_COMPLETION_COMMAND,
-			)
-
-			if (command && !isCommandDisabled) {
-				if (lastMessage && lastMessage.ask !== "command") {
-					// Haven't sent a command message yet so first send completion_result then command.
-					await cline.say("completion_result", result, undefined, false)
-					TelemetryService.instance.captureTaskCompleted(cline.taskId)
-					cline.emit("taskCompleted", cline.taskId, cline.getTokenUsage(), cline.toolUsage)
-				}
-
-				// Complete command message.
-				const didApprove = await askApproval("command", command)
-
-				if (!didApprove) {
-					return
-				}
-
-				const executionId = cline.lastMessageTs?.toString() ?? Date.now().toString()
-				const options: ExecuteCommandOptions = { executionId, command }
-				const [userRejected, execCommandResult] = await executeCommand(cline, options)
-
-				if (userRejected) {
-					cline.didRejectTool = true
-					pushToolResult(execCommandResult)
-					return
-				}
-
-				// User didn't reject, but the command may have output.
-				commandResult = execCommandResult
-			} else {
-				await cline.say("completion_result", result, undefined, false)
-				TelemetryService.instance.captureTaskCompleted(cline.taskId)
-				cline.emit("taskCompleted", cline.taskId, cline.getTokenUsage(), cline.toolUsage)
-			}
+			// Command execution is permanently disabled in attempt_completion
+			// Users must use execute_command tool separately before attempt_completion
+			await cline.say("completion_result", result, undefined, false)
+			TelemetryService.instance.captureTaskCompleted(cline.taskId)
+			cline.emit("taskCompleted", cline.taskId, cline.getTokenUsage(), cline.toolUsage)
 
 			if (cline.parentTask) {
 				const didApprove = await askFinishSubTaskApproval()
@@ -138,14 +99,6 @@ export async function attemptCompletionTool(
 			await cline.say("user_feedback", text ?? "", images)
 			const toolResults: (Anthropic.TextBlockParam | Anthropic.ImageBlockParam)[] = []
 
-			if (commandResult) {
-				if (typeof commandResult === "string") {
-					toolResults.push({ type: "text", text: commandResult })
-				} else if (Array.isArray(commandResult)) {
-					toolResults.push(...commandResult)
-				}
-			}
-
 			toolResults.push({
 				type: "text",
 				text: `The user has provided feedback on the results. Consider their input to continue the task, and then attempt completion again.\n<feedback>\n${text}\n</feedback>`,

src/shared/__tests__/experiments.spec.ts

@@ -27,7 +27,6 @@ describe("experiments", () => {
 		it("returns false when POWER_STEERING experiment is not enabled", () => {
 			const experiments: Record<ExperimentId, boolean> = {
 				powerSteering: false,
-				disableCompletionCommand: false,
 				multiFileApplyDiff: false,
 			}
 			expect(Experiments.isEnabled(experiments, EXPERIMENT_IDS.POWER_STEERING)).toBe(false)
@@ -36,7 +35,6 @@ describe("experiments", () => {
 		it("returns true when experiment POWER_STEERING is enabled", () => {
 			const experiments: Record<ExperimentId, boolean> = {
 				powerSteering: true,
-				disableCompletionCommand: false,
 				multiFileApplyDiff: false,
 			}
 			expect(Experiments.isEnabled(experiments, EXPERIMENT_IDS.POWER_STEERING)).toBe(true)
@@ -45,7 +43,6 @@ describe("experiments", () => {
 		it("returns false when experiment is not present", () => {
 			const experiments: Record<ExperimentId, boolean> = {
 				powerSteering: false,
-				disableCompletionCommand: false,
 				multiFileApplyDiff: false,
 			}
 			expect(Experiments.isEnabled(experiments, EXPERIMENT_IDS.POWER_STEERING)).toBe(false)

src/shared/experiments.ts

@@ -2,7 +2,6 @@ import type { AssertEqual, Equals, Keys, Values, ExperimentId, Experiments } fro
 
 export const EXPERIMENT_IDS = {
 	MULTI_FILE_APPLY_DIFF: "multiFileApplyDiff",
-	DISABLE_COMPLETION_COMMAND: "disableCompletionCommand",
 	POWER_STEERING: "powerSteering",
 } as const satisfies Record<string, ExperimentId>
 
@@ -16,7 +15,6 @@ interface ExperimentConfig {
 
 export const experimentConfigsMap: Record<ExperimentKey, ExperimentConfig> = {
 	MULTI_FILE_APPLY_DIFF: { enabled: false },
-	DISABLE_COMPLETION_COMMAND: { enabled: false },
 	POWER_STEERING: { enabled: false },
 }
 

src/shared/tools.ts

@@ -144,7 +144,7 @@ export interface AskFollowupQuestionToolUse extends ToolUse {
 
 export interface AttemptCompletionToolUse extends ToolUse {
 	name: "attempt_completion"
-	params: Partial<Pick<Record<ToolParamName, string>, "result" | "command">>
+	params: Partial<Pick<Record<ToolParamName, string>, "result">>
 }
 
 export interface SwitchModeToolUse extends ToolUse {

webview-ui/src/i18n/locales/ca/settings.json

@@ -501,10 +501,6 @@
 			"name": "Habilitar Marketplace",
 			"description": "Quan està habilitat, pots instal·lar MCP i modes personalitzats del Marketplace."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Desactivar l'execució de comandes a attempt_completion",
-			"description": "Quan està activat, l'eina attempt_completion no executarà comandes. Aquesta és una característica experimental per preparar la futura eliminació de l'execució de comandes en la finalització de tasques."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Habilita edicions de fitxers concurrents",
 			"description": "Quan està activat, Roo pot editar múltiples fitxers en una sola petició. Quan està desactivat, Roo ha d'editar fitxers d'un en un. Desactivar això pot ajudar quan es treballa amb models menys capaços o quan vols més control sobre les modificacions de fitxers."

webview-ui/src/i18n/locales/de/settings.json

@@ -501,10 +501,7 @@
 			"name": "Marketplace aktivieren",
 			"description": "Wenn aktiviert, kannst du MCP und benutzerdefinierte Modi aus dem Marketplace installieren und verwalten."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Befehlsausführung in attempt_completion deaktivieren",
-			"description": "Wenn aktiviert, führt das Tool attempt_completion keine Befehle aus. Dies ist eine experimentelle Funktion, um die Abschaffung der Befehlsausführung bei Aufgabenabschluss vorzubereiten."
-		},
+
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Gleichzeitige Dateibearbeitungen aktivieren",
 			"description": "Wenn aktiviert, kann Roo mehrere Dateien in einer einzigen Anfrage bearbeiten. Wenn deaktiviert, muss Roo Dateien einzeln bearbeiten. Das Deaktivieren kann helfen, wenn du mit weniger fähigen Modellen arbeitest oder mehr Kontrolle über Dateiänderungen haben möchtest."

webview-ui/src/i18n/locales/en/settings.json

@@ -501,10 +501,6 @@
 			"name": "Enable Marketplace",
 			"description": "When enabled, you can install MCPs and custom modes from the Marketplace."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Disable command execution in attempt_completion",
-			"description": "When enabled, the attempt_completion tool will not execute commands. This is an experimental feature to prepare for deprecating command execution in task completion."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Enable concurrent file edits",
 			"description": "When enabled, Roo can edit multiple files in a single request. When disabled, Roo must edit files one at a time. Disabling this can help when working with less capable models or when you want more control over file modifications."

webview-ui/src/i18n/locales/es/settings.json

@@ -501,10 +501,6 @@
 			"name": "Habilitar Marketplace",
 			"description": "Cuando está habilitado, puedes instalar MCP y modos personalizados del Marketplace."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Desactivar la ejecución de comandos en attempt_completion",
-			"description": "Cuando está activado, la herramienta attempt_completion no ejecutará comandos. Esta es una función experimental para preparar la futura eliminación de la ejecución de comandos en la finalización de tareas."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Habilitar ediciones de archivos concurrentes",
 			"description": "Cuando está habilitado, Roo puede editar múltiples archivos en una sola solicitud. Cuando está deshabilitado, Roo debe editar archivos de uno en uno. Deshabilitar esto puede ayudar cuando trabajas con modelos menos capaces o cuando quieres más control sobre las modificaciones de archivos."

webview-ui/src/i18n/locales/fr/settings.json

@@ -501,10 +501,7 @@
 			"name": "Activer le Marketplace",
 			"description": "Lorsque cette option est activée, tu peux installer des MCP et des modes personnalisés depuis le Marketplace."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Désactiver l'exécution des commandes dans attempt_completion",
-			"description": "Lorsque cette option est activée, l'outil attempt_completion n'exécutera pas de commandes. Il s'agit d'une fonctionnalité expérimentale visant à préparer la dépréciation de l'exécution des commandes lors de la finalisation des tâches."
-		},
+
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Activer les éditions de fichiers concurrentes",
 			"description": "Lorsque cette option est activée, Roo peut éditer plusieurs fichiers en une seule requête. Lorsqu'elle est désactivée, Roo doit éditer les fichiers un par un. Désactiver cette option peut aider lorsque tu travailles avec des modèles moins capables ou lorsque tu veux plus de contrôle sur les modifications de fichiers."

webview-ui/src/i18n/locales/hi/settings.json

@@ -501,10 +501,6 @@
 			"name": "Marketplace सक्षम करें",
 			"description": "जब सक्षम होता है, तो आप Marketplace से MCP और कस्टम मोड इंस्टॉल कर सकते हैं।"
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "attempt_completion में कमांड निष्पादन अक्षम करें",
-			"description": "जब सक्षम किया जाता है, तो attempt_completion टूल कमांड निष्पादित नहीं करेगा। यह कार्य पूर्ण होने पर कमांड निष्पादन को पदावनत करने की तैयारी के लिए एक प्रयोगात्मक सुविधा है।"
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "समानांतर फ़ाइल संपादन सक्षम करें",
 			"description": "जब सक्षम किया जाता है, तो Roo एक ही अनुरोध में कई फ़ाइलों को संपादित कर सकता है। जब अक्षम किया जाता है, तो Roo को एक समय में एक फ़ाइल संपादित करनी होगी। इसे अक्षम करना तब मदद कर सकता है जब आप कम सक्षम मॉडल के साथ काम कर रहे हों या जब आप फ़ाइल संशोधनों पर अधिक नियंत्रण चाहते हों।"

webview-ui/src/i18n/locales/id/settings.json

@@ -530,10 +530,6 @@
 			"name": "Aktifkan Marketplace",
 			"description": "Ketika diaktifkan, kamu dapat menginstal MCP dan mode kustom dari Marketplace."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Nonaktifkan eksekusi perintah di attempt_completion",
-			"description": "Ketika diaktifkan, tool attempt_completion tidak akan mengeksekusi perintah. Ini adalah fitur eksperimental untuk mempersiapkan penghentian eksekusi perintah dalam penyelesaian tugas."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Aktifkan edit file bersamaan",
 			"description": "Ketika diaktifkan, Roo dapat mengedit beberapa file dalam satu permintaan. Ketika dinonaktifkan, Roo harus mengedit file satu per satu. Menonaktifkan ini dapat membantu saat bekerja dengan model yang kurang mampu atau ketika kamu ingin kontrol lebih terhadap modifikasi file."

webview-ui/src/i18n/locales/it/settings.json

@@ -501,10 +501,6 @@
 			"name": "Abilita Marketplace",
 			"description": "Quando abilitato, puoi installare MCP e modalità personalizzate dal Marketplace."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Disabilita l'esecuzione dei comandi in attempt_completion",
-			"description": "Se abilitato, lo strumento attempt_completion non eseguirà comandi. Questa è una funzionalità sperimentale per preparare la futura deprecazione dell'esecuzione dei comandi al completamento dell'attività."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Abilita modifiche di file concorrenti",
 			"description": "Quando abilitato, Roo può modificare più file in una singola richiesta. Quando disabilitato, Roo deve modificare i file uno alla volta. Disabilitare questa opzione può aiutare quando lavori con modelli meno capaci o quando vuoi più controllo sulle modifiche dei file."

webview-ui/src/i18n/locales/ja/settings.json

@@ -501,10 +501,6 @@
 			"name": "Marketplaceを有効にする",
 			"description": "有効にすると、MarketplaceからMCPとカスタムモードをインストールできます。"
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "attempt_completionでのコマンド実行を無効にする",
-			"description": "有効にすると、attempt_completionツールはコマンドを実行しません。これは、タスク完了時のコマンド実行の非推奨化に備えるための実験的な機能です。"
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "同時ファイル編集を有効にする",
 			"description": "有効にすると、Rooは単一のリクエストで複数のファイルを編集できます。無効にすると、Rooはファイルを一つずつ編集する必要があります。これを無効にすることで、能力の低いモデルで作業する場合や、ファイル変更をより細かく制御したい場合に役立ちます。"

webview-ui/src/i18n/locales/ko/settings.json

@@ -501,10 +501,6 @@
 			"name": "Marketplace 활성화",
 			"description": "활성화하면 Marketplace에서 MCP와 사용자 정의 모드를 설치할 수 있습니다."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "attempt_completion에서 명령 실행 비활성화",
-			"description": "활성화하면 attempt_completion 도구가 명령을 실행하지 않습니다. 이는 작업 완료 시 명령 실행을 더 이상 사용하지 않도록 준비하기 위한 실험적 기능입니다."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "동시 파일 편집 활성화",
 			"description": "활성화하면 Roo가 단일 요청으로 여러 파일을 편집할 수 있습니다. 비활성화하면 Roo는 파일을 하나씩 편집해야 합니다. 이 기능을 비활성화하면 덜 강력한 모델로 작업하거나 파일 수정에 대한 더 많은 제어가 필요할 때 도움이 됩니다."

webview-ui/src/i18n/locales/nl/settings.json

@@ -501,10 +501,6 @@
 			"name": "Marketplace inschakelen",
 			"description": "Wanneer ingeschakeld kun je MCP's en aangepaste modi uit de Marketplace installeren."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Commando-uitvoering in attempt_completion uitschakelen",
-			"description": "Indien ingeschakeld, zal de attempt_completion tool geen commando's uitvoeren. Dit is een experimentele functie ter voorbereiding op het afschaffen van commando-uitvoering bij taakvoltooiing."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Gelijktijdige bestandsbewerkingen inschakelen",
 			"description": "Wanneer ingeschakeld, kan Roo meerdere bestanden in één verzoek bewerken. Wanneer uitgeschakeld, moet Roo bestanden één voor één bewerken. Het uitschakelen hiervan kan helpen wanneer je werkt met minder capabele modellen of wanneer je meer controle wilt over bestandswijzigingen."

webview-ui/src/i18n/locales/pl/settings.json

@@ -497,10 +497,6 @@
 			"name": "Włącz jednoczesne odczytywanie plików",
 			"description": "Po włączeniu Roo może odczytać wiele plików w jednym żądaniu. Po wyłączeniu Roo musi odczytywać pliki pojedynczo. Wyłączenie może pomóc podczas pracy z mniej wydajnymi modelami lub gdy chcesz mieć większą kontrolę nad dostępem do plików."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Wyłącz wykonywanie poleceń w attempt_completion",
-			"description": "Gdy włączone, narzędzie attempt_completion nie będzie wykonywać poleceń. Jest to funkcja eksperymentalna przygotowująca do przyszłego wycofania wykonywania poleceń po zakończeniu zadania."
-		},
 		"MARKETPLACE": {
 			"name": "Włącz Marketplace",
 			"description": "Gdy włączone, możesz instalować MCP i niestandardowe tryby z Marketplace."

webview-ui/src/i18n/locales/pt-BR/settings.json

@@ -497,10 +497,6 @@
 			"name": "Habilitar leitura simultânea de arquivos",
 			"description": "Quando habilitado, o Roo pode ler vários arquivos em uma única solicitação. Quando desabilitado, o Roo deve ler arquivos um de cada vez. Desabilitar pode ajudar ao trabalhar com modelos menos capazes ou quando você deseja mais controle sobre o acesso aos arquivos."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Desativar execução de comando em attempt_completion",
-			"description": "Quando ativado, a ferramenta attempt_completion não executará comandos. Este é um recurso experimental para preparar a futura descontinuação da execução de comandos na conclusão da tarefa."
-		},
 		"MARKETPLACE": {
 			"name": "Ativar Marketplace",
 			"description": "Quando ativado, você pode instalar MCPs e modos personalizados do Marketplace."

webview-ui/src/i18n/locales/ru/settings.json

@@ -497,10 +497,6 @@
 			"name": "Включить одновременное чтение файлов",
 			"description": "При включении Roo может читать несколько файлов в одном запросе. При отключении Roo должен читать файлы по одному. Отключение может помочь при работе с менее производительными моделями или когда вы хотите больше контроля над доступом к файлам."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Отключить выполнение команд в attempt_completion",
-			"description": "Если включено, инструмент attempt_completion не будет выполнять команды. Это экспериментальная функция для подготовки к будущему прекращению поддержки выполнения команд при завершении задачи."
-		},
 		"MARKETPLACE": {
 			"name": "Включить Marketplace",
 			"description": "Когда включено, вы можете устанавливать MCP и пользовательские режимы из Marketplace."

webview-ui/src/i18n/locales/tr/settings.json

@@ -501,10 +501,6 @@
 			"name": "Marketplace'i Etkinleştir",
 			"description": "Etkinleştirildiğinde, Marketplace'ten MCP'leri ve özel modları yükleyebilirsiniz."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "attempt_completion'da komut yürütmeyi devre dışı bırak",
-			"description": "Etkinleştirildiğinde, attempt_completion aracı komutları yürütmez. Bu, görev tamamlandığında komut yürütmenin kullanımdan kaldırılmasına hazırlanmak için deneysel bir özelliktir."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Eşzamanlı dosya düzenlemelerini etkinleştir",
 			"description": "Etkinleştirildiğinde, Roo tek bir istekte birden fazla dosyayı düzenleyebilir. Devre dışı bırakıldığında, Roo dosyaları tek tek düzenlemek zorundadır. Bunu devre dışı bırakmak, daha az yetenekli modellerle çalışırken veya dosya değişiklikleri üzerinde daha fazla kontrol istediğinde yardımcı olabilir."

webview-ui/src/i18n/locales/vi/settings.json

@@ -501,10 +501,6 @@
 			"name": "Bật Marketplace",
 			"description": "Khi được bật, bạn có thể cài đặt MCP và chế độ tùy chỉnh từ Marketplace."
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "Tắt thực thi lệnh trong attempt_completion",
-			"description": "Khi được bật, công cụ attempt_completion sẽ không thực thi lệnh. Đây là một tính năng thử nghiệm để chuẩn bị cho việc ngừng hỗ trợ thực thi lệnh khi hoàn thành tác vụ trong tương lai."
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "Bật chỉnh sửa tệp đồng thời",
 			"description": "Khi được bật, Roo có thể chỉnh sửa nhiều tệp trong một yêu cầu duy nhất. Khi bị tắt, Roo phải chỉnh sửa từng tệp một. Tắt tính năng này có thể hữu ích khi làm việc với các mô hình kém khả năng hơn hoặc khi bạn muốn kiểm soát nhiều hơn đối với các thay đổi tệp."

webview-ui/src/i18n/locales/zh-CN/settings.json

@@ -501,10 +501,6 @@
 			"name": "启用 Marketplace",
 			"description": "启用后，你可以从 Marketplace 安装 MCP 和自定义模式。"
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "禁用 attempt_completion 中的命令执行",
-			"description": "启用后，attempt_completion 工具将不会执行命令。这是一项实验性功能，旨在为将来弃用任务完成时的命令执行做准备。"
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "启用并发文件编辑",
 			"description": "启用后 Roo 可在单个请求中编辑多个文件。禁用后 Roo 必须逐个编辑文件。禁用此功能有助于使用能力较弱的模型或需要更精确控制文件修改时。"

webview-ui/src/i18n/locales/zh-TW/settings.json

@@ -501,10 +501,6 @@
 			"name": "啟用 Marketplace",
 			"description": "啟用後，您可以從 Marketplace 安裝 MCP 和自訂模式。"
 		},
-		"DISABLE_COMPLETION_COMMAND": {
-			"name": "停用 attempt_completion 中的指令執行",
-			"description": "啟用後，attempt_completion 工具將不會執行指令。這是一項實驗性功能，旨在為未來停用工作完成時的指令執行做準備。"
-		},
 		"MULTI_FILE_APPLY_DIFF": {
 			"name": "啟用並行檔案編輯",
 			"description": "啟用後 Roo 可在單個請求中編輯多個檔案。停用後 Roo 必須逐個編輯檔案。停用此功能有助於使用能力較弱的模型或需要更精確控制檔案修改時。"