[BUG] PowerShell cmdlets fail when Inline Terminal is ON — execa uses cmd.exe instead of user shell #705
Description
A Note from the User
This is a message from me, a human user. I asked AI to handle the rest of the issue report.
I tried to patch the problems I encountered while using Zoo Code myself. The patches may be incomplete or may not work correctly. Please, the bug fix team, judge them directly. I hope Zoo Code continues to grow and mature.
Problem
When "Use Inline Terminal (recommended)" setting is ON, PowerShell cmdlets like Test-Path, Get-ChildItem return 'Test-Path' is not recognized as an internal or external command. The inline terminal uses execa backend which defaults to cmd.exe on Windows, ignoring the user's shell preference.
Context
- OS: Windows 11, PowerShell 5.1
- Zoo Code Version: v3.63.100188
- Model: mimo-v2.5-pro
- Setting: "Use Inline Terminal (recommended)" = ON
Reproduction Steps
- Zoo Code Settings → Terminal → "Use Inline Terminal (recommended)" ON
- Execute
Test-Path "README.md"viaexecute_command - Runs in cmd.exe, PowerShell cmdlet fails
Expected Result
Test-Path "README.md" should return True.
Actual Result
'Test-Path' is not recognized as an internal or external command, operable program or batch file.
Root Cause
From Zoo Code documentation:
ON (Use Inline Terminal): Runs commands with the Inline Terminal (in chat), bypassing shell profiles and VS Code shell integration. Mechanism: uses a background "execa" provider and streams output directly.
When Inline Terminal is ON:
- Does NOT use VS Code's PowerShell terminal
- Creates background process via Node.js
execalibrary - execa uses cmd.exe by default on Windows
The jJe (execaTerminal) class in extension.js does not respect the user's shell settings when calling execa.
Applied Patch
We resolved this by turning off Inline Terminal and adding a PowerShell shellPath fallback in the Pn constructor (v6 patch):
// When getProfileShell() returns undefined in Pn constructor
let explicitShell = process.platform === "win32"
? (process.env.SystemRoot || "C:\\Windows") + "\\System32\\WindowsPowerShell\\v1.0\\powershell.exe"
: (process.env.SHELL || "/bin/bash");
n.shellPath = explicitShell;Recommended Official Fix
Option 1: Respect user shell settings in execa backend:
// In jJe (execaTerminal) class
const shellPath = process.platform === "win32"
? (Pn.getProfileShell()?.shellPath || process.env.ComSpec || "cmd.exe")
: (process.env.SHELL || "/bin/bash");Option 2: Add shell option for inline terminal in settings:
{
"roo-cline.inlineTerminal.shell": "powershell"
}Option 3: Change default to Inline Terminal OFF (currently ON by default)
Activity
myk1yt commentedon Jun 24, 2026
[RESOLVED] Inline Terminal uses cmd.exe instead of PowerShell on Windows
Problem
When "Use Inline Terminal (recommended)" is ON, PowerShell cmdlets like
Test-Path,Get-ChildItemfail with'Test-Path' is not recognized as an internal or external command. The Inline Terminal uses theexecalibrary which defaults tocmd.exeon Windows, ignoring the user's shell preference set in VS Code settings.Root Cause
In
extension.jsat the execa call site (byte offset ~14,556,931), the shell resolution logic was:getExecaShellPath()returnsundefinedby default, soundefined || truetells execa to use the system default shell, which isComSpec=cmd.exeon Windows. This bypasses VS Code'sterminal.integrated.defaultProfile.windowssetting entirely.Fix Applied
Replaced the shell fallback with platform-aware logic using PATH-based resolution:
This makes the Inline Terminal use PowerShell 5.1 on Windows (always available in system PATH at
C:\Windows\System32\WindowsPowerShell\v1.0\). macOS/Linux behavior is unchanged (!0=true= system default).Why PATH-based instead of absolute path
powershell.exeis always in the Windows system PATH, so execa resolves it correctly without needing the full absolute pathC:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe. This is simpler and works on all Windows installations regardless of system drive letter.Verification
echo $PSVersionTable.PSVersionin Inline Terminal now outputs the PowerShell version number (previously printed as literal string in cmd.exe)Test-Path,Get-ChildItem, etc.) work correctly--checksyntax validation passedLimitation
This is a local patch to compiled
extension.js. It will be overwritten on extension updates and needs re-application. A permanent fix would require adding aroo-cline.inlineTerminal.shellconfiguration option in the extension'spackage.json.fix(terminal): retry with execa when shell integration loses command
fix(terminal): retry with execa when shell integration loses command
fix(terminal): retry with execa when shell integration loses command
fix(terminal): retry with execa when shell integration loses command
fix(terminal): retry with execa when shell integration loses command
DennisFederico commentedon Aug 21, 2026
Strange as it may, after hours of doing different tests using both Rider and VSCode... I created a user variable for ComSpec pointing to powershell.exe, it seems that the underlying library uses %COMSPEC% to run the command... that worked for me.
That should not be the solution, but I cannot think of any process or tool in my system (nowadays) that would use cmd.exe... just In case I left the system default value intact
This makes me think that in fact the underlying runner library or mechanism is somehow wrong, it should use the VSCode/Rider terminal "Id", as passed to the model/provider and not default configured in the OS