[Bug]: Chat and composer file chips show a folder icon for files without an extension #17398

Activity

1. juliusmarminge commented on Oct 9, 2026

   

   juliusmarminge

   on Oct 9, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the clear pointer. I haven't reproduced this end-to-end; below is what current main (c9fa1367c) shows for the path you named.

   Kind is guessed from the basename alone

   inferEntryKindFromPath treats a basename with no . as a directory (and a leading-dot name with no second . the same way). Call sites that paint the chip icon from that helper:

   • FileTagChipContent — used by chat Markdown file chips (ChatMarkdown.tsx) and by the live composer mention node (ComposerPromptEditorTiptap.tsx).
   • UserMessageMentionChip for sent @ mentions.

   So LICENSE, Makefile, Dockerfile, and extensionless binaries like ~/.local/bin/some-tool get a folder icon. The same heuristic also classifies common dotfiles such as .gitignore / .env as directories.

   Composer search already knows the real kind, then drops it

   The @ picker builds items with pathKind: entry.kind from workspace path search, and ComposerCommandMenu uses that for the menu icon. On select, only the path is written via serializeComposerFileLink(item.path). The tip-tap composer-mention node stores path + source only (attrs), and MentionContextRecord likewise has no kind field. After insert, the chip re-runs inferEntryKindFromPath.

   Markdown / inline-code chips go through resolveMarkdownFileLinkMeta, which does not attach a kind and does not stat the target. Trailing / (or \) survives into filePath in some cases; basenameOfPath then yields an empty basename and the current heuristic already maps that to directory. File-tree drag mentions strip the trailing slash on purpose, so those directory pills lose that signal.

   Suggested direction

   Prefer, in order:

   1. Keep known kind where it exists — persist pathKind on the composer mention node (and, if worth the schema change, on MentionContextRecord), and pass an optional kind into FileTagChipContent / timeline chips instead of re-inferring. That matches what the picker already shows.
   2. Tighten the path heuristic for chips that have no kind:
      • Treat a trailing / or \ as directory before looking at the basename.
      • Default extensionless basenames to file rather than directory (folders in chat links more often carry a trailing separator, or arrive from search with a real kind). Trade-off: a real folder link without a trailing separator would then show a file icon until something else supplies kind.
      • Optionally reuse the existing EXTENSIONLESS_FILE_NAMES allowlist (already used when deciding whether a path looks like a file) as a middle ground.
   3. The leading-dot branch that marks .gitignore-style names as directories looks worth revisiting at the same time (dotfile vs folder like .git).

   Related

   • #15215 — outside-workspace folder link opens a failing file preview (open behavior, not the icon guess).
   • #5291 (closed) — directory chips dropping the final path segment when a trailing separator was present.
   • #15237 — relative Markdown folder links with a trailing slash not chipping.

   I didn't find a duplicate of this icon mis-guess, or an open PR that changes inferEntryKindFromPath.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 9, 2026
3. Yash-Singh1

   closed this as completedin #17923on Oct 10, 2026