Bug: Markdown local file links render percent-encoded non-ASCII paths in transcript output
Open 💬 3 comments Opened Mar 23, 2026 by potato-dumplings
💡 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.318.11754 (1100)
What subscription do you have?
free
What platform is your computer?
Darwin 23.6.0 arm64 arm
What issue are you seeing?
In Codex Desktop transcript output, local markdown file links can display percent-encoded path text (for example %E6... / %C3%9F) instead of decoded UTF-8 characters.
I confirmed this is a rendering-path inconsistency:
- Patch/status (“thinking/status layer”) shows decoded path text.
- Markdown output layer may show encoded path text.
Example:
- Actual (output layer):
/Users/.../docs/random_%C3%9F.md:1 - Expected:
/Users/.../docs/random_ß.md:1
What steps can reproduce the bug?
- Ask Codex to output a markdown local link with an encoded UTF-8 path:
[placeholder](/Users/example/code/codex/docs/random_%C3%9F.md:1)
- Observe the rendered transcript output layer.
- In affected builds, the displayed local path may remain percent-encoded.
Control case (invalid sequence should remain unchanged):[bad](/Users/example/code/codex/docs/%E6%ZZ.md)
What is the expected behavior?
Local markdown file link destinations should be normalized for display:
- Valid
%XXUTF-8 sequences are decoded before rendering. - Invalid percent sequences remain unchanged.
- Output rendering should be consistent with patch/status rendering.
Additional information
I traced, fixed, and validated this in the open-source codebase.
Confirmed cause:
- Non-
file://local link targets were normalized without percent-decoding first in markdown render path. file://handling had decode coverage in URL path handling, but plain absolute local-path branch did not.
Fix applied in both implementations:
codex-rs/tui/src/markdown_render.rscodex-rs/tui_app_server/src/markdown_render.rs
Change summary:
- Decode
%XXpath text before display normalization in non-file://local-link parsing. - Keep fallback behavior: if decoded bytes are not valid UTF-8, return original text.
- Added regression tests in both test files:
file_link_decodes_percent_encoded_path_textfile_link_preserves_invalid_percent_sequences
Validation passed:
cargo test -p codex-tui markdown_render_tests::file_link_cargo test -p codex-tui-app-server markdown_render_tests::file_link_- Manual CLI/TUI check:
/Users/.../random_%C3%9F.md:1renders as/Users/.../random_ß.md:1%E6%ZZremains%E6%ZZ
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Draft PR opened with a scoped fix and regression tests: https://github.com/openai/codex/pull/15816
Confirmed on Windows as well.
I can reproduce the same rendering inconsistency for percent-encoded UTF-8 local paths in transcript output:
%C3%9F)Expected behavior:
%XXUTF-8 sequences decoded for displayIf needed, I can provide app version + exact repro logs from my environment.