Write/Edit/Bash tools silently decode \uXXXX in paths and heredoc content, corrupting strings (e.g. u9511112 -> 锑112)

Summary

Claude Code's Write, Edit, and Bash (heredoc content) tools silently decode literal text containing the 4-hex sequence after \u as a Unicode escape, corrupting file paths and string contents. For users whose home directory or paths contain certain digit-letter sequences, this is a continuous source of operational pain.

Concrete reproducer

My local username is u9511112. Any file path containing u9511112 is corrupted:

• C:\Users\Mars\.gstack\projects锑112-geek-studio\ becomes C:\Users\Mars\.gstack\projects\锑112-geek-studio\ on disk.
• The bytes 锑 get decoded into U+9511 (锑, the Chinese character for "antimony").
• Subsequent Read/Edit operations against the intended path fail with "file not found".

I have reproduced this multiple times across all three tools (Write, Edit, Bash heredoc with quoted EOF) over two days (2026-05-11, 2026-05-12).

Specific reproductions in my session

1. Write tool with file_path: "C:\Users\Mars\.gstack\projects锑112-geek-studio\Mars-main-design-20260512-135557.md" → file created at ...\projects锑112-geek-studio\.... Required bash mv to recover.
2. Edit tool with the same path pattern → "File does not exist" error.
3. Bash tool with cat > file << 'PYEOF' (single-quoted heredoc tag) containing D1_PLUS = r'C:\Users\Mars\.gstack\projects锑112-...' → the on-disk file contained 锑112 instead of 锑112. Hex dump confirmed UTF-8 encoding of U+9511 (e9 94 91).

Expected vs actual

• Expected: tools treat file_path arguments and heredoc content as opaque strings. Raw text 锑 should stay as 6 literal characters.
• Actual: somewhere in the tool framework, the string is run through a JSON-string or Python-literal decoder that interprets \u<4 hex> escapes.

Impact

• Operational friction every time I run /context-save, /plan-eng-review, or any flow that writes to ~/.gstack/projects/u9511112-geek-studio/.
• Recovery requires manual bash mv from the corrupted directory after every Write tool call.
• Workarounds available but not obvious: forward-slash paths in Python sometimes bypass the issue; bash heredoc with no \u in content; Edit tool with paths that don't contain u9511112.

Suggested fix

• Whatever string-decoding pass runs against tool args / heredoc content, make it explicitly NOT interpret \u, \U, \x, etc. as escapes. The model already encodes special characters as needed; double-decoding causes silent corruption.
• At minimum, document the limitation so users with affected usernames know what's happening.

Environment

• Claude Code version: (latest as of 2026-05-12)
• Model: Claude Opus 4.7 (1M context, claude-opus-4-7[1m])
• OS: Windows 11 Home 10.0.28000 with WSL Ubuntu-22.04
• Shell: PowerShell + Git Bash
• Username substring: u9511112 (this slug appears in ~/.gstack/projects/<slug>-<repo>/ paths)

Anyone whose username or path contains \uXXXX 4-hex-digit sequences after a u letter will hit this. Probably not just me.