Repository navigation
[Bug]: Malformed Markdown links from Codex output render as raw text #11810
Description
Activity
Triage
Confirmed as a distinct malformed-source case, not a replay of closed #5158.
Codex-backed assistant text can persist as
[file](<local/path/file.md)— opening<, no closing>before). CommonMark then does not parse a link, so web/desktopChatMarkdownand the mobile Markdown renderer show the raw brackets and path.The reporter already compared the chat text with the Codex completion payload and the stored transcript. That matches the code: the adapter and projector do not strip
>.What the code does
-
apps/server/src/provider/Layers/CodexAdapter.tspassesitem.text/item/agentMessage/deltathrough.trimTextonly trims whitespace. -
apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.tsconcatenates assistant deltas and uses completeddetailonly as an empty-message fallback. No Markdown rewrite. -
T3 Code’s own Codex citation helper (
packages/client-runtime/src/codexFileCitations.tscodexFileCitationMarkdown) always emits[label](<href>)with the closing>. If the stored text is missing>, it did not come from that helper. -
File-link pre-scan in
apps/web/src/markdown-links.tsrequires a closed>for the angle-bracket branch:/\[[^\]]*]\(\s*(?:<([^>\n]+)>|([^\s)]+))(?:\s+["'][^"']*["'])?\s*\)/gThe bare-href branch can capture
<local/path/file.md, butnormalizeMarkdownLinkDestinationonly unwraps destinations that have both<and>. react-markdown still never builds a link node, so the chip path never runs.
Well-formed
[file](<local/path/file.md>)already renders as a file chip after #6439 / #8081 / #8584. This report is the missing closer in the source.Related, not a duplicate
- [Bug]: Markdown file links break when the destination uses angle brackets or contains parentheses #5158 / fix(web): command-click spaced folder links #6439 / fix(web): make Windows file links clickable in chat #8081: classification of valid angle-bracket and Windows destinations.
- [Bug]: Local file links in chat render as raw markdown, not clickable, and files cannot be previewed in-app #7554: same “raw local Markdown link on Codex” symptom; closed after well-formed links worked. This missing-
>source is a likely remaining cause. - [Bug]: Codex artifact citations render as raw codex-file-citation markup #5813 / fix(web,mobile): render Codex citations and artifact templates #8584:
:codex-file-citationdirectives, not this link form. - [Bug]: File-link chips discard descriptive Markdown labels and remove sentence content #10787: chips replacing descriptive labels after a successful parse.
- Open fix(chat): render Codex source citations #9605: Codex source-citation markers, not file destinations.
No open or merged PR repairs unclosed
](<path)destinations.Suggested fix
Keep stored transcripts as the provider sent them. Repair at render time in shared client-runtime (web
ChatMarkdown+ mobile):- Close
[label](<path)→[label](<path>)whenpathlooks like a local file/folder and the>before)is missing. - Cover the reporter’s example, spaces, Windows drive paths, and list items.
- Do not touch well-formed
](<path>)or real HTML.
Also worth tracking upstream against Codex CLI
0.154.0, since the broken string is already in the completion payload.Workaround still holds: copy the path, add the missing
>, open the file outside the conversation.Labels:
bug,accepted,upstream,via-triage(removeneeds-triage)-
- added a commit that references this issue
on Oct 4, 2026
Before submitting
Area
apps/web
Steps to reproduce
Expected behavior
Valid Markdown links should be preserved and rendered as clickable links. A link such as
[file](<local/path/file.md>)should retain the closing>and render as a file link or a clear plain-text fallback.Actual behavior
The completed message can contain a link such as
[file](<local/path/file.md)with the closing>missing before). The bracketed label and destination are then shown literally instead of as a clickable link.Affected area
Assistant-message persistence and Markdown rendering for Codex-backed conversations, especially local-file links using angle-bracket destinations.
Impact
Users cannot open generated local files directly from the assistant response and must manually reconstruct the path. Lists containing many affected links become difficult to scan.
Version or commit
T3 Code Nightly
0.0.41-nightly.20260914.1707; Codex CLI runnercodex-cli 0.154.0.Environment
Codex provider. The same malformed string was observed in the provider completion payload and the persisted T3 Code transcript, so the exact internal owner may be provider output formatting or T3 Code message normalization.
Evidence
A screenshot shows the raw bracketed Markdown and destination text instead of a rendered link. The persisted transcript and provider completion notification contain the same missing
>character.Workaround
Manually copy and repair the path, then open the file outside the conversation.