MediaMetz/gemini-cli
1
0
Fork 0
mirror of https://github.com/google-gemini/gemini-cli.git synced 2026-04-27 13:34:15 -07:00
Code Issues Packages Projects Releases Wiki Activity

feat(core): deduplicate subprocess protocol in tool descriptions

Browse Source
This commit is contained in:
Aishanee Shah
2026-02-16 16:49:01 +00:00
parent ce84b3cb5f
commit 4428c83be4
6 changed files with 194 additions and 69 deletions
Download Patch File Download Diff File Expand all files Collapse all files
packages/core/src/core/__snapshots__/prompts.test.ts.snap
+143
View File
@@ -631,6 +631,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -769,6 +780,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -890,6 +912,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -1510,6 +1543,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -1648,6 +1692,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -1790,6 +1845,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -2070,6 +2136,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -2207,6 +2284,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -2345,6 +2433,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -2722,6 +2821,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -2860,6 +2970,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -3109,6 +3230,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
@@ -3247,6 +3379,17 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
- **Tools vs. Text:** Use tools for actions, text output *only* for communication. Do not add explanatory comments within tool calls.
- **Handling Inability:** If unable/unwilling to fulfill a request, state so briefly without excessive justification. Offer alternatives if appropriate.
## Standard Subprocess Protocol
For any tool that executes a subprocess (including shell commands and project-specific discovered tools), the following information is returned:
- **Output:** The combined content of stdout and stderr. Can be \`(empty)\` or partial on error or for unwaited background processes.
- **Exit Code:** The numeric exit code of the process. Only included if non-zero (indicating failure).
- **Error:** A descriptive message if a process-level error occurred (e.g., command not found).
- **Signal:** The name or number of the signal that terminated the process (if applicable).
- **Background PIDs:** A list of PIDs for any background processes started by the command.
- **Process Group PGID:** The process group ID, which can be used to terminate the process group if needed.
## Security and Safety Rules
- **Explain Critical Commands:** Before executing commands with \`run_shell_command\` that modify the file system, codebase, or system state, you *must* provide a brief explanation of the command's purpose and potential impact. Prioritize user understanding and safety. You should not ask permission to use the tool; the user will be presented with a confirmation dialogue upon use (you do not need to tell them this).
- **Security First:** Always apply security best practices. Never introduce code that exposes, logs, or commits secrets, API keys, or other sensitive information.
packages/core/src/tools/__snapshots__/shell.test.ts.snap
+7 -35
View File
@@ -1,20 +1,13 @@
// Vitest Snapshot v1, https://vitest.dev/guide/snapshot.html
exports[`ShellTool > getDescription > should return the non-windows description when not on windows 1`] = `
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
Exit Code: Only included if non-zero (command failed).
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available."
The following information is returned: [Protocol: Subprocess]"
`;
exports[`ShellTool > getDescription > should return the windows description when on windows 1`] = `
@@ -24,46 +17,25 @@ exports[`ShellTool > getDescription > should return the windows description when
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
Exit Code: Only included if non-zero (command failed).
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available."
The following information is returned: [Protocol: Subprocess]"
`;
exports[`ShellTool > getSchema > should return the base schema when no modelId is provided 1`] = `
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
Exit Code: Only included if non-zero (command failed).
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available."
The following information is returned: [Protocol: Subprocess]"
`;
exports[`ShellTool > getSchema > should return the schema from the resolver when modelId is provided 1`] = `
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
"This tool executes a given shell command as \`bash -c <command>\`. Command can start background processes using \`&\`.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
Exit Code: Only included if non-zero (command failed).
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available."
The following information is returned: [Protocol: Subprocess]"
`;
packages/core/src/tools/definitions/__snapshots__/coreToolsModelSnapshots.test.ts.snap
+4 -18
View File
@@ -568,20 +568,13 @@ A good instruction should concisely answer:
exports[`coreTools snapshots for specific models > Model: gemini-2.5-pro > snapshot for tool: run_shell_command 1`] = `
{
"description": "This tool executes a given shell command as \`bash -c <command>\`. To run a command in the background, set the \`is_background\` parameter to true. Do NOT use \`&\` to background commands. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
"description": "This tool executes a given shell command as \`bash -c <command>\`. To run a command in the background, set the \`is_background\` parameter to true. Do NOT use \`&\` to background commands.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
Exit Code: Only included if non-zero (command failed).
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available.",
The following information is returned: [Protocol: Subprocess]",
"name": "run_shell_command",
"parametersJsonSchema": {
"properties": {
@@ -1357,20 +1350,13 @@ A good instruction should concisely answer:
exports[`coreTools snapshots for specific models > Model: gemini-3-pro-preview > snapshot for tool: run_shell_command 1`] = `
{
"description": "This tool executes a given shell command as \`bash -c <command>\`. To run a command in the background, set the \`is_background\` parameter to true. Do NOT use \`&\` to background commands. Command is executed as a subprocess that leads its own process group. Command process group can be terminated as \`kill -- -PGID\` or signaled as \`kill -s SIGNAL -- -PGID\`.
"description": "This tool executes a given shell command as \`bash -c <command>\`. To run a command in the background, set the \`is_background\` parameter to true. Do NOT use \`&\` to background commands.
Efficiency Guidelines:
- Quiet Flags: Always prefer silent or quiet flags (e.g., \`npm install --silent\`, \`git --no-pager\`) to reduce output volume while still capturing necessary information.
- Pagination: Always disable terminal pagination to ensure commands terminate (e.g., use \`git --no-pager\`, \`systemctl --no-pager\`, or set \`PAGER=cat\`).
The following information is returned:
Output: Combined stdout/stderr. Can be \`(empty)\` or partial on error and for any unwaited background processes.
Exit Code: Only included if non-zero (command failed).
Error: Only included if a process-level error occurred (e.g., spawn failure).
Signal: Only included if process was terminated by a signal.
Background PIDs: Only included if background processes were started.
Process Group PGID: Only included if available.",
The following information is returned: [Protocol: Subprocess]",
"name": "run_shell_command",
"parametersJsonSchema": {
"properties": {
packages/core/src/tools/tool-registry.test.ts
+1 -1
View File
@@ -550,7 +550,7 @@ describe('ToolRegistry', () => {
expect(result.error?.type).toBe(
ToolErrorType.DISCOVERED_TOOL_EXECUTION_ERROR,
);
expect(result.llmContent).toContain('Stderr: Something went wrong');
expect(result.llmContent).toContain('Output: Something went wrong');
expect(result.llmContent).toContain('Exit Code: 1');
});
packages/core/src/tools/tool-registry.ts
+14 -14
View File
@@ -103,13 +103,19 @@ class DiscoveredToolInvocation extends BaseToolInvocation<
// if there is any error, non-zero exit code, signal, or stderr, return error details instead of stdout
if (error || code !== 0 || signal || stderr) {
const llmContent = [
`Stdout: ${stdout || '(empty)'}`,
`Stderr: ${stderr || '(empty)'}`,
`Error: ${error ?? '(none)'}`,
`Exit Code: ${code ?? '(none)'}`,
`Signal: ${signal ?? '(none)'}`,
].join('\n');
const llmContentParts = [
`Output: ${(stdout + stderr).trim() || '(empty)'}`,
];
if (error) {
llmContentParts.push(`Error: ${error}`);
}
if (code !== null && code !== 0) {
llmContentParts.push(`Exit Code: ${code}`);
}
if (signal) {
llmContentParts.push(`Signal: ${signal}`);
}
const llmContent = llmContentParts.join('\n');
return {
llmContent,
returnDisplay: llmContent,
@@ -153,13 +159,7 @@ Tool discovery and call commands can be configured in project or user settings.
When called, the tool call command is executed as a subprocess.
On success, tool output is returned as a json string.
Otherwise, the following information is returned:
Stdout: Output on stdout stream. Can be \`(empty)\` or partial.
Stderr: Output on stderr stream. Can be \`(empty)\` or partial.
Error: Error or \`(none)\` if no error was reported for the subprocess.
Exit Code: Exit code or \`(none)\` if terminated by signal.
Signal: Signal number or \`(none)\` if no signal was received.
Otherwise, the following information is returned: [Protocol: Subprocess]
`;
super(
prefixedName,