What happened?
When using the run_shell_command tool, the Gemini CLI fails to correctly encapsulate the command string argument before passing it
to the underlying shell (PowerShell). This results in frequent syntax errors such as Unterminated string literal, Missing argument
in parameter list, or ParserError.
Specifically, if a command contains nested quotes (e.g., npx tsx -e "console.log('test')"), the CLI's internal transport mechanism
appears to mis-parse the boundaries of the string. This forces the agent into a "Script Sprawl" anti-pattern: instead of executing
a simple one-liner, the agent must:
- Write the logic to a temporary .ts or .ps1 file using write_file.
- Execute that file using run_shell_command.
- Delete the temporary file.
This workaround is inefficient, increases token consumption, and clutters the project directory with "junk" artifacts.
What did you expect to happen?
I expected the command string provided to the tool to be passed to the host shell verbatim or with robust escaping (e.g., using an
internal buffer or Base64 encoding the payload) so that complex one-liners containing quotes, backticks, semicolons, and
parentheses execute successfully without being truncated or misinterpreted by the CLI bridge.
Client information
- CLI Version: 0.26.0
- Git Commit: a380b42
- Session ID: aacea196-85b5-421f-bdd2-fa5d2c7efedc
- Operating System: win32 v24.11.0
- Sandbox Environment: no sandbox
- Model Version: gemini-3-flash-preview
- Memory Usage: 1.20 GB
- Terminal Name: Unknown
- Terminal Background: #0c0c0c
- Kitty Keyboard Protocol: Unsupported
Login information
- Logged in via Gemini CLI / Google Account.
Anything else we need to know?
This issue is particularly severe on the win32 platform where PowerShell's quoting rules are already complex. The CLI's additional
layer of parsing makes it nearly impossible to execute any command involving:
- Node.js "eval" flags (-e).
- PowerShell variable expansion ($var).
- Complex piping with Select-String or Get-Content.
- Multi-line strings passed as arguments.
This failure mode is a primary driver of agent "paralysis," where the agent repeatedly tries to fix a command string only to have
it fail again due to the same parsing bug (the "Definition of Insanity" loop).
What happened?
When using the run_shell_command tool, the Gemini CLI fails to correctly encapsulate the command string argument before passing it
to the underlying shell (PowerShell). This results in frequent syntax errors such as Unterminated string literal, Missing argument
in parameter list, or ParserError.
Specifically, if a command contains nested quotes (e.g., npx tsx -e "console.log('test')"), the CLI's internal transport mechanism
appears to mis-parse the boundaries of the string. This forces the agent into a "Script Sprawl" anti-pattern: instead of executing
a simple one-liner, the agent must:
This workaround is inefficient, increases token consumption, and clutters the project directory with "junk" artifacts.
What did you expect to happen?
I expected the command string provided to the tool to be passed to the host shell verbatim or with robust escaping (e.g., using an
internal buffer or Base64 encoding the payload) so that complex one-liners containing quotes, backticks, semicolons, and
parentheses execute successfully without being truncated or misinterpreted by the CLI bridge.
Client information
Login information
Anything else we need to know?
This issue is particularly severe on the win32 platform where PowerShell's quoting rules are already complex. The CLI's additional
layer of parsing makes it nearly impossible to execute any command involving:
This failure mode is a primary driver of agent "paralysis," where the agent repeatedly tries to fix a command string only to have
it fail again due to the same parsing bug (the "Definition of Insanity" loop).