[Bug]: Malformed Markdown links from Codex output render as raw text

[coygeek]

Before submitting

• I searched existing issues and found related reports, but this is a distinct malformed-Markdown case.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Run T3 Code with the Codex provider and ask it to report several generated files using Markdown links whose destinations are local paths.
2. Inspect the completed assistant message in the T3 Code conversation.
3. Compare the displayed message with the provider completion payload or persisted assistant text.

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 runner codex-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.

[juliusmarminge]

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/desktop ChatMarkdown and 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.ts passes item.text / item/agentMessage/delta through. trimText only trims whitespace.

• apps/server/src/orchestration/Layers/ProviderRuntimeIngestion.ts concatenates assistant deltas and uses completed detail only as an empty-message fallback. No Markdown rewrite.

• T3 Code’s own Codex citation helper (packages/client-runtime/src/codexFileCitations.ts codexFileCitationMarkdown) 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.ts requires a closed > for the angle-bracket branch:

  /\[[^\]]*]\(\s*(?:<([^>\n]+)>|([^\s)]+))(?:\s+["'][^"']*["'])?\s*\)/g

  The bare-href branch can capture <local/path/file.md, but normalizeMarkdownLinkDestination only 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-citation directives, 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>) when path looks 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 (remove needs-triage)