I found these CLAUDE.md examples that help mitigate when claude or external tools are executed
ie: Cases where you can't just modify your profile
The problem is powerh
In the file $Profile.CurrentUserAllHosts add
# This same line works on Powershell 5.1 and Pwsh 7+
$OutputEncoding =
[Console]::OutputEncoding = [Console]::InputEncoding =
[System.Text.UTF8Encoding]::new( <# bool: encoderShouldEmitUTF8Identifier #> )Or even set your global default like chcp 65001. But that can affect legacy apps if they force the culture as the implicit encoding type.
# Windows PowerShell Parameter Constraints
CRITICAL GLOBAL RULE: The host machine uses a Japanese system locale (CP932/Shift-JIS).
Whenever you invoke external commands via the Windows PowerShell execution tool boundary that pass Japanese string arguments, you MUST prepend an explicit UTF-8 memory boundary wrapper.
Never call parameters raw. Instead, format every shell invoke command like this:
powershell -NoProfile -Command "[Console]::InputEncoding = [System.Text.Encoding]::UTF8; [Console]::OutputEncoding = [System.Text.Encoding]::UTF8; <Your-Command-Here>"{
"hooks": {
"PreToolUse": "[Console]::InputEncoding = [System.Text.Encoding]::UTF8; [Console]::OutputEncoding = [System.Text.Encoding]::UTF8;"
}
}When I've had issues with commands related to encoding, some of these have helped. They might be overlap with your case
- if
wslis involved -- that ignores encodings when piping. It forcesutf-16lebreaking the output streams. ( one fix: https://www.reddit.com/r/PowerShell/comments/1ijvi0g/comment/mbhixhr ) -- Or use a wrapper that switches switches to encodingutf-16lebefore piping fromwslthen switch back to your original enocding - Setting
$ENV:LANG = 'C.UTF-8' - (from above) Setting $OutputEncoding, and all [Console]::Input/Output encodings
- I use
[System.Text.UTF8Encoding]::new( $false )intentionally because some cli apps break if you use the BOM version named[System.Text.UTF8Encoding]
- I use
$ENV:LANG = 'C.UTF-8'