[Bug] Shell tool captures PowerShell cmdlet output but silently drops native executable stdout (python.exe, hostname.exe)

[ty2328]

TITLE:

service.py
Windows_MCP_Shell_Bug_Report.md

MCP_CAPABILITY_AUDIT.md

Description

The Shell tool's execute_command method in desktop/service.py correctly captures output from PowerShell cmdlets (Write-Host, Get-ChildItem, Select-String, etc.) but silently drops stdout from all native executables. Commands execute successfully (exit code 0, side effects like file creation occur), but the returned output string is empty.

Environment

• Windows 11, US English locale, UTF-8 codepage (65001)
• Python 3.13.12 at C:\Program Files\Python313\python.exe
• PowerShell 7.5.4 (after manually changing line 146 from 'powershell' to 'pwsh')
• Windows-MCP v0.6.2 installed via Claude Desktop Extensions
• Claude Desktop (current as of March 7, 2026)

Related issue: Shell hardcodes powershell (PS5.1)

Line 146 of desktop/service.py uses 'powershell' which resolves to Windows PowerShell 5.1, not PowerShell 7. We manually changed this to 'pwsh' to get PS7. Suggestion: detect and prefer pwsh when available, or make the shell executable configurable via env var.

Reproduction

Using Claude Desktop with the Windows-MCP extension:

Works (PowerShell cmdlet):

Write-Host "hello"
→ Returns: "hello"

Fails (native executable — Python):

& "C:\Program Files\Python313\python.exe" -c "print('hello')"
→ Returns: "" (empty, exit code 0)

Fails (native executable — hostname.exe):

& "C:\Windows\System32\hostname.exe"
→ Returns: "" (empty, exit code 0)

Root Cause Analysis

The execute_command method (lines 142-162) does:

result = subprocess.run(
    ['pwsh', '-NoProfile', '-EncodedCommand', encoded],
    capture_output=True,
    timeout=timeout,
    cwd=os.path.expanduser(path='~')
)
stdout = result.stdout

subprocess.run(capture_output=True) sets stdout=PIPE. When pwsh runs a cmdlet, the output flows through PowerShell's output stream into the pipe. When pwsh invokes a native executable (python.exe, hostname.exe), the child process's stdout apparently does not flow back through the pipe to the parent Python process.

This is NOT an encoding issue — the machine's default encoding is UTF-8 (codepage 65001). We tested setting $OutputEncoding, [Console]::OutputEncoding, $env:PYTHONUTF8, and all combinations. None resolved it.

Encoding attempts (all failed)

• $OutputEncoding = [System.Text.Encoding]::UTF8 → still empty
• $env:PYTHONUTF8 = "1" → still empty
• [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 → still empty
• All three combined → still empty

Workaround

Native executables can write output to a file, and a separate Shell call can read the file:

# Call 1:
Set-Content C:\temp\task.py -Value "open(r'C:\temp\result.txt','w').write('hello')"
& "C:\Program Files\Python313\python.exe" C:\temp\task.py

# Call 2 (separate MCP invocation):
Write-Host ([System.IO.File]::ReadAllText("C:\temp\result.txt"))
# → Returns: "hello"

Both steps cannot be in the same call — the Read races ahead of Python finishing.

Suggested Fix

Possible avenues to investigate:

• Add explicit encoding='utf-8' and errors='replace' to the subprocess.run call
• Test whether -Command (instead of -EncodedCommand) handles native exe output differently
• Set [Console]::OutputEncoding inside the encoded command before running native executables
• Consider using subprocess.PIPE explicitly and reading stdout after process completion
• Make the shell executable (powershell vs pwsh) configurable via environment variable

Impact

This blocks all Python, Quarto, and native executable integration through the Shell tool, requiring users to manually run scripts in a separate terminal and paste output back to Claude.