[Windows] "Open in File Explorer" on existing C:\Users\... links opens C:\Users instead of the file location

Environment

• Codex Desktop for Windows (packaged app), app-server codex-cli 0.153.0-alpha.5, install hash 994e8469124a0d31, as of 2026-09-03
• OS: Windows NT 10.0.28000.0 (custom "X-Lite" image, stock explorer.exe)
• Local host

Summary

Right-clicking a rendered local-file link in chat and choosing Open in File Explorer opens C:\Users instead of the file's containing folder whenever the link target lives under C:\Users\.... The target files exist on disk and the paths are plain ASCII.

Repro

1. Paste a screenshot into the chat. Codex saves it to C:\Users\<user>\AppData\Local\Temp\codex-clipboard-<uuid>.png and renders a link to it.
2. Confirm the file exists on disk (it does; Test-Path returns True).
3. Right-click the rendered link → Open in File Explorer.

• Expected: Explorer opens ...\AppData\Local\Temp with the PNG selected.
• Actual: Explorer opens C:\Users. Reproduces consistently for C:\Users\... targets.

Observations

• Links under E:\... reveal correctly, so the reveal action itself works.
• Running explorer /select,"<full path>" outside the app works fine.
• The failure lands exactly at C:\Users — the target appears truncated at the \U boundary, consistent with \U being consumed as an escape prefix while parsing the markdown link target. This is the same escape-mangling family as #28439, where \. before dot-directories is dropped.
• #14079 comments note the Windows package calls showItemInFolder(...) with an openPath(...) fallback; opening the truncated C:\Users prefix through that fallback would produce exactly this symptom.

Related but distinct issues

• #28439: separator dropped before .codex (\. escape) — same family, different mangling and different symptom.
• #38668: "Open in folder" falls back to C:\ for mapped-drive/UNC project files — different trigger.
• #14079: broader Windows local-link parsing (/C:/ prefixing, drive-letter classification, non-ASCII percent-encoding).

Requested fix

Pass the unmodified native path to the reveal action (or normalize/protect backslash escapes before markdown link-target parsing), and add regression coverage for reveal-in-Explorer with user-profile paths such as C:\Users\<user>\AppData\....

Trace the Windows reveal path through showItemInFolder(...) and its openPath(...) fallback, then inspect how local-file markdown link targets parse backslashes. Add regression coverage for a C:\Users... path and verify that Open in File Explorer opens its containing folder with the file selected.