[BUG] Claude Code for VS Code 2.1.117: Read/Edit tools fail on Windows when username contains \uXXXX sequence
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?
The Read and Edit tools in the VS Code extension fail with "file does not exist" when the Windows username contains a character sequence that matches a Unicode escape. For example, a username of u0041xyz contains \u0041, which is interpreted as Unicode codepoint U+0041 (A), so the path C:\Users\u0041xyz\... is mangled to C:\UsersAxyz\... before it reaches the filesystem. All Read and Edit tool calls fail as a result.
My username follows this pattern as it was assigned by my organisation on a managed device — I am unable to change it.
What Should Happen?
Backslashes in Windows file paths should be treated as path separators, not Unicode escape characters. Read and Edit tools should resolve paths correctly regardless of the username.
Error Messages/Logs
File does not exist. Note: your current working directory is (removed)Steps to Reproduce
- Have a Windows username containing a sequence matching \uXXXX where XXXX is a valid Unicode codepoint (e.g. u0041xyz, where \u0041 = A)
- Open a project in VS Code with the Claude Code extension v2.1.117
- Ask Claude to read or edit any file in the project
- The Read/Edit tool receives a mangled path (e.g. C:\UsersAxyz\...) and returns "file does not exist"
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.114 (Claude Code for VS Code)
Claude Code Version
2.1.117
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
VS Code integrated terminal
Additional Information
The Bash tool is unaffected because it uses Unix-style forward-slash paths. Only the Read and Edit tools, which construct Windows-style backslash paths, are affected. The issue is specific to usernames where a letter-digit sequence happens to form a valid \uXXXX Unicode escape — a pattern that may be common in organisation-managed devices where usernames are system-assigned.
Showing cached comments. Read the full discussion on GitHub ↗
10 Comments
Found 1 possible duplicate issue:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This seems related/similar but is not a duplicate of #46276. Both are Windows path mangling bugs in the VS Code extension, but they have different triggers and root causes. This issue also appears to be a more recent regression — the behaviour is confirmed working in a 4 day old version, whereas the other bug was reported two weeks ago.
I can confirm this occurs. One workaround is to directly write to a disk path without that username, but the issue arises again when Claude writes to the .claude user directory.
This is severe, and I am experiencing similar in other path segments (#58140)
Still happening on 2.1.156. VERY severe. Even if I have Claude write a memory, he can't find it.
Just to note that the powershell option in claude might help.
https://code.claude.com/docs/en/tools-reference#powershell-tool
I'd normally test it and report back, but my temptation to go the extra mile for anthropic has been eliminated after the zero issue responses in a year to any of my issues except mark as dupe.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
Still reproducing on Claude Code 2.1.204 (Windows 11, Git Bash/MSYS), same root cause: a literal backslash immediately followed by a username whose leading characters form valid hex (here
u173350→1733) gets decoded as a Unicode escape (\u1733→ U+1733), with the trailing digits appended as plain text.One addition to what's reported here and in #51815: this is not limited to the Read/Edit tools, and the Bash tool is not unaffected as #51815 states — it's about whether the parameter itself contains the dangerous backslash+username sequence, regardless of which tool receives it. I reproduced the exact same corruption inside plain file content written through the Bash tool via a heredoc, when that content happened to include an example Windows-style path with the pattern. Only genuinely avoiding the backslash+username sequence (e.g. using forward-slash POSIX paths through Bash) sidesteps it reliably — using Bash "instead of" Read/Write/Edit is not itself a safe workaround if the dangerous string still appears somewhere in the parameter.
This is still silently corrupting file operations with no error surfaced (the tool reports success while writing to a different, real, sibling directory) — could this be reconsidered given it's a data-loss-adjacent silent failure mode, not just a cosmetic bug?
Silently corrupting Tcl code - requiring additional custom linting and agent guidance to reduce the risk.
This repo has already had this reported in more than just this ticket - closing and requesting 'open a new issue' seems like a bug in your ticket processing system too. I'd rather work on another harness that takes issues seriously.
The best way to get this addressed would be to construct a security
vulnerability around the issue, tag it as a zero day on the socials, then
watch it be patched rapidly.
On Tue, 18 Aug 2026 at 03:31, Julian Noble @.***> wrote: