In your editor

The editor surface publishes what the local index knows about the file you have open. That is the routes and calls in it, the code on the other side of them in the other repos on disk, and any contract between the two that no longer holds. Those diagnostics are available in the Problems panel to you and to editor integrations that read it.

Install the CLI first

The extension carries no server of its own. It starts carrick lsp --stdio, so without the carrick CLI it starts nothing and says so in the Carrick output channel.

npm install -g carrick     # Node 24 or newer
carrick login
cd ~/code                  # the folder that holds your repos
carrick init               # finds the repos and runs the first index

Without an index the server publishes no diagnostics and names the command that builds one. carrick index rebuilds it later. See the Quickstart for the rest of the setup.

Install the extension

The extension is published as carrick-tools.carrick in both the Visual Studio Marketplace and Open VSX. Install it from the gallery your editor uses.

For VS Code:

code --install-extension carrick-tools.carrick

Every scanner release also includes a .vsix. Download the asset when an editor cannot resolve either gallery:

mkdir -p carrick-extension
gh release download -R carrick-tools/carrick --pattern '*.vsix' --dir carrick-extension
code --install-extension carrick-extension/carrick-*.vsix

The extension activates on TypeScript and TSX files. It carries no scanner or language server; every result comes from the installed carrick CLI.

What it shows

Diagnostics. The verdicts for the open file land in the Problems panel, and the sites on the other side arrive as related locations, so a finding on a producer is one click from the code that reads it. The server also publishes for the counterpart file, so opening a producer can raise a diagnostic on a consumer you never opened. A row is an error where the verdict claims something, the two sides are not compatible, and the other side is on this disk. Other findings are warnings.

Go to definition, across repos. On a call to another service it jumps to the handler that serves it, in the other repo. On a route it lists the call sites that reach it and the editor shows the picker. Carrick answers only inside a row the index holds, and only when the file on the other side is on this disk, so every other jump falls through to TypeScript exactly as it did before.

The code lens. Above a route or a call the index holds a counterpart or a mismatch for, one line says how many are on the other side and whether the contract still holds. Clicking it lists them and opens one across repos. The list also carries the boundary sentence. A row the index knows nothing about gets no lens. On a local index, a missing consumer means the call was not indexed here rather than that nobody calls the route.

The boundary line. A status bar item names the indexed service and the commit the scan was taken at, and its tooltip is what that scan could not classify. That sentence is what makes an empty Problems panel readable. It belongs to the workspace rather than to a file, so it sits in the status bar instead of on every file you open.

One check publishes at most ten findings per file and thirty findings across all files. When a file has more, an eleventh row states how many were omitted and names the carrick check command that prints the complete answer. Problems are ordered before other rows and then by source line. Carrick never publishes Hint diagnostics.

Settings

Each setting turns off its own surface and leaves the others standing, and takes effect on the next publish rather than at the next reload.

Setting	Default	What it controls
carrick.binary	the carrick on PATH	Which CLI to start lsp --stdio on. Not a surface
carrick.diagnostics	on	The verdicts in the Problems panel, at their own site and at each counterpart
carrick.definition	on	Cross-repo go to definition. Off means Carrick answers nothing and your other definition providers are untouched
carrick.boundary	on	The status bar item and its tooltip, or the file-level row in a client without a status bar
carrick.codeLens	on	The lens above a route or call with a counterpart or a mismatch

An editor launched from a dock or a launcher does not inherit a shell’s PATH, so a carrick that works in a terminal can be missing here. Point carrick.binary at the absolute path when that happens; the output channel names what it tried to start.

CARRICK_CHANNEL=off in the environment turns delivery off altogether.

Other LSP clients

The server is client-agnostic. Any client that takes a command and arguments can start it:

carrick lsp --stdio

An LSP client sends the settings above as initializationOptions under the same names with the carrick. prefix stripped. A workspace/didChangeConfiguration carrying { "settings": { "carrick": { ... } } } changes one mid-session. A client with no status bar keeps the boundary as a file-level diagnostic instead.

These generic client configurations have not completed the editor test plan. Treat the standard LSP entry point as integration guidance rather than a tested-editor claim.

The server takes the first workspace folder the client sends, falls back to the nearest .carrick/ above the file, and logs when the two differ.

Related

• Connecting your agent. The three channels an agent can read, including this one.
• Quickstart. Install, index, and connect your organisation.
• CLI. Login, workspace detection, indexing and read commands.
• What Carrick covers. What scans cleanly and what falls outside scope.