Local file link does not render properly
What version of the Codex App are you using (From “About Codex” dialog)?
26.325.31654
What subscription do you have?
Plus
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Title
Intermittent local Markdown link rendering bug for assistant-authored messages on Windows in Codex desktop
Environment
- Codex desktop app
- Windows
- Example target path:
D:\...file.md
Summary
Local Markdown links to Windows paths render inconsistently in Codex desktop. The same visible Markdown can sometimes render as a working hyperlink and sometimes not render as a hyperlink at all. External https:// links work normally.
Example Markdown [here](D:\Cloud\Dropbox\Coding Ground\GITHUB_AND_APPS_SCRIPT_ELI5.md)
Repro steps
- In Codex desktop on Windows, ask the assistant to output this exact Markdown:
[here](D:\...file.md)
- Observe whether the assistant-authored message renders the link as blue/clickable.
- In the same thread, type the exact same Markdown yourself as a user message.
- Compare whether the user-authored message renders as blue/clickable.
- Repeat the assistant-authored test in later messages. The same visible Markdown may alternate between working and not working.
Expected result
The same local Markdown link should render consistently and open the same local file regardless of whether it is user-authored or assistant-authored.
Actual result
- External
https://links render reliably. - Local Windows-path Markdown links are inconsistent.
- Some assistant-authored instances render and work.
- Other assistant-authored instances with the same visible Markdown do not render as hyperlinks.
- User-authored instances may work when assistant-authored ones do not.
Key observation
When the failure happens, the issue is often visible before clicking because the text is not rendered as a blue hyperlink at all. This suggests the problem occurs during rendering/sanitization/link rewriting, not only at click time.
Strongest hypothesis
Codex desktop appears to use different rendering or internal link-rewrite paths for different message surfaces or message origins. Local Windows paths like D:\... are likely being handled inconsistently during sanitization, normalization, or internal app:// link rewriting. The issue appears message-instance-dependent rather than text-dependent.
Additional evidence
- Commentary/progress messages appear to render differently from final messages.
- In at least one case, commentary surfaced a rewritten target like
app://-/index.html?hostId=local. - That suggests an internal rewrite layer is involved.
What steps can reproduce the bug?
Repro steps
- In Codex desktop on Windows, ask the assistant to output this exact Markdown:
[here](D:\...file.md)
- Observe whether the assistant-authored message renders the link as blue/clickable.
- In the same thread, type the exact same Markdown yourself as a user message.
- Compare whether the user-authored message renders as blue/clickable.
- Repeat the assistant-authored test in later messages. The same visible Markdown may alternate between working and not working.
What is the expected behavior?
The link should be rendered in blue text and proper linking
Additional information
I have done the troubleshooting with Codex.
There is no pattern to when a link is rendered whenever posted by Codex. But any link posted by me always get rendered - even the ones that was posted out in plaintext by Codex.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗