Summary
The Write and Edit tools silently decode \uXXXX sequences in file content as JSON Unicode escapes before writing to disk. As a result, it is impossible to store a literal \uXXXX escape sequence in a file via these tools:
- Authoring the six-character text
\uE010 writes the actual U+E010 character.
- Authoring
\\uE010 to compensate writes a doubled backslash (\\uE010).
Neither produces the intended single-backslash literal \uE010 on disk.
This is the content-corruption analog of several closed Windows-path reports (#58358, #54583, #51815). Those were framed around home-directory paths on Windows and closed as stale/duplicate. This report is about arbitrary file content on Linux, is trivially reproducible, and still occurs, so I am filing fresh per the maintainer note on #54583 ("Please open a new issue if this is still relevant").
Why it matters
Any workflow that legitimately needs literal \uXXXX text in a file is silently corrupted:
- Source code / test fixtures that assert on escape-sequence strings.
- Config or data files that store Unicode escapes as text (e.g. a YAML field holding
\uE010).
- Documentation about escape sequences (this very issue body hit the bug while being drafted).
The corruption is invisible: the written characters often render as nothing or as unrelated glyphs, Read shows an apparently empty "", and grep for the intended text cannot find the line. The agent cannot tell it went wrong without dropping to od -c.
Reproducer (Linux)
Call the Write tool so that the file content is the line tengwar: " followed by the six literal characters \uE010, then \uE046, then ". Inspect the raw bytes:
$ od -c file.txt
0000000 t e n g w a r : " 356 200 220 356 201 206
0000020 " \n
356 200 220 = UTF-8 for U+E010, 356 201 206 = U+E046. The escape text was decoded into the actual characters before the file was written.
Attempted workaround — author the content with doubled backslashes (\\uE010\\uE046):
$ od -c file2.txt
0000000 t e n g w a r : " \ \ u E 0 1
0000020 0 \ \ u E 0 4 6 " \n
That yields a doubled backslash, not the intended single-backslash escape. So there is no way to write a literal single-backslash \uXXXX through Write/Edit.
Note this is not clean JSON round-tripping: standard JSON would decode a doubled backslash to a single one, but here the doubled backslash is preserved literally while a bare \uXXXX is decoded. The two behaviors are inconsistent.
Working alternative (for reference)
Writing the same value via Bash with sed/printf produces the correct single-backslash escape on disk (the shell tool's own escape handling collapses the doubled backslash). So the corruption is specific to how \uXXXX in the Write/Edit content argument is decoded at the tool boundary, not an inherent filesystem limitation.
Expected
The content (and Edit new_string) should be written to disk byte-for-byte as authored. A literal single-backslash escape in the intended file content should appear on disk as the six ASCII characters backslash, u, E, 0, 1, 0, not be decoded into U+E010.
Environment
Related (but closed)
Related (still open)
🤖 Filed with Claude Code
Summary
The
WriteandEdittools silently decode\uXXXXsequences in file content as JSON Unicode escapes before writing to disk. As a result, it is impossible to store a literal\uXXXXescape sequence in a file via these tools:\uE010writes the actual U+E010 character.\\uE010to compensate writes a doubled backslash (\\uE010).Neither produces the intended single-backslash literal
\uE010on disk.This is the content-corruption analog of several closed Windows-path reports (#58358, #54583, #51815). Those were framed around home-directory paths on Windows and closed as stale/duplicate. This report is about arbitrary file content on Linux, is trivially reproducible, and still occurs, so I am filing fresh per the maintainer note on #54583 ("Please open a new issue if this is still relevant").
Why it matters
Any workflow that legitimately needs literal
\uXXXXtext in a file is silently corrupted:\uE010).The corruption is invisible: the written characters often render as nothing or as unrelated glyphs,
Readshows an apparently empty"", andgrepfor the intended text cannot find the line. The agent cannot tell it went wrong without dropping tood -c.Reproducer (Linux)
Call the
Writetool so that the file content is the linetengwar: "followed by the six literal characters\uE010, then\uE046, then". Inspect the raw bytes:356 200 220= UTF-8 for U+E010,356 201 206= U+E046. The escape text was decoded into the actual characters before the file was written.Attempted workaround — author the content with doubled backslashes (
\\uE010\\uE046):That yields a doubled backslash, not the intended single-backslash escape. So there is no way to write a literal single-backslash
\uXXXXthroughWrite/Edit.Note this is not clean JSON round-tripping: standard JSON would decode a doubled backslash to a single one, but here the doubled backslash is preserved literally while a bare
\uXXXXis decoded. The two behaviors are inconsistent.Working alternative (for reference)
Writing the same value via
Bashwithsed/printfproduces the correct single-backslash escape on disk (the shell tool's own escape handling collapses the doubled backslash). So the corruption is specific to how\uXXXXin theWrite/Editcontent argument is decoded at the tool boundary, not an inherent filesystem limitation.Expected
The
content(andEditnew_string) should be written to disk byte-for-byte as authored. A literal single-backslash escape in the intended file content should appear on disk as the six ASCII characters backslash,u,E,0,1,0, not be decoded into U+E010.Environment
Write,Edit(content /new_string). The relatedEditold_stringmatching case is Edit tool silently normalizes\uXXXXescape sequences in old_string, breaking exact matches #52813.Related (but closed)
\uXXXXescape sequences in old_string, breaking exact matches #52813 — Edit silently normalizes escapes inold_string, breaking exact matchesRelated (still open)
🤖 Filed with Claude Code