Read tool renders JS Unicode escape sequences inconsistently, causing Edit failures

Bug: Read tool renders JavaScript escape sequences inconsistently

Description

When reading a file that contains JavaScript Unicode escape sequences (e.g. \u2192 in a template literal), the Read tool sometimes renders the escape as the actual Unicode character (→) and sometimes shows the literal escape sequence (\u2192). This inconsistency causes Edit operations to fail because the old_string doesn't match what's actually in the file.

Steps to reproduce

1. Create a file containing a JavaScript template literal with \u2192:

``js
console.log(${a}\u2192${b});
``

1. Read the full file with the Read tool
2. Note how \u2192 is displayed (may show as →)
3. Read just the specific line range containing that line
4. Note it may display differently than step 3
5. Attempt to Edit using the representation from step 3 — may fail if the actual file content doesn't match

Expected behavior

The Read tool should consistently show the exact bytes in the file. If the file contains the literal characters \u2192 (backslash-u-2192), it should always display \u2192, never the rendered arrow →.

Impact

When using Edit after Read, users must re-read the exact block they want to edit to get the correct character representation. This caused a failed Edit operation and a ~10 minute debugging detour in a real session.

Environment

• Claude Code CLI on Windows 11
• Model: claude-opus-4-6 (1M context)
• File type: TypeScript (.ts) with ES module template literals