Skill.md text not rendering in Windows app in Windows mode
Resolved 💬 5 comments Opened May 6, 2026 by kendonB Closed Aug 4, 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.429.61741
What subscription do you have?
Pro
What platform is your computer?
Windows 11 x64 (Microsoft Windows NT 10.0.26200.0 x64)
What issue are you seeing?
On WSL mode, I could click the skill name and the skill text would pop up to the right. On Windows mode, it doesn't pop up.
What steps can reproduce the bug?
invoke skill with $, click skill
What is the expected behavior?
_No response_
Additional information
_No response_
5 Comments
Does work after the first message has been sent but not while it's in the unsent chat.
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I believe this is a general windows app issue that skills text as a file link only work after the message has been sent, whereas the behaviour should be that the skill should act like a link after being put into the chat text box but still unsent
Still reproducible on the current Windows desktop package
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0.The exact behavior remains:
SKILL.mdtab opens but displays Tab content cannot be displayed.Current renderer error:
The unsent mention contains the correct readable Windows path in
skill-mention-pathanddata-prompt-link-href. The exception occurs synchronously before a file-read RPC.A useful control test: changing only the in-memory preview target from
C:\Users\...\SKILL.mdto/C:/Users/.../SKILL.mdmakes the built-in tab display the same file successfully.The Microsoft Store
app.asarand the runtime-served renderer asset match exactly (SHA-256B7255AE117A54BF16C7F45834054CD16ABD9B24CF5AA9DBD7C796F59743E556A). The packaged preview helper selectspath.win32.dirname(...)for the Windows path, while the bundled browser path implementation haswin32: null.This appears to be the same underlying Windows renderer defect now documented for another preview surface in #35441. I added the longer cross-surface evidence there as well: https://github.com/openai/codex/issues/35441#issuecomment-5123447773
No model/API request is involved in this failure, so authentication or provider routing is not on the failing path.
this is fixed