Connect tools
Use Kin from your editor.
Inspect code connections without leaving VS Code. The extension helps you see what Kin knows about your project and when an answer may be incomplete.
Documentation
Start
Work with code
Connect tools
Understand Kin
Reference
Troubleshoot
Start
Work with code
Connect tools
Understand Kin
Reference
Troubleshoot
How this works in Kin
The extension is Kin inside VS Code rather than a fork of it. It reads the same graph the CLI and your agent read, and it names the state the graph is in rather than showing you a zero.
Install
From the Visual Studio Marketplace or from Open VSX, whichever your editor installs from. It needs VS Code 1.85 or newer, a repository admitted with kin init, and the local kin binary on the machine.
The commands and requirements on this page come from the extension's own manifest and README. Nothing here was exercised through the VS Code interface during the run the other docs pages cite; what that run confirms is only the detection row, which reports the extension as not detected in ~/.vscode/extensions and says plainly that it cannot be determined from the CLI for other editors.
What it gives you
Entity Explorer
Semantic entities from the graph in the sidebar, rather than a second filesystem tree beside the one you already have.
Semantic Search
Cmd/Ctrl+Shift+K S
Natural-language retrieval through semantic_locate, with results in a picker you can navigate. Workspace symbol search on Cmd/Ctrl+T uses name-pattern graph search instead.
Trace
Cmd/Ctrl+Shift+K T
The focal entity and the semantic context around it. The same graph data backs go-to-definition on F12 and hover, and both of those need the MCP connection.
Graph Overview
Cmd/Ctrl+Shift+K O
Entity count for the active workspace, plus edge, file and entity-kind counts when the daemon reports them. A graph that is unreachable or still indexing is named as that, not shown as zeros.
Review
Cmd/Ctrl+Shift+K V
Report-only Kin review surfaced as gutter decorations, diagnostics and a Kin Review output channel. It reports; it does not gate anything.
Rename
F2
A Kin rename plan for the selected entity and the graph references to it.
Status Bar
The indexed entity count, or an honest not-initialized or unavailable state. Kin: Show Status reports whether it is on the MCP path or the CLI path, and what state the graph is in.
How it reaches the graph
With kin.mcpEnabled at its default the extension launches kin mcp start on activation for each initialized workspace, and that process starts or reuses the repository daemon. There is no separate daemon-start step. Turn the setting off and it runs one CLI subprocess per command instead. Either path needs the local binary, and kin.binaryPath is where you name it when auto-detection does not find it.
When it looks wrong
Every Kin command is present but nothing answers.
No folder in the workspace contains a .kin directory.
Run Kin: Initialize Repository, or Kin: Setup Workspace, both of which the extension offers by name.
Hover and go-to-definition do nothing while other commands work.
Those two fire on every word the cursor touches, so they run only over the MCP connection rather than spawning a subprocess per lookup.
Leave kin.mcpEnabled at its default, and give the connection a moment after activation.
The status bar reports a count you do not believe.
It reports the graph, and the graph can be behind the working copy.
Open Graph Overview, or run kin graph status in a terminal and compare.
The extension cannot find the kin binary.
Either path, MCP or CLI, needs the local binary. With kin.binaryPath empty it checks ~/.kin/bin/kin and then PATH.
Set kin.binaryPath to the absolute path, which whence -p kin or which kin will give you.
A multi-root workspace answers about the wrong folder.
Commands resolve the active file's owning workspace, but the entity explorer and the status bar follow the first Kin-initialized folder in the workspace.
Open the file you mean before running a command, and read the status bar as belonging to that first folder.
Next action
Open one entity you already know.
Find it in the entity explorer, trace it, then run the same question on the command line and compare the two answers. That comparison is what tells you how much to trust the third one.
Find recorded callers