Feature request: configurable PowerShell tool shell initialization for Windows encoding

Resolved 💬 3 comments Opened May 27, 2026 by dmajima Closed Jun 27, 2026

Summary

On Windows, the PowerShell tool spawns pwsh.exe using a hardcoded full path ("C:\Program Files\PowerShell\7\pwsh.exe" -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command "..."). Because -NoProfile is used, [Console]::OutputEncoding defaults to the system's non-UTF-8 encoding (e.g., CP1250 or CP932), causing Japanese (and likely other non-ASCII) text to be garbled — especially during parallel agent execution via the Agent tool.

Problem

When multiple agents run in parallel (e.g., via Agent() with multiple concurrent calls), the main console output shows mojibake like:

â—ă¬ă"ăĄăĽçµćžśă«ĺźşăĄăŤă€ćڇć'ă•れăźĺ•ŹéˇŚă‚'修正ă—ăľă™ă€

The garbling occurs only while parallel agents are running and resolves when they complete.

Root cause

  1. Claude Code spawns pwsh.exe with the full absolute path, bypassing PATH resolution
  2. Each pwsh -NoProfile process initializes [Console]::OutputEncoding from the system's default code page (not UTF-8)
  3. The per-command encoding prefix (chcp 65001; [Console]::OutputEncoding = UTF8; ...) fixes encoding within each command, but during parallel execution, there appears to be a timing window or relay issue where garbled bytes reach the main console

What we tried (and why each failed)

| Approach | Result |
|----------|--------|
| Windows UTF-8 system locale (Beta: Unicode UTF-8) | Fixed encoding but broke Excel VBA macros and other legacy apps that depend on CP932 (Shift-JIS) |
| OEMCP-only registry change (OEMCP=65001, ACP=932) | Caused system instability; had to roll back |
| PATH wrapper (pwsh.cmd in a prioritized PATH directory) | Ineffective — Claude Code uses the full path to pwsh.exe, not PATH resolution |
| HKCU\Console\CodePage registry | Only affects interactive console windows, not piped subprocesses |
| PreToolUse hook | Can only provide additionalContext (reminders), cannot modify the actual command or shell initialization |
| Mandatory per-command prefix (current mitigation) | Works for individual commands but doesn't prevent garbling during parallel agent relay |

Feature Request

Please consider adding one or more of the following:

Option A: CLAUDE_CODE_POWERSHELL_PATH environment variable

Similar to CLAUDE_CODE_GIT_BASH_PATH for the Bash tool, allow users to specify a custom path for the PowerShell tool's shell executable. This would enable a wrapper script that sets encoding before invoking the real pwsh.exe.

Option B: Shell initialization command configuration

A settings.json option to specify initialization commands that are prepended to every PowerShell tool invocation:

{
  "shellInit": {
    "powershell": "& chcp.com 65001 | Out-Null; [Console]::InputEncoding = [Console]::OutputEncoding = [System.Text.Encoding]::UTF8; $OutputEncoding = [System.Text.Encoding]::UTF8;"
  }
}

Option C: Force UTF-8 encoding for subprocess I/O

Have Claude Code explicitly set the child process's console code page to 65001 before spawning pwsh.exe, or read subprocess output as UTF-8 regardless of the process's reported encoding.

Environment

  • OS: Windows 11 Pro (10.0.26200)
  • PowerShell: 7.x (pwsh.exe)
  • System locale: Japanese (ACP=932, OEMCP=932)
  • Claude Code version: Latest (as of 2025-05-28)
  • Reproduction: Run multiple Agent() calls in parallel that produce Japanese text output

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗