[Bug]: Inline code like `avatars/u1.webp` becomes a file chip labeled `u1.webp` even when the path does not exist#29421

opened8d agobyMmadebyjulz

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

The classifier is inlineCodeFilePathCandidate in packages/shared/src/markdownLinks.ts; the chip label comes from fileLinkLabel in packages/shared/src/fileLinks.ts.

Steps to reproduce

  1. Open any thread.

  2. Have an assistant response use an example storage key or path in inline code, where that path does not exist in the workspace:

    markdown
    1`scope: "global"` (the default) means the key is the pattern as written, for example `avatars/{userId}.webp` gives `avatars/u1.webp`.
  3. Read the rendered message, then click the second span.

Expected behavior

avatars/u1.webp renders as ordinary inline code with its full text. It is an example object key, not a file in the workspace, so it should not be a link — or at least the chip should keep the text the agent wrote.

Actual behavior

The span renders as a file chip with an image icon labeled just u1.webp. The sentence now reads "avatars/{userId}.webp gives 🖼 u1.webp", which drops the avatars/ part and no longer says what the agent wrote. Clicking it opens a preview for <workspace>/avatars/u1.webp, which does not exist.

This happens a lot with docs-style answers: S3 keys, URL paths, example output paths, paths in other repos or on other machines. Any dir/name.ext span in inline code becomes a chip.

Cause

On main @ 47f2c8d29e981c7723467efe137ee19e91df924e:

  • inlineCodeFilePathCandidate accepts any span with a / and an extension on the basename. Nothing checks whether the path exists in the workspace before it becomes a chip.
  • fileLinkLabel then shows only the basename (plus a parent suffix only when basenames collide), so the directory part of what the agent wrote disappears from the sentence.

Possible fixes

  • Only turn inline code into a chip once the path resolves to an existing file (or show unresolved paths as plain inline code).
  • For inline code, keep the written text as the label instead of collapsing it to the basename, as was done for descriptive Markdown link labels in #10787.

Related: #22181 and #13899 (same class: inline code becomes a chip and hides its prefix, triggered there by a :line suffix), #10787 / #28509 (chip labels replacing the text that was written).

Impact

Minor bug or occasional failure

Version or commit

T3 Code desktop, current release (Nov 2026)

Environment

macOS, Claude Code provider

Synced from GitHub

I'd like to work on this. I propose keeping inline-code file chips but preserving the path exactly as written in their labels, so avatars/u1.webp stays avatars/u1.webp, across web, desktop, mobile, and find-in-thread.

This would address the lost text while keeping existing link detection, avoiding filesystem checks during rendering and extra remote latency. Missing paths would still be clickable. Would that direction be acceptable, including preserving absolute paths and :line suffixes as written?

Synced from GitHub

Same issue on T3 Code Desktop 0.1.5 (macOS 26, arm64), local server 0.1.5.

An assistant answer described a convention in inline code: "the ## Markers table in docs/architecture/[stack.md](https://github.com/Users/nicolasklein/.t3/scratch/2026-11-05-read-triage-playbook-md-users-01e78e66/docs/architecture/stack.md)". The path names a file that exists in other projects that follow this convention, but not in the thread's workspace. It rendered as a file chip. Clicking it opened the file preview with "The file could not be accessed or read. It may be missing or inaccessible." for <workspace>/docs/architecture/stack.md.

This one is a docs-style answer about conventions that span projects, so the path is correct, just not for this workspace. If missing paths fell back to plain inline code (as #30021 proposes), this case would be handled.

Triaged with Claude Opus 5.5 in Claude Code via T3 Code triage.