[BUG] Desktop app file attachments mangle U+202F in macOS screenshot filenames — every tool sees 'File does not exist'

Summary

Attaching a macOS/iOS screenshot to Claude Code (desktop app) by drag-and-drop produces a file reference whose path does not match the file on disk: the narrow no-break space (U+202F) that macOS puts before "AM"/"PM" in screenshot filenames arrives as a regular space (U+0020). Every tool call against that path (Read, stat, sips, …) fails with "File does not exist", even though the file is right there in ~/Downloads.

Combined with HEIC not being readable by the Read tool (see #76492), the common real-world flow iPhone screenshot → AirDrop → drag into Claude Code fails 100% of the time, and the model typically burns several turns misdiagnosing it (iCloud placeholders, sandbox, permissions) because ls/glob CAN see the file while exact-path access cannot.

Repro

1. On macOS, take any screenshot (or AirDrop one from iOS). Filename will be like Screenshot 2026-08-10 at 9.22.20 PM.heic — the space before PM is U+202F.
2. Drag the file from ~/Downloads into the Claude Code desktop app input and send.
3. The model receives @"/Users/<user>/Downloads/Screenshot 2026-08-10 at 9.22.20 PM.heic" with a plain U+0020 before PM.
4. Any Read/Bash against that literal path → File does not exist.
5. ls ~/Downloads/*.heic lists the file; a glob (Screenshot*9.22.20*.heic) resolves it fine — confirming the mismatch is the space character, not the file.

Expected

The attachment path handed to the model preserves the exact bytes of the on-disk filename (no Unicode normalization / whitespace substitution). Ideally, image attachments would be passed as image content rather than a path at all, which would also sidestep the HEIC limitation.

Environment

• Claude Code desktop app, macOS (Darwin 25.6.0)
• Model: claude-fable-5
• File source: iOS screenshot via AirDrop to ~/Downloads (HEIC)

Related

• #2224 (closed/autoclose) — general Unicode-filename tool inconsistency
• #76492 (open) — HEIC auto-convert feature request
• #67494 / #29870 — Write/Edit tools stripping U+202F/U+00A0 inside files; this report is the same class of bug applied to attachment paths