Windows app file references resolve to invalid c:\\C:\\ path and fail to open
Resolved 💬 3 comments Opened Mar 5, 2026 by 0okay Closed Mar 10, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
26.304.1528.0 (from runtime path in logs: OpenAI.Codex_26.304.1528.0_x64)
What subscription do you have?
ChatGPT Plus (using Codex desktop app)
What platform is your computer?
Microsoft Windows NT 10.0.22621.0 x64
What issue are you seeing?
On Windows, clicking local file references generated in Codex responses can resolve to an invalid path with duplicated drive prefix, e.g.:
c:\C:\Users\Administrator\Documents\Playground\Claude-Patent-Creator\commands\create-patent.md
This fails to open and prevents reliable navigation from assistant responses to source files.
In addition, line-level focus behavior is inconsistent: users cannot reliably jump/focus to exact lines with collapsible context (diff-like experience) from response references.
Relevant log errors:
无法读取文件 'c:\C:\Users\...\create-patent.md'无法解析不存在的文件 'c:\C:\Users\...\commands'
What steps can reproduce the bug?
- On Windows, use Codex desktop app in a workspace.
- Ask Codex to provide source references for local files/lines.
- Click a returned file reference from the response.
- Observe VS Code/Codex logs showing
c:\C:\...and file open failure.
What is the expected behavior?
- Local Windows paths should resolve exactly once (e.g.,
C:\Users\...) when clicked. - Clicking references should open the target file reliably.
- Line-level jump/focus should work consistently, with optional fold/collapse context similar to diff navigation.
Additional information
- This appears to be App-side path normalization / URI-to-path conversion on Windows.
- Separate warning also appeared in logs about
settings.jsonBOM parse, but the path duplication issue reproduces as a distinct navigation problem.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I believe the currently open Windows desktop app path-link bug in #14079 is closely related to this older issue.
I reproduced a very similar family of failures on a newer Codex App build (
26.306.996.0, Windows10.0.26200.0 x64, ChatGPT Plus):<C:/...>,<D:/...>,<F:/...>render blue/underlined but are not treated as real local path objectsCopy path</Users/...>works correctly and is treated as a real path object<///C:/...>/<///D:/...>can still resolve incorrectly with an extra current-drive prefix (same family as thec:\\C:\\...symptom here)So although this issue is closed, the Windows desktop local-path normalization problem still appears to exist in current builds, and the active tracking issue seems to be #14079.
For cross-reference, this older Windows desktop issue also appears related to:
From current repros, #14079 looks like the broader active tracker, while this issue captures one specific Windows symptom (
c:\\C:\\...invalid path resolution).