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

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).

Start in apps/web/src/components/ChatMarkdown.tsx at the file-link anchor renderer and compare it with apps/mobile/modules/t3-markdown-text/src/nativeMarkdownText.ts. Run apps/mobile/src/lib/nativeMarkdownText.test.ts, including the existing ignored-label case. Done means descriptive Markdown labels remain in rendered sentences while file destinations, icons, and line numbers stay accessible in both web and mobile renderers.