Mac app: local Markdown images fail to render when path contains non-ASCII characters
Summary
In the Codex desktop app on macOS, local Markdown images can render as broken placeholders when the absolute filesystem path contains non-ASCII characters, such as CJK characters.
Why this matters
Codex often needs to return generated local artifacts using Markdown image syntax. When the image preview silently fails, users cannot inspect generated images inside the conversation even though the files themselves are valid and readable on disk.
Example
A Markdown image with a local absolute path like this may show as a broken image placeholder in the chat UI:
The same PNG file is valid and can be opened by local image tools. The issue appears to be in the app's local image rendering/path handling layer rather than in the image file itself.
Reproduction steps
- On macOS, create a PNG under a directory whose path contains non-ASCII characters, for example:
``bash``
mkdir -p /tmp/codex-local-image-repro/中文目录
# create or copy any valid PNG to:
# /tmp/codex-local-image-repro/中文目录/test.png
- Ask Codex to return the image in chat using Markdown with the absolute local path:
``md``
- Observe that the image may appear as a broken placeholder instead of rendering inline.
Expected behavior
The Codex desktop app should render local Markdown images from valid absolute filesystem paths, including paths containing UTF-8 / non-ASCII characters.
Actual behavior
The image preview fails in the chat UI and displays a broken placeholder, while the PNG file itself is valid.
Notes
- Please treat the path above as a synthetic repro path; no user-specific path or project name is included here.
- This may be related to URL/path encoding for local files in the Markdown image renderer.
- A useful control test is to copy the same file to an ASCII-only path and compare rendering behavior.
Related issues that may share path-handling code
- #14576
- #15463
- #17548
- #17992
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗