[BUG] Windows: anonymized cwd causes Edit/Write to write to C: drive instead of real project location

Summary

On Windows, Claude Code reports an anonymized/obfuscated cwd in the environment block, while Bash resolves to the true path. When Edit/Write are invoked using the reported cwd, Windows happily creates the entire phantom directory tree on C: (the obfuscated path doesn't exist), polluting the filesystem with mirror copies of project files in the wrong location while the real project is untouched.

Environment

• Claude Code 2.1.112
• Windows 11 Home China 10.0.22631
• Shell: bash (Git Bash)
• Project located on D: drive

Symptoms

Environment block shows:

Primary working directory: C:\Users\user\project\_external\D\dev-34c6fc\my_proj-279965\java-23524b\zhitu-ag-64a949

But Bash pwd correctly reports:

/d/dev/my_proj/java/zhitu-agent-java

Every path segment in the reported cwd is anonymized with a hash suffix (dev → dev-34c6fc, my_proj → my_proj-279965, etc.) and the drive letter D: is flattened into _external\D\.

When Edit/Write use that cwd, Windows creates the entire fake path tree under C:\Users\user\project\_external\…. From Claude's perspective the file appears written (it reads back from the same path), but the real D: project is untouched and C: accumulates phantom mirror copies that have to be rm -rfed manually.

Reproduce

1. On Windows, launch Claude in a project on a non-C: drive (e.g. D:\dev\my_proj\…).
2. Observe the environment block reporting an anonymized C:\Users\user\project\_external\<DRIVE>\<hashed-segments>\… cwd.
3. Have Claude \Write\ or \Edit\ a file. The file lands at the anonymized C: path, not the real D: path.

Impact

• Edits silently miss the real project.
• \C:\ accumulates garbage requiring manual cleanup.
• User has to catch every wrong-drive write themselves.
• Newly appeared in the last few days — earlier sessions didn't show this anonymization.

Workaround

Use \Bash\ with heredoc / \sed\ (bash shell has the correct cwd), or pass absolute \D:\ paths to Edit/Write.

Suspected cause

Looks like a telemetry-style anonymization layer leaks into the \cwd\ field consumed by file-IO tools, while \Bash\ bypasses it through the shell's own pwd. Expected: the cwd seen by tools should match the launch cwd, with any anonymization confined to telemetry payloads.