[BUG] Silent empty output on CJK paths (PowerShell/WSL2) is misjudged by the agent as negative confirmation ("file does not exist")

Preflight Checklist

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

What's Wrong?

On Windows setups spanning three layers — native Windows, PowerShell, and WSL2 — file operations on paths containing CJK (e.g. Traditional Chinese) characters can fail silently with empty output rather than with an error or visible mojibake.

The encoding chain (how the command string is passed in → the console active code page → how stdout is encoded on the way back) breaks at one of its links. When it does, a command like Test-Path / Get-ChildItem against a CJK path resolves a name that does not match the real path and returns nothing — Test-Path → $false, Get-ChildItem → empty.

The critical part is what the agent does next: it treats the empty result as a valid negative answer ("the folder is empty / the file does not exist / there is no leftover copy") and reports that to the user as a confirmed conclusion. The operation looks like it succeeded — it never ran against the intended path at all.

How this differs from #62862 and #26006:

• #62862 is about output rendering as mojibake — garbled but present text; the user can see something is wrong.
• #26006 is about silently mixing WSL/gitbash/PowerShell across commands.
• This is a third consequence: when the encoding chain breaks on a CJK path, the symptom is a clean empty output that is indistinguishable from a true negative, which the agent confidently reports as confirmation. The failure presents as a success.

What Should Happen?

Either the CJK path is handled correctly end-to-end, OR — independent of the encoding fix — the agent should recognise that an empty result on a non-ASCII path is ambiguous (could be "truly empty" or "path didn't resolve") and verify the directory itself resolved before drawing a negative conclusion.

"Empty output == confirmed negative" is an unsafe inference for any verification or cleanup workflow, not just CJK paths, and is worth hardening on its own even if the encoding issue is fully fixed.

Error Messages/Logs

Steps to Reproduce

Environment: Windows 11 + PowerShell + WSL2 (Ubuntu), working in a folder whose path contains CJK characters on a Windows drive.

1. Ask the agent to verify whether a file still exists in a CJK-named folder (e.g. "confirm there's no leftover copy of X in D:\<chinese>\test").
2. The agent issues a PowerShell-based check.
3. PowerShell returns empty — the path name is mangled by the encoding chain and the real folder is never inspected.
4. The agent concludes "no leftover / file does not exist" and reports it as confirmed.
5. Re-checking the same path via WSL bash using the /mnt/... form (UTF-8 end-to-end) shows the files were actually there.

Real session evidence (screenshot in Additional Information): a live Claude Code session where the agent made this exact misjudgement — it first reported "no leftover files," and only after being asked "are you sure?" did it re-check via Bash, find the files were there all along, and attribute the error to PowerShell silently producing no output on the CJK path. Both the failure-as-success and the empty-output-as-confirmation are visible in the agent's own words.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.143

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Environment note: Claude Code runs inside WSL, but spawns powershell.exe for Windows-side operations. The bug surfaces precisely at this WSL↔PowerShell boundary on CJK paths (related to the interface-mixing in #26006).

Two separable problems:

1. Encoding (tooling): the PowerShell tool's encoding chain mishandles CJK paths. Adjacent to #62862 — forcing UTF-8 on the spawned shell ([Console]::OutputEncoding, $OutputEncoding, chcp 65001) would likely fix the garbling.
2. Reasoning (agent): independent of the encoding fix, the agent should not treat a silent empty result as a confirmed negative without first proving the target path resolved. An empty Get-ChildItem and a mis-resolved path are observationally identical.

Suggested mitigations:

• Tooling: allow forcing UTF-8 on the PowerShell tool's spawned shell (overlaps with #62862).
• Agent: when an "exists / empty / leftover?" check returns empty on a non-ASCII path, confirm the directory itself is reachable before reporting a negative. Prefer the WSL /mnt/... (UTF-8) path for CJK file operations where both shells are available.

Impact: affects Traditional/Simplified Chinese, Japanese, Korean (and likely other non-ASCII) users on the common Windows + WSL2 layout. Most dangerous in verification and cleanup workflows, where a false "it's already gone" leads to wrong follow-up actions.

Screenshot below: a real Claude Code session showing the agent making this exact misjudgement (reported "no leftover," then on re-check via Bash found the files present, and attributed it to PowerShell silently producing no output on the CJK path). Paths redacted.

<img width="1084" height="460" alt="Image" src="https://github.com/user-attachments/assets/449c6cd3-3f04-42be-bfd8-9246f0b64fa3" />