Codex Desktop Markdown preview does not render local images referenced by relative paths

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

26.623.141536 (4753)

What subscription do you have?

Unknown / not relevant

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Codex Desktop's local Markdown file preview renders a local image when the same file is referenced with an absolute local path, but shows broken-image placeholders when the image is referenced with relative paths.

I reproduced this with a synthetic Markdown file and a generic assets/ folder. No private project path or project-specific content is included here.

Actual behavior:

• ![](assets/example.png) shows a broken-image placeholder.
• ![](docs/example/assets/example.png) also shows a broken-image placeholder in my test.
• ![](/Users/<user>/workspace/docs/example/assets/example.png) renders correctly.

This makes normal portable Markdown documents hard to preview in Codex because images are commonly stored next to the document under an assets/ directory.

What steps can reproduce the bug?

1. On macOS, create a local workspace with a Markdown file and image asset:

workspace/
  docs/
    example/
      test.md
      assets/
        example.png

1. In docs/example/test.md, reference the same PNG using a file-relative path:

![](assets/example.png)

1. Also test a workspace-root-style path:

![](docs/example/assets/example.png)

1. Add an absolute-path control:

![](/Users/<user>/workspace/docs/example/assets/example.png)

1. Open/render the Markdown file in Codex Desktop's Markdown preview.

Result: the relative image references render as broken-image placeholders, while the absolute path renders.

What is the expected behavior?

Relative local Markdown image paths should render when they resolve to an existing file, preferably relative to the Markdown file location, matching common Markdown and GitHub behavior.

If workspace-root-relative paths are supported, their base should be documented and applied consistently. The preview should not require absolute, user-specific paths for images stored inside the workspace.

Additional information

I searched related issues before filing. Adjacent but not exact:

• #21510: relative Markdown links resolving from the wrong base.
• #21707: image paths containing spaces.
• #20166: non-ASCII characters in absolute local image paths.
• #14576 and #23878: Windows local/external Markdown image rendering cases.

This report is specifically for macOS local Markdown file preview where the same image renders via an absolute local path but not via relative local Markdown image paths.

Related in-app feedback ID: 019f3745-5173-7d40-9aa4-0901d9855f05