fix(vscode): support filenames with spaces and unicode in @mentions#11977
Conversation
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
| * `my folder/report q1.xlsx`. The second alternative handles slash-based paths. | ||
| * This regex is the fallback used only when no source position data is available. | ||
| */ | ||
| const MENTION_RE = /@((?:[\w./-]+ )*[\w./-]+\.[\w]+|[\w.-]+\/[\w./-]+)/g |
There was a problem hiding this comment.
WARNING: Broadened fallback regex can over-match ordinary prose, not just file mentions
The new first alternative (?:[\w./-]+ )*[\w./-]+\.[\w]+ is used by detect() whenever a message has zero refs with position data — i.e. for every plain-text message without a file/agent attachment, not just legacy mentions. Because the repeated group has no upper bound on how many space-separated words it can swallow before the final name.ext token, any @ followed eventually by a decimal number or dotted token later in the same sentence gets pulled into the match.
Example: "@support team for v2.0 details" matches the whole span @support team for v2.0 as a highlighted "file" mention, even though only v2.0 looks vaguely file-like and nothing here is an actual attachment. This will render as an incorrect highlighted/clickable chip around unrelated prose in normal chat messages.
Consider bounding the number of space-separated segments (e.g. {0,2} instead of *), or only applying the space-tolerant alternative when there is some other signal (e.g. an actual space-containing path in mentionedPaths) rather than as a blanket regex over all plain text.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
| for (const path of mentionedPaths) { | ||
| if (text.includes(`@${path}`)) { | ||
| const token = `@${path}` | ||
| const idx = text.indexOf(token) |
There was a problem hiding this comment.
WARNING: Repeated mentions of the same path in one message only highlight the first occurrence
mentionedPaths is a Set<string>, so each distinct path produces at most one FileAttachment, and idx = text.indexOf(token) always resolves to the first occurrence of @path in the text. If the same file is mentioned twice in one message (e.g. "see @foo.ts and again @foo.ts"), only the first @foo.ts gets a source.text position; the renderer's resolve() in message-highlight.ts has no second ref to relocate for the duplicate, so the second occurrence stays as plain text instead of being highlighted.
Before this change, highlighting for messages without space-containing mentions relied entirely on detect()'s regex fallback, which highlights every occurrence via matchAll. So this is a real (if narrow) behavior regression for the duplicate-mention case, traded for fixing the primary space/Unicode bug. Worth a look if duplicate mentions in a single message are a supported/expected scenario.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Incremental review of the latest commit ( Files Reviewed (5 files)
Previous Review Summaries (6 snapshots, latest commit b793d57)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit b793d57)Status: No Issues Found | Recommendation: Merge The previously flagged ASCII-only Files Reviewed (2 files)
Previous review (commit 28175b2)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (2 files)
The previously reported whitespace-only boundary check issue (repeats adjacent to punctuation losing their highlight) is resolved in Fix these issues in Kilo Cloud Previous review (commit 55c5879)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (2 files)
The previously reported prefix-collision issue ( Fix these issues in Kilo Cloud Previous review (commit 44bea91)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (2 files)
Both previously reported issues (over-matching fallback regex; duplicate mentions losing highlighting) are resolved in Fix these issues in Kilo Cloud Previous review (commit 72c4d10)Status: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (5 files)
Fix these issues in Kilo Cloud Previous review (commit 5d8c84b)Status: 2 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (4 files)
Reviewed by claude-sonnet-5-20260630 · Input: 48 · Output: 11.4K · Cached: 1.5M Review guidance: REVIEW.md from base branch |
|
Addressed both review issues in 44bea91: 1. Over-matching regex — Reverted 2. Duplicate mentions losing highlighting — Since Added tests for both: over-matching prevention ( |
| // text for exact repeats of this ref's mention text so every occurrence | ||
| // stays highlighted, not just the first. | ||
| let repeat = text.indexOf(next.source.value, index) | ||
| while (repeat !== -1) { |
There was a problem hiding this comment.
WARNING: Repeat-search can bleed into a different, later mention when one mention's text is a prefix of another's
text.indexOf(next.source.value, index) does a plain substring search with no boundary check. If a later, distinct mention's text has next.source.value as a literal prefix (e.g. @a.ts mentioned once, and @a.tsx mentioned later in the same message — a common collision in TS/TSX codebases), this loop matches @a.ts inside @a.tsx, pushing a bogus {start, end} range that only covers @a.ts and advances index past part of the real @a.tsx occurrence.
When @a.tsx appears before any duplicate of @a.ts, the subsequent locate() call for the a.tsx ref then fails to find its own text after that corrupted index, so the real @a.tsx mention is dropped entirely and rendered as a wrong @a.ts chip followed by a stray plain x.
Consider requiring a non-word boundary after the match (e.g. check text[end] is not \w before treating it as a repeat), or track already-claimed ranges instead of relying purely on index position.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
|
Addressed in 55c5879. Prefix-collision bug in repeat-mention search — Confirmed the issue: the plain Fixed by requiring each repeat candidate to be flanked by whitespace or a string edge on both sides before accepting it — the same token-boundary convention already used in |
| if (found === -1) break | ||
|
|
||
| const end = found + value.length | ||
| const before = found === 0 || /\s/.test(text[found - 1] ?? "") |
There was a problem hiding this comment.
WARNING: Boundary check requires literal whitespace, so repeats followed/preceded by punctuation lose their highlight
before/after only accept whitespace or a string edge as the token boundary. This fixes the prefix-collision case, but it's stricter than the token definition detect()/MENTION_RE uses elsewhere (word chars, ., /, -), so it silently drops legitimate repeats that are adjacent to punctuation rather than whitespace — e.g. a second mention at the end of a sentence ("... again @file.ts.") or inside parentheses ("(@file.ts)" following an earlier mention) won't satisfy the whitespace check and will be rendered as a plain, unhighlighted repeat even though it's the exact same mention text.
Consider testing for "not a continuation character" (e.g. !/[\w./-]/.test(...)) instead of "is whitespace", matching the boundary semantics MENTION_RE already uses — that still blocks @a.ts from matching inside @a.tsx (x is a continuation char) while allowing repeats followed by ., ,, ), etc.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
|
Addressed in 28175b2. Over-strict punctuation rejection — Confirmed: the whitespace-only boundary check from Replaced the boundary condition with a path-continuation check matching Added tests for: a repeat followed by a comma, a sentence-ending period, a closing paren, and the compound-extension collision case (to confirm the original fix's intent is preserved, not just relaxed away). |
| // Word characters, slashes, and hyphens unambiguously continue a path token. | ||
| // A dot is handled separately (see continuesPath) since it is both a common | ||
| // sentence-ending character and a path/extension separator. | ||
| const PATH_CONTINUATION = /[\w/-]/ |
There was a problem hiding this comment.
WARNING: ASCII-only \w boundary check reintroduces the prefix-collision bug for non-ASCII filenames
PATH_CONTINUATION (and continuesPath, which reuses it) is /[\w/-]/ without the u flag, so \w only matches [A-Za-z0-9_]. Any Unicode letter — Cyrillic, CJK, etc. — is not recognized as a continuation character, even though such characters are exactly what this PR adds support for.
Concretely: if a message mentions two distinct files файл.txt and файлы.txt (each gets its own source.text ref via buildFileAttachments), repeats() for the shorter @файл.txt ref will happily match the literal prefix @файл.txt inside the later, unrelated @файлы.txt occurrence — text[end] is ы, which PATH_CONTINUATION.test("ы") reports as false, so after is true and the bogus repeat is accepted. This is the same @a.ts/@a.tsx collision this file's repeats() was specifically written to prevent (see the existing regression test), just reintroduced for non-ASCII paths — the shorter mention's highlight bleeds into the longer, distinct mention, and resolve()'s index then advances past part of the real файлы.txt occurrence, corrupting or dropping its own highlight.
Consider adding the u flag and switching to a Unicode-aware character class (e.g. /[\w/-]/u still won't fix it by itself since \w is defined as ASCII-only even under u; something like /[\p{L}\p{N}_/-]/u is needed) so continuation detection works consistently for the Unicode filenames this PR targets.
Reply with @kilocode-bot fix it to have Kilo Code address this issue.
|
Addressed in b793d57. ASCII-only Replaced Added regression tests for a Cyrillic collision ( |
|
Hi @sylwester-liljegren. Thanks for the contribution, can you establish if those are worth fixing? I would also love to keep the change minimal since this is just a small improvement, can you confirm that this is the minimal path to achieve our follow up? Blocking: rebase required before merge. The PR is DIRTY against main, with conflicts in packages/kilo-vscode/webview-ui/src/hooks/file-mention-utils.ts and packages/kilo-vscode/webview-ui/src/hooks/useFileMention.ts. Current main added file-picker support, bidi caret handling, and, critically, workspace-containment checks for attachments. Resolving buildFileAttachments by taking the PR version around file-mention-utils.ts:175 would remove the containment guard and risk restoring the external-file permission-bypass path. The rebase must retain normalization and isInsideWorkspace() checks, then add the new source metadata and URL handling on top. Medium: repeated mentions hide a different mention between them. packages/kilo-ui/src/components/message-highlight.ts:129-132 finds all later repetitions of the first ref and advances the shared cursor to the last repetition before resolving subsequent refs. For @a.ts @b.ts @a.ts, the second @a.ts advances index past @b.ts, so @b.ts is rendered as plain text. I reproduced this against the PR head. Add a regression test with interleaved duplicate and distinct file/agent refs. Medium: prefix protection fails for valid space-containing filenames. packages/kilo-ui/src/components/message-highlight.ts:105-107 treats whitespace as a valid token boundary. With both a.txt and a.txt backup.txt attached, @a.txt @a.txt backup.txt renders the second mention as a chip for @a.txt followed by unhighlighted backup.txt. The new feature explicitly supports spaces within paths, so a space cannot always indicate the end of a distinct mention. I reproduced this against the PR head. Medium: literal percent-encoded-looking filenames resolve to the wrong file. packages/kilo-vscode/webview-ui/src/hooks/file-mention-utils.ts:193 only replaces spaces before assigning pathname. For a real filename such as 100%20real.txt, the produced URL includes %20, and Bun.fileURLToPath() decodes it to 100 real.txt. URL construction must escape literal percent signs as well as spaces, ideally by encoding path segments rather than selectively replacing spaces. Add a test that round-trips a filename containing literal %20. |
|
Hi @marius-kilocode , I think it is worth it. I'll look into this and I'll let you know when this PR is ready for you to review. |
Two bugs prevented @mentions from working correctly when filenames contained spaces or non-ASCII characters: 1. Sent-message highlighting broke for paths with spaces. buildFileAttachments did not set source.text position data on file attachments, so the renderer fell back to MENTION_RE which uses [\w./-] and stops at whitespace. Now source.text is computed via text.indexOf and included in the attachment. The renderer's resolve() path uses source.value with indexOf, which handles spaces and any Unicode correctly. 2. Server read failed with 'File not found' for paths with spaces. VS Code's webview (Chromium) does not percent-encode spaces when setting url.pathname on a file:// URL. The resulting literal space in url.href caused Bun's fileURLToPath to truncate the resolved path at the first space. Spaces are now pre-encoded as %20 before assignment. Additionally, MENTION_RE in message-highlight.ts is updated to match filenames that include space-separated segments (e.g. 'org data.xlsx') as a fallback for messages that pre-date this fix and therefore lack source.text data.
Two issues flagged by review: 1. The broadened MENTION_RE fallback regex over-matched ordinary prose. A pattern permissive enough to span space-separated path segments also swallows text following any unrelated @mention up to the next dotted/versioned token (e.g. '@agent check report for v1.2 details' highlighted the entire span through 'v1.2'). Reverted MENTION_RE to its original conservative form; the primary fix for space/unicode filenames does not depend on it; it now relies on source.text data computed in buildFileAttachments and resolved via exact text search. 2. Repeated mentions of the same path in one message only highlighted the first occurrence. mentionedPaths is a Set, so buildFileAttachments produces exactly one ref per unique path regardless of how many times it appears in the text. Once that ref carries source.text, resolve() was used instead of the old regex-based detect() fallback, which used to independently highlight every occurrence via a global regex scan. resolve() now also searches the remaining text for exact repeats of each ref's resolved mention value, so every occurrence of a path stays highlighted, not just the first. Added tests covering: over-matching prevention, repeated plain mentions, and repeated mentions containing a space.
The repeat-mention search added in 44bea91 used a plain substring indexOf, which let a shorter mention's value match as a literal prefix of a longer, distinct mention that starts the same way (e.g. '@a.ts' matches inside '@a.tsx'). This truncated the longer mention's highlight to just its prefix and dropped its own ref from being located. Repeats are now only accepted when flanked by whitespace or a string edge on both sides, matching the same token-boundary convention already used elsewhere (syncMentionedPaths' (?:^|\\s)@path(?:\\s|$) pattern). Added a regression test for the exact a.ts/a.tsx collision case.
The whitespace-only boundary check added in 55c5879 to prevent '@a.ts' from falsely matching inside '@a.tsx' was stricter than necessary: it required literal whitespace on both sides, so a repeated mention directly followed by ordinary punctuation (a trailing comma, sentence-ending period, or closing paren) silently lost its highlight. Replaced the whitespace check with a path-continuation check matching MENTION_RE's own character class (word chars, dot, slash, hyphen). A repeat is now rejected only when the adjacent character could extend it into a longer, different path. The dot is handled with one character of lookahead: it counts as a continuation only when another word character follows (e.g. '@report.csv' + '.bak'), so a lone trailing sentence period does not block highlighting, while a genuine compound-extension collision still correctly does. Added tests for: repeat followed by a comma, a sentence-ending period, a closing paren, and a compound-extension collision that must still be rejected (@report.csv inside @report.csv.bak).
PATH_CONTINUATION and continuesPath used \w, which in JavaScript regex
matches ASCII letters/digits only. A Cyrillic or CJK mention (e.g.
'@файл') was therefore not recognized as continuing into a longer,
distinct mention that starts the same way (e.g. '@файлы'), silently
reintroducing the same collision the check exists to prevent (the
@a.ts/@a.tsx case) specifically for the non-ASCII paths this PR is
meant to support.
Replaced \w with Unicode property escapes (\p{L}, \p{N} with the u
flag), which correctly recognize any Unicode letter or digit as a
continuation character, not just ASCII ones.
Added regression tests for a Cyrillic prefix collision (@файл inside
@файлы) and a CJK one (@文件 inside @文件夹), both verified to fail
against the prior ASCII-only implementation.
Reverting to a message with a space-containing @mention, then resending the same text, reproduced the 'File not found' truncation error even after the buildFileAttachments/URL-encoding fix, because the revert path uses a different, unrelated mechanism to reconstruct known mention paths. Revert restores the original message's text into the input via a setChatBoxMessage window message, which PromptInput handles by calling seedFromText(text). seedFromText re-derives candidate mention paths from raw text with a regex (the same conservative, space-free pattern as MENTION_RE) — for '@mention-test/my quarterly report.txt' its slash alternative matches only 'mention-test/my', stopping at the first space. That truncated candidate is then added to knownPaths and, critically, passes syncMentionedPaths' own boundary check too: a real space genuinely follows 'my' in the full filename, so the truncated candidate looks like a complete, validly-bounded mention from the regex's perspective. The truncated path then ends up in mentionedPaths alongside the real one, and buildFileAttachments builds a second, broken attachment for it, producing the same truncated 'File not found: ...\mention-test\my' error alongside a correct read of the real file. Fix: revertSession() now also extracts the reverted message's file parts' exact source.path values (recorded by the earlier buildFileAttachments fix) and sends them alongside the restored text. PromptInput's setChatBoxMessage handler seeds these exact paths directly via a new seedFromParts() function instead of falling back to seedFromText's regex re-derivation, when they're available. seedFromParts skips the flawed candidate-discovery step entirely and just prunes the known-good paths against the current text, so it can't reintroduce the truncation. seedFromText itself is left unchanged and still used as a fallback for callers without exact path data (native undo restoring a draft, or messages sent before source.path existed) — broadening its regex to handle spaces was already tried and reverted elsewhere in this PR because it causes ordinary prose to be over-matched. Added tests: a regression test locking in seedFromText's known limitation (so future refactors don't silently 'fix' it in a way that goes unnoticed), and coverage for seedFromParts handling a space-containing path correctly, pruning stale paths, and seeding multiple paths.
…ncoding - Rework message-highlight.ts's resolve()/repeats() to locate each ref independently and track claimed ranges, instead of threading a single moving cursor through every ref. Fixes an interleaved-mentions bug where locating a later repeat of one mention (e.g. the second `@a.ts` in `@a.ts @b.ts @a.ts`) could advance past and hide a distinct mention (`@b.ts`) that sits between the repeats. - Reject a repeat match when it is a literal prefix of another known ref's exact mention text, not just when the following character looks like a generic path-continuation character. A trailing space can no longer be assumed to end a mention now that paths may contain spaces, so `@a.txt @a.txt backup.txt` no longer truncates the second, longer mention. - Escape literal percent characters (in addition to spaces) before assigning to the file:// URL's pathname in buildFileAttachments, so a real filename like "100%20real.txt" round-trips correctly instead of being decoded as "100 real.txt" server-side.
sylwester-liljegren
force-pushed
the
fix/file-mention-spaces-unicode
branch
from
6bf4ce0 to
cbdb2b1
Compare
…-containing paths syncMentionedPaths tested each known path independently with a boundary regex that treated any whitespace after "@path" as proof the mention ends there. That assumption broke once paths can contain spaces: a stale, unrelated "a.txt" from an earlier mention would incorrectly survive pruning whenever the current text also mentions the longer, distinct "a.txt backup.txt", since a real space genuinely follows "a.txt" as part of that longer path. The stale path would then get re-attached via buildFileAttachments, silently reading the wrong file's contents. Track already-accepted (longest-first) matches and reject a candidate occurrence when it's a literal prefix of one of them at the same text position, mirroring the same fix already applied to message-highlight.ts's repeat-mention detection.
|
@marius-kilocode , I have updated the PR now. You may look into this PR now if you would like to. |
|
Thanks @sylwester-liljegren. It looked good, I merged it! |
2 participants
Issue
Stumbled previously upon some cases while using @mentions, where the handling of whitespaces/special letters weren't properly handled, hence the creation of this PR.
Context
File
@mentionsin the chat input did not work correctly when filenames contained spaces (e.g.org data.xlsx) or non-ASCII characters (e.g.файл.txt,文件.txt). Two separate bugs were responsible:Highlight disappeared in the sent message. The full
@mention-test/org data.xlsxappeared highlighted while typing, but after sending only@mention-test/orgstayed highlighted anddata.xlsxrendered as plain text.Server returned "File not found" for paths with spaces. When sending a message with a space-containing mention, the extension generated an invalid
file://URL with a literal space instead of%20. Bun'sfileURLToPathparsed this malformed URL and truncated the resolved path at the first space (e.g.mention-test\myinstead ofmention-test\my quarterly report.txt), causing aReadToolfailure.Review also surfaced a related, pre-existing gap: mentioning the same file twice in one message only kept the first occurrence highlighted. That's fixed here too, alongside two edge cases the fix itself introduced (see below).
Manual testing also turned up a third, related bug: reverting to a message with a space-containing mention and resending it reproduced the same "File not found" truncation, even with bugs 1 and 2 already fixed — through a completely different code path (see Bug 3 below).
Implementation
Bug 1 — rendering truncation for mentions with spaces or non-ASCII characters
buildFileAttachmentspreviously returned attachments withoutsource.textposition data.buildHighlightedTextSegmentsinmessage-highlight.tschecks for refs with position info; finding none, it fell back toMENTION_REdetection. That regex uses[\w./-]character classes which stop at whitespace, so@org data.xlsxmatched nothing and rendered as plain text.Fix:
buildFileAttachmentsnow computes the exact character positions of each mention viatext.indexOf(token)and includes them assource.texton the attachment. The server stores this, and the renderer'sresolve()path usestext.indexOf(source.value), which handles spaces and all Unicode correctly.MENTION_REitself is left in its original, conservative form (no space handling) — it's only a fallback for messages sent before this fix that lacksource.text, and broadening it to span spaces was tried and reverted during review because it made the fallback swallow ordinary prose following any unrelated@mention(e.g.@agent check the report for v1.2 detailswould highlight the entire span throughv1.2).Bug 2 — URL encoding
VS Code's webview (Chromium) does not percent-encode spaces when assigning to
url.pathnameon afile://URL, despite this being required by the URL spec. The resulting literal space inurl.hrefcaused Bun'sfileURLToPathon the server side to silently truncate the path at the first space character.Fix: spaces are explicitly pre-encoded as
%20before assignment tourl.pathname. Other non-ASCII characters (Cyrillic, Chinese, etc.) are correctly encoded by the URL class, so only spaces need this explicit treatment.Repeated-mention highlighting
mentionedPathsis aSet<string>, sobuildFileAttachmentsproduces exactly one ref per unique path even when it's mentioned more than once in the same message — previously the second occurrence just fell through toMENTION_RE's regex-baseddetect(), which found every regex match independently; oncesource.textmaderesolve()the active path instead, only the first occurrence located.Fix:
resolve()now also searches the remainder of the text for repeats of each ref's exact mention value. Doing this correctly needs a boundary check, not a plain substring search — a naive one would let a shorter mention match as a literal prefix of a longer, distinct one that starts the same way (@a.tsinside@a.tsx, or@report.csvinside@report.csv.bak), truncating the longer mention's own highlight. The boundary check accepts a repeat only when the adjacent character couldn't extend it into a longer path — ordinary punctuation (comma, sentence-ending period, closing paren) is fine, but a word character, slash, hyphen, or a dot followed by another word character is treated as a continuation and rejected. The character class used is Unicode-aware (\p{L}/\p{N}, not\w, which is ASCII-only in JavaScript regex), so the same collision protection applies to Cyrillic and CJK mentions, not just ASCII ones.Bug 3 — mention truncation after revert-and-resend
Reverting to a message that had a space-containing
@mention, then resending the same text, reproduced the "File not found" truncation error again, through a mechanism unrelated to bugs 1 and 2.Revert restores the original message's text into the input via a
setChatBoxMessagewindow message.PromptInputhandled this by callingseedFromText(text), which re-derives candidate mention paths from the raw text using a regex — the same conservative, space-free pattern asMENTION_RE. For@mention-test/my quarterly report.txt, its slash-based alternative matches onlymention-test/my, stopping at the first space (no extension is required for that alternative, so it doesn't even need a dot to match). That truncated candidate is then added toknownPathsand, critically, passessyncMentionedPaths' own boundary check too — a real space genuinely followsmyin the full filename, so the truncated candidate looks like a complete, validly-bounded mention from the regex's perspective. It ends up inmentionedPathsalongside the real, full path, andbuildFileAttachmentsbuilds a second, broken attachment for it — producing the same truncatedFile not found: ...\mention-test\myerror alongside a correct read of the real file.Fix:
revertSession()now also extracts the reverted message's file parts' exactsource.pathvalues (recorded by the Bug 1 fix) and sends them alongside the restored text.PromptInput'ssetChatBoxMessagehandler seeds these exact paths directly via a newseedFromParts()function instead of falling back toseedFromText's regex re-derivation, when they're available.seedFromPartsskips the flawed candidate-discovery step entirely and just prunes the known-good paths against the current text, so it can't reintroduce the truncation.seedFromTextitself is left unchanged and still used as a fallback for callers without exact path data (native undo restoring a draft, or messages sent beforesource.pathexisted).Screenshots / Video
The repeated-mention, boundary-check, and revert-resend fixes are covered by unit tests rather than a distinct visual state beyond what's shown above — they correct edge cases (duplicates, prefix collisions, punctuation, Unicode, revert/resend) in the same highlighting and file-resolution behavior.
How to Test
Manual/local verification
Create test files and mention them via the autocomplete dropdown in the chat:
For each file, type
@in the chat input, select the file from the dropdown, and send:Expected: the full path is highlighted as a single mention chip in the sent message, the agent reply references the correct secret value, and no "File not found" error appears.
Reviewer test steps
bun run extension).@in the chat input and select a file with spaces in its name from the autocomplete dropdown.@path/with spaces.extis highlighted as one chip in the sent message bubble.File not founderror box appears.@file.tswith the older@file.ts,please") and confirm both occurrences stay highlighted, including one directly followed by punctuation.File not founderror appears and the highlight/read behavior matches the original send.Blocked checks and substitute verification
bun turbo typecheckpre-push hook exits with code 66 on@opencode-ai/uiin the local turbo execution context, butbun run typecheckin that package passes when run directly. This is a pre-existing local environment issue unrelated to these changes.bun run typecheckfrompackages/kilo-vscode/bun run lintfrompackages/kilo-vscode/bun test tests/unit/file-mention-utils.test.ts tests/unit/use-file-mention.test.tsfrompackages/kilo-vscode/— 78 tests passbun test src/components/message-highlight.test.tsfrompackages/kilo-ui/— 20 tests passChecklist