[Bug]: File-link chips discard descriptive Markdown labels and remove sentence content

[gfdelarue]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Also affects the mobile Markdown renderer. Desktop uses the web renderer.

Steps to reproduce

1. Open a thread in a project containing a source file.

2. Have an assistant response contain a Markdown link whose label is descriptive prose, using that file's absolute path as the destination. For example, with an existing /repo/src/example.ts:

   This function [validates the input](/repo/src/example.ts:12).

3. Read the rendered sentence in the transcript.

For a deterministic renderer-level reproduction, pass that Markdown as text to ChatMarkdown with cwd="/repo".

Expected behavior

The sentence retains validates the input, and the file destination remains accessible. File icons, line numbers, and destination disambiguation should not replace meaningful link text.

Actual behavior

The descriptive label is replaced by a filename chip. The sentence becomes approximately:

This function example.ts · L12.

The original observation was a sentence containing the linked phrase the server explicitly combines the question and your answer. The UI replaced that whole phrase with decider.ts · L1096, leaving the sentence incomplete.

A read-only inspection of the stored assistant message confirmed that the descriptive label was still present in the original Markdown. The content loss occurs during rendering.

Impact

Minor bug or occasional failure

This removes meaningful sentence content, rather than only changing styling.

Version or commit

Source verified at 061543e9e5b54ec0048725c37d52fef2962df173, which matched upstream main when checked. The exact installed version behind the original observation was not recorded.

Environment

Observed in the T3 chat UI. Source inspection confirms the behavior in web/desktop and the shared mobile Markdown renderer used by iOS and Android. The behavior is independent of provider. Exact browser/desktop versions were not recorded; no new browser or simulator run was performed.

Supporting evidence

• The web anchor renderer replaces the original label with a file chip.
• The chip label is built from the basename and position, without the original link children.
• The mobile renderer similarly replaces file-link children with presentation.label.
• The existing mobile test explicitly replaces an ignored label with a filename. That focused test passed: 1 passed, 34 skipped.

Related closed issue #353 asks for visible, distinguishable file destinations. This report concerns losing descriptive prose; a fix should preserve destination visibility. The current head of open PR #10236 was also checked and retains this label replacement.

Workaround

Keep meaningful prose outside file links and use filename-only labels. For example:

This function validates the input. See [example.ts](/repo/src/example.ts:12).

[juliusmarminge]

Triage

Confirmed. This is renderer-only content loss on current main (061543e). The stored assistant Markdown still has the descriptive label; both chat renderers throw it away and print a filename chip instead.

This function [validates the input](/repo/src/example.ts:12). becomes This function example.ts · L12.

What the code does

Web MarkdownAnchor in apps/web/src/components/ChatMarkdown.tsx recognizes a file href and calls fileLinkChip without children. The chip label is basename plus optional parent suffix and L#. Copy is rewritten to [basename](href) as well.

Mobile does the same in two places:

• Native: nativeMarkdownText.ts uses resolveMarkdownLinkPresentation(href).label (basename + position) and never walks link children for file links.
• JS fallback: ThreadFeed.tsx also renders presentation.label.

apps/mobile/src/lib/nativeMarkdownText.test.ts currently expects "ignored label" → "README.md:12". That test will need to change with the fix.

Inline-code auto-chips (`example.ts:12`) are a different path and should stay filename-based.

Related, not a duplicate

• Markdown file links are ambiguous and hide their destination #353 asked for visible, distinguishable file destinations. Improve markdown file link UX #1956 added chips for that. A fix here should keep destination visibility (icon, tooltip, line, parent suffix) and only stop replacing meaningful link text.
• [Bug]: File links in agent output always resolve against the thread's project, not the repo the file is in #10553 is wrong-project path resolution.
• feat(web): unify context chip presentation and previews #10236 still replaces file-link labels. Do not treat it as the fix.

Suggested fix

When the authored label is already the basename, a path, or file:line, keep the current chip. When it is other prose, render that text and attach the destination (icon / tooltip / line / adjacent chip) so the sentence stays intact.

Cover web + desktop (ChatMarkdown) and both mobile renderers. Update the mobile “ignored label” test.

Workaround still holds: put the prose outside the link and use a filename-only label.

Labels: bug, via-triage, accepted (remove needs-triage)