MoonshotAI / MoonshotAI/kimi-code
Markdown file links in assistant output are never clickable in the VS Code extension
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 7.5k
- Forks
- 1.2k
- Avg merge
- 11h 53m
- Merged PRs (30d)
- 350
Description
What version of Kimi Code is running?
0.29.1
Which open platform/subscription were you using?
Allegretto
Which model were you using?
K3 High
What platform is your computer?
Linux 7.1.4-200.fc44.x86_64 x86_64` — Fedora Linux 44 (container, remote server; VSCodium client connected over Remote)
What issue are you seeing?
Bug: Markdown file links in assistant output are never clickable in the VS Code extension
Environment
| Item | Value |
|---|---|
| Extension | moonshot-ai.kimi-code v0.6.4 |
| Kimi Code CLI | 0.29.1 (/usr/local/bin/kimi) |
| Editor | VSCodium 1.126.04524 (commit 4c0b0c6cc561d2d3636d1ec250935431876ce4dc) |
| Platform | Linux 7.1.4-200.fc44.x86_64 x86_64 — Fedora Linux 44 (container, remote server; VSCodium client connected over Remote) |
| Model | K3 High |
| Subscription | Allegretto |
What issue are you seeing?
Markdown links to local files in assistant chat output render as
non-clickable text — clicking does nothing. External https:// links in the
same messages are clickable and open correctly, so markdown rendering
itself works; only local-file targets are dead.
Example emitted by the assistant (a documented pattern in our project skills):
[L1 — line 33](/home/dev/workspace/project/file.md:33)
renders as non-actionable text: no hover target, no click behaviour.
What steps can reproduce the bug?
- In the VS Code extension (v0.6.4), ask the agent to review a file and cite
findings as markdown links with absolute paths and:linesuffixes, e.g.
[L1 — line 33](/home/dev/workspace/project/file.md:33). - Click the link in the chat view. Nothing happens.
- Control: an
https://link (e.g. a GitHub issue URL) in the same message
clicks through normally.
Variants tested — all dead (same target file, one per message):
- absolute path with
:line - absolute path without
:line file:///abs/path, with and without:line- workspace-relative path with
:line vscode://file/abs/path:line- bare
/abs/path:lineas plain text (no markdown) - label variants: em-dash, ASCII hyphen, no separator (label parsing ruled out)
What is the expected behavior?
Clicking a markdown link to a local file opens that file in the editor,
ideally at the line given by the :line suffix — the behaviour other
coding-agent extensions provide for file:line references in chat output.
Additional information
- The https-vs-file asymmetry within a single message reproduces cleanly
and is the sharpest evidence. - Agentic editing workflows that cite findings as
file:linelinks lose
their navigation affordance; every reference must be opened by hand. - Tracker searched before filing: nearest item is #2051 (TUI URLs in
terminal output, enhancement) — not the same. No existing issue covers
file links in the extension chat view.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in the VS Code extension's chat-view markdown-link handling and reproduce the reported local-file cases alongside an https link. Trace how local targets are parsed and dispatched; done means absolute, workspace-relative, file://, and file:line links become clickable and open the file, ideally at the requested line, without regressing external links.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript, vscode
- Domain
- desktop, tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100