Edit tool silently drops/corrupts Nerd Font (PUA) Unicode glyphs when writing files

Description

While using the Edit tool to add a Nerd Font icon (a Private Use Area / PUA Unicode codepoint) into a file, the tool call reported success, but the byte that landed on disk was a plain ASCII space (0x20), not the intended glyph. No error, warning, or diff mismatch was surfaced anywhere in the process.

This is different from the rendering/visibility issues tracked in #70301 (PUA glyphs not displayed in the TUI, and the Read tool not surfacing them to the model). This report is about the write path: the resulting file content did not match what the tool call was asked to write, silently.

Repro

1. Ask Claude Code to insert a Nerd Font glyph via the Edit tool, e.g. changing:

``lua
{ section = 'startup' },
`
to
`lua
{ section = 'startup', icon = '<nf-md-flash glyph, U+F0E7>' },
``

1. The Edit tool reports the edit succeeded, no errors shown.
2. Inspect the changed line with hexdump -C: the byte at the icon's position is 0x20 (space) — not the expected 3-byte UTF-8 sequence 0xef 0x83 0xa7 for U+F0E7.
3. Nothing in the transcript (tool result, diff view, or otherwise) indicated a mismatch. The only way this was caught was by manually hexdumping the file afterward, prompted by the user noticing the icon wasn't actually showing up.

Environment

• Claude Code CLI (terminal), Linux
• Model: Claude Sonnet 5 (claude-sonnet-5)

Impact

Any Edit/Write that embeds a Nerd Font / PUA glyph (icons in dashboards, statuslines, prompt configs, etc.) can silently produce incorrect file content. Since these glyphs are usually invisible ("tofu") in fonts that lack the matching Nerd Font patch, neither the assistant's own verification (re-reading the file, rendering it) nor a casual glance by the user reliably catches the discrepancy — it took an explicit byte-level hexdump to confirm.

Workaround via CLAUDE.md

Don't embed the literal glyph in an Edit/Write tool call. Instead compute the exact UTF-8 bytes via a script and patch the file directly, e.g.:

python3 -c "
glyph = chr(0xf0e7).encode('utf-8')
data = open('file.lua','rb').read().replace(b'OLD', b'NEW' + glyph + b'MORE')
open('file.lua','wb').write(data)
"

then verify with hexdump -C that the intended bytes actually landed.

Possibly related

• #70301 — Nerd Font / PUA characters not rendered in the TUI and dropped by the Read tool. Same character class (PUA/Nerd Font codepoints), but that issue is about visibility (rendering + Read-tool surfacing); this one is about write-path correctness — the file content itself ends up wrong, independent of how it's later displayed or read back.

I can't tell from the assistant side whether the glyph was already wrong by the time the Edit tool call was made (a generation/tokenization issue on rare PUA codepoints) or whether it was correct in the call and got lost/normalized during transmission or the actual file write. Flagging both as candidate root causes in case that's useful for triage.