Write/Edit tools silently decode \uXXXX in file content, corrupting escape-sequence text (Linux)

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

• Platform: Linux
• Tools affected: Write, Edit (content / new_string). The related Edit old_string matching case is #52813.
• Appears to be a transport/argument-decoding issue (JSON Unicode-escape decoding of tool arguments), so likely platform-independent.

Related (but closed)

• #58358 — Write/Edit/Bash decode escapes in paths/heredoc content (closed as duplicate of #54583)
• #54583 — escape in Windows path decoded (closed, not planned, stale; invites a new issue)
• #52813 — Edit silently normalizes escapes in old_string, breaking exact matches

Related (still open)

• #51815 — Read/Edit fail on Windows username with an escape sequence
• #64479 - Edit tool fails on mixed literal/escape Unicode in multi-line old_string
• #73483 - Write emits raw U+0000 where the model intended the six-character NUL escape sequence
• #66058 - Edit tool corrupts literal escape sequences

🤖 Filed with Claude Code