claude-code - 💡(How to fix) Fix [BUG] PowerShell tool fails Exit 1, empty stdout/stderr on Windows 10 DE-locale (v2.1.142, all environmental causes ruled out)

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

The PowerShell tool returns exit 1 with completely empty stdout/stderr for every command ('test', 42, Write-Output 'test', $PSVersionTable.PSVersion, etc.). No error string is emitted anywhere.

pwsh.exe itself works correctly when invoked via the Bash tool, so the failure is in the harness PowerShell-tool wrapper, not in PowerShell. The Bash tool is fully functional throughout.

The bug persists through: App restart, PC reboot, Windows Settings Reset, complete uninstall + reinstall (which upgraded Claude Code from 2.1.138 to 2.1.142), cleanup of all persistent caches outside the UWP container, and dangerouslyDisableSandbox: true. Reproducible in a brand-new project on the very first invocation.

Possibly related to #55727 (Japanese locale CP932, v2.1.124–126) - my case is Windows 10 with German DE-locale (CP850 OEM codepage) on v2.1.142.

What Should Happen?

The PowerShell tool should execute the given command via pwsh.exe and return its stdout/stderr with the correct exit code, equivalent to the result of running the same command directly via pwsh -NoProfile -Command "<command>".

For example, the command 'test' should return test on stdout with exit code 0 — which is what pwsh.exe directly via the Bash tool already does correctly.

Error Messages/Logs

No error messages are emitted — this is part of the bug. Both stdout and stderr from the `PowerShell` tool are completely empty, regardless of the command or whether `dangerouslyDisableSandbox: true` is passed.

The Claude Desktop main log (`%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log`) contains only permission-request entries for the PowerShell tool calls but no subprocess-spawn errors or stderr capture. No relevant entries in `claude.ai-web.log`, `cowork_vm_node.log`, or `ssh.log` either.

Steps to Reproduce

1. Open Claude Desktop App on Windows 10 (German locale).
2. Switch to the Code tab.
3. Create a new project (any directory - bug is not project-specific).
4. Start a new Code session in that project.
5. As the first action, ask Claude: "Run PowerShell with the command 'test'".
6. Observe: the PowerShell tool invocation returns exit 1 with empty stdout/stderr.
7. (Optional) Ask Claude to retry with dangerouslyDisableSandbox: true - same result.
8. (Verification) Ask Claude to invoke pwsh -NoProfile -Command "'test'" via the Bash tool instead - this returns test correctly.

The bug reproduces on the very first PowerShell invocation in any fresh session, in any project, immediately after a clean install.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.138

Claude Code Version

2.1.142

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Regression note

The "Last Working Version" field shows 2.1.138 because that's the version where the PowerShell tool was last observed working (prior to 2026-05-14). However, the bug currently also reproduces on 2.1.138 and persists on the upgrade to 2.1.142 — so this is not a straightforward release-induced regression.

First observation of the broken state coincided with an environmental change: I temporarily moved %USERPROFILE%\.claude\ to OneDrive and replaced the original with a symbolic link, then reverted both changes a short time later (symlink removed, directory restored to its original location). The PowerShell tool has been broken in every session since then.

Whether the symlink experiment actually caused the bug is unclear, because:

• The change was fully reverted before testing showed the failure
• The bug persisted through complete uninstall + fresh install (so it is not held in app binaries or the UWP container)
• The bug persisted through deletion of every persistent file I could find outside the UWP container (%USERPROFILE%\.claude\session-env\*, \sessions\*, \telemetry\*, \shell-snapshots\*, %LOCALAPPDATA%\Claude\, %LOCALAPPDATA%\Temp\claude\, HKCU\Software\Classes\claude)

So either the symlink event triggered durable state in a location I have not yet identified, or it merely coincided with first observation and the real cause is something else (e.g., a Win10-specific code path that only matters when certain conditions are met). Either way: the bug exists right now on a fully clean install, reproduces in any new project on the first PowerShell call, and the listed cleanup steps do not undo it.

Environment details

• Claude Desktop App: 1.7196.1.0 (installed via direct download from https://claude.ai/downloads — Claude is not currently listed in the Microsoft Store for me)
• Embedded Claude Code: 2.1.142
• Windows 10 with Extended Security Updates (ESU)
• Locale: de-DE
• Console codepage: CP850 (OEM)

What did NOT fix the bug (each verified independently)

1. Restart Claude Desktop App
2. Open multiple new Code sessions
3. Full PC reboot
4. Windows Settings reset (Apps → Installed apps → Claude → Advanced options → Reset)
5. Complete uninstall via Windows Settings → reboot → fresh install from https://claude.ai/downloads (this upgraded Claude Desktop from 1.7196.0.0 → 1.7196.1.0 and embedded Claude Code from 2.1.138 → 2.1.142)
6. Test in a brand-new project with a brand-new session
7. Cleanup of all persistent caches outside the UWP container:
   • %USERPROFILE%\.claude\session-env\*
   • %USERPROFILE%\.claude\sessions\*
   • %USERPROFILE%\.claude\telemetry\*
   • %USERPROFILE%\.claude\shell-snapshots\*
   • %LOCALAPPDATA%\Claude\
   • %LOCALAPPDATA%\Temp\claude\
   • HKCU\Software\Classes\claude (URL handler)
8. Retest with dangerouslyDisableSandbox: true

Workaround

Invoke pwsh.exe via the Bash tool:

pwsh -NoProfile -Command "<powershell-code>"

Possible relationship to #55727

That issue reports the same symptom class (exit 1, empty/garbled output) on Japanese locale (CP932) and v2.1.124–126. My case differs in three ways:

• CP850 (German OEM) vs CP932 (Japanese OEM). Both are legacy OEM/console codepages — the layer where CreateProcess argument encoding tends to break.
• Claude Code v2.1.142 — 18+ versions newer than the originally reported range.
• Windows 10 with ESU. The original report did not specify a Windows version.

This may be the same bug class affecting all non-UTF-8 OEM-locale Windows installations, with Windows 10 possibly more exposed due to reduced CI coverage post-EOL.

Request

Harness-side verbose logging for the PowerShell-tool wrapper would help diagnose this — currently no subprocess error string is emitted anywhere I can find.