A macOS screenshot is saved as Screenshot 2026-09-03 at 12.07.21 PM.png, but the space before AM/PM is U+202F NARROW NO-BREAK SPACE, not U+0020. Every other space in the name is a normal space, so the name looks completely ordinary in ls, in Finder, and in a terminal — and a path you retype or copy out of prose will not resolve.
Symptom: a CLI reports the file as missing while ls on a glob prints it.
$ ls ~/Pictures/Screenshots/*12.07.21*
Screenshot 2026-09-03 at 12.07.21 PM.png
$ mytool --src "~/Pictures/Screenshots/Screenshot 2026-09-03 at 12.07.21 PM.png"
error: Source file not foundProof, on the glob-expanded name:
$ printf '%s' "$(ls ~/Pictures/Screenshots/*12.07.21*)" | xxd | tail -2
00000030: 3032 362d 3039 2d30 3320 6174 2031 322e 026-09-03 at 12.
00000040: 3037 2e32 31e2 80af 504d 2e70 6e67 07.21...PM.png
^^^^^^^^ e2 80 af = U+202FWhy it bites agents and scripts specifically: an agent reading a filename from a directory listing (or a human pasting one into a prompt) reproduces it with an ordinary space, because U+202F renders identically. The failure then looks like a broken tool or a permissions problem rather than an encoding one.
Fixes, in order of robustness:
- Never retype the path. Let the shell produce it:
SRC=$(ls ~/Pictures/Screenshots/*2026-09-03*12.07.21*)then pass"$SRC". - Glob on the stable parts only (the date and the
HH.MM.SS); the AM/PM token is exactly where the trap is. - Auditing a directory for affected names:
printf '%s\n' * | grep -P '\x{202f}'. - In a program, compare filenames as bytes, or normalize with NFKC before matching user-supplied text against directory entries.
The same class of bug shows up in other Apple-generated names and in text copied out of Word or Pages, which also emit U+202F and U+00A0. Treat any filename that came from a GUI as bytes, not as text you can retype.