›_ Codex Issues
Codex Issues / #14576

Windows desktop app does not render local markdown images from absolute drive-letter paths

Open 💬 3 comments Opened Mar 13, 2026 by cz-bszy
💡 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?

Windows desktop app. I did not capture the exact build number before filing this report.

What subscription do you have?

Pro

What platform is your computer?

Windows

What issue are you seeing?

Local image references in assistant responses do not render correctly in the Codex desktop app on Windows, even when the file exists and the assistant uses an absolute local path.

In my case, the assistant returned markdown like:

![client preview](/E:/Test/novel-writing-platform/docs/home-client-preview.png)

The PNG file was present on disk, but the app displayed a broken image placeholder instead of the actual image.

In the same session, absolute local file links were also not clickable/openable from the UI. There is already a separate Windows path issue for broken local file links, but image rendering appears to be a separate symptom because the app fails before even showing the image preview.

What steps can reproduce the bug?

  1. Use Codex desktop app on Windows.
  2. Ask the assistant to save a screenshot or image to a local path inside the workspace.
  3. Have the assistant respond with markdown using an absolute local path, for example:
![preview](/E:/path/to/file.png)
  1. Observe that the image does not render in the chat UI.

What is the expected behavior?

If the file exists and the assistant returns a valid absolute local path in markdown image syntax, the image should render inline in the desktop app.

Additional information

  • The file did exist on disk.
  • The problem was observed on Windows with a drive-letter path.
  • A related symptom in the same environment is that local file links in assistant messages are not always clickable/openable.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #14079
  • #14483
  • #13548
  • #13656

Powered by Codex Action

0okay · 4 months ago

I can reproduce a closely related issue in the Codex Windows desktop app, but in my case it happens in the Markdown file preview tab, not only in assistant chat responses.

Environment:

  • Codex desktop app on Windows 11
  • Workspace path is on an E: drive
  • The Markdown files and images are inside the same workspace
  • The workspace path contains spaces and non-ASCII characters, but I also tested ASCII-only copied image paths inside a local assets folder

What I tested:

  1. Markdown image links using Windows-style relative paths:
![](..\OCR全文\D1_DE8617599U1_Ice_hockey_puck_images\D1_DE8617599U1_Ice_hockey_puck_img_001.jpg)

Result: broken image placeholder.

  1. Markdown image links using URL-style relative paths:
![](../OCR全文/D1_DE8617599U1_Ice_hockey_puck_images/D1_DE8617599U1_Ice_hockey_puck_img_001.jpg)

Result: broken image placeholder.

  1. Markdown image links after copying the image files next to the Markdown files under an ASCII-only local assets folder:
![](assets/D1/img_001.jpg)

Result: broken image placeholder.

  1. Markdown image links using absolute file:/// URLs:
![](file:///E:/path/to/workspace/assets/D1/img_001.jpg)

Result: broken image placeholder.

  1. The same Markdown content with images embedded as data:image/jpeg;base64,... reference definitions.

Result: images render successfully in the Codex Markdown preview.

  1. A generated HTML version using the same assets/D1/img_001.jpg relative paths.

Result: images open correctly in a normal browser.

So this seems broader than just drive-letter absolute paths. The Codex Windows Markdown preview appears unable or unwilling to resolve local image resources from Markdown files, even when:

  • the image exists on disk,
  • the image is inside the workspace,
  • the path is relative to the Markdown file,
  • the path is ASCII-only,
  • and the same asset path works in a browser-rendered HTML file.

Expected behavior:

  • At minimum, Markdown preview should render workspace-contained relative images such as ![](assets/D1/img_001.jpg) relative to the Markdown file location.
  • Ideally, it should also handle valid file:/// image URLs or convert them to whatever safe local-resource URI the desktop app/webview requires.

Why this matters:

This is a common workflow for documentation, patent/technical reports, OCR outputs, and generated Markdown artifacts. The only reliable workaround I found is embedding images as base64 data URIs, but that makes otherwise small Markdown files very large and difficult to edit or review.

ChrisMcSomething · 4 months ago

I was having this issue in Codex Desktop and resolved it by asking it to give me inline images using the correct path format below, I put it both in the system prompt and it saved it to Codex memory after I asked it to.

This did not render for me:

![Screenshot](<C:\Users\Name\Pictures\Screenshots\my screenshot.png>)

But this did render:

![Screenshot](C:/Users/Name/Pictures/Screenshots/screenshot.png)

So the working format seems to be:

![alt text](C:/path/to/image.png)

Key differences:

  • use the drive letter directly, like C:/...
  • use forward slashes instead of backslashes
  • don’t wrap the image path in angle brackets
  • if the path has spaces, try renaming/copying it to a no-spaces path first

Hope that helps narrow it down.