Codex App on Windows mis-handles chat local file links with drive-letter paths

What version of the Codex App are you using (From “About Codex” dialog)?

26.306.996.0 (Microsoft Store package OpenAI.Codex_26.306.996.0_x64)

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

This issue is a duplicate of #14079. I am updating the description here only to correct an earlier imprecise diagnosis.

On Windows, the Codex App appears to have two distinct problems when handling local file links in chat:

1. Drive-letter absolute paths are not treated as real local file path objects, even when the entire path is ASCII-only.
2. If any path segment contains non-ASCII characters (for example Chinese directory names or Chinese filenames), the target becomes percent-encoded (%...) and fails to open correctly.

Important correction:

• the %... garbling is not just a “long path” problem
• it is specifically triggered when the clickable path target contains non-ASCII path segments

Examples of observed behavior:

• </Users/28033/...> works and is treated as a real local path object in the UI
• right-click includes Copy path
• clicking opens the correct file
• <C:/Users/...>, <D:/...>, <F:/...> render blue/underlined but are not treated as real local path objects
• no path metadata
• no Copy path
• clicking does not open the file
• paths containing Chinese directory names or Chinese filenames become percent-encoded and fail to open

What steps can reproduce the bug?

1. On Windows, create or use existing files such as:

• C:\Users\28033\.codex\tmp\link-tests\ascii.md
• D:\.codex_shortfiles\link-tests\ascii.md
• F:\.codex_shortfiles\link-tests\ascii.md
• files under directories or filenames containing Chinese characters

1. In a Codex App chat message, include links like:

[A](<C:/Users/28033/.codex/tmp/link-tests/ascii.md>)
[B](<D:/.codex_shortfiles/link-tests/ascii.md>)
[C](<F:/.codex_shortfiles/link-tests/ascii.md>)
[D](</Users/28033/.codex/tmp/link-tests/ascii.md>)

1. Observe:

• A, B, C: blue/underlined only, but not real path objects and do not open
• D: works correctly

1. Then test paths where one segment contains Chinese characters:

• ASCII dir + Chinese filename
• Chinese dir + ASCII filename
• Chinese dir + Chinese filename

1. Observe that once any path segment is non-ASCII, the target becomes percent-encoded and fails to open correctly.

What is the expected behavior?

• On Windows, drive-letter absolute paths should be recognized and open the correct local file, or be rejected with a clear unsupported-format message.
• Non-ASCII Windows paths should either work correctly or fail explicitly, rather than being percent-encoded into unusable local targets.

Additional information

• The actively tracked duplicate target is #14079.
• I added the more precise repro notes there as comments so discussion stays in one place.
• Current workaround is to expose source files through ASCII-only alias paths, but that is only a workaround, not a real fix.