Code intelligence instead of brute-force reading

You ask a question that should be cheap — where is resolveTenant defined, and who calls it — and you watch a grep return sixty hits across four packages, then six file reads to sort the definition from the re-exports. The answer was correct. Getting to it spent a chunk of the window on files you will never look at again.

Lesson 11.1 made the tree smaller before the session started. This lesson makes the lookups inside what is left cheaper — the first thing on this level that adds a capability rather than taking content away.

Finding a symbol the expensive way

In a large codebase, finding where a symbol is defined or used can cost many file reads and grep calls. — Set up Claude Code in a monorepo or large codebase

Note what that sentence does not say. It does not say search is unreliable, or that Claude gets the wrong answer. It says the answer is expensive. Every one of those reads lands in the window you costed out in Lesson 3.1, and it is there until you compact or clear — the read cost arriving by a route you did not choose, because you did not open those files, the search did.

What the plugin actually adds

A code intelligence plugin does not add a smarter search. It connects Claude to a language server — the same protocol that powers an IDE's "go to definition" — and switches on a built-in tool:

Code intelligence plugins enable Claude Code's built-in LSP tool, giving Claude the ability to jump to definitions, find references, and see type errors immediately after edits. — Discover plugins

Once the plugin is installed and its binary is available, Claude gains exactly two capabilities, and only one of them is about navigation.

Automatic diagnostics. After every file edit Claude makes, the language server reports errors and warnings back, so Claude sees type errors, missing imports and syntax issues without running a compiler or linter. If Claude introduces an error, it notices and fixes it in the same turn — you configure nothing beyond installing the plugin. To read the diagnostics yourself, press Ctrl+O when Claude Code shows an indicator such as Found 3 new diagnostic issues in 2 files.

Code navigation. Claude calls the language server directly rather than scanning:

Operation	Replaces
Jump to a symbol's definition	A grep, then reads to find the real declaration
Find all references to a symbol	A repo-wide grep and manual filtering of the hits
Get type information at a position	Reading the file, then the type it imports from
List symbols in a file, or search for one across the workspace	Reading the file; a glob plus a grep
Find implementations of an interface	A grep for `implements`, per language
Trace call hierarchies	Repeated reference searches by hand

The docs are careful about how strong the claim is, and so should you be:

These operations give Claude more precise navigation than grep-based search, though availability may vary by language and environment. — Discover plugins

More precise, and may vary. No documented figure exists for what this saves in tokens; distrust anyone who quotes you one.

Install it, and install the binary

Installation is one command inside a session. For TypeScript:

text

/plugin install typescript-lsp@claude-plugins-official

Then read the install summary rather than assuming, because it tells you whether you have a second step. Plugin is now active. means Claude Code activated the plugin as part of the install and there is nothing left to do. Run /reload-plugins to activate. means it did not — either because activating would invalidate the prompt cache, or because the activation attempt failed — and the plugin sits inert until you run that command; if the reload warns that it will re-read the conversation, rerun it as /reload-plugins --force. That fork in the road is recent: "Before v2.1.221, no install took effect in the current session until you ran /reload-plugins or restarted" (Discover plugins), so an install was always two steps and the second one was yours. Either way, get the plugin active before you decide anything about whether it works — a correctly installed plugin with the binary already on $PATH looks exactly like the trap below until you do.

The official marketplace carries a plugin for eleven languages — C/C++, C#, Go, Java, Kotlin, Lua, PHP, Python, Rust, Swift and TypeScript — and each one expects a binary you install yourself:

Language	Plugin	Binary required
TypeScript	`typescript-lsp`	`typescript-language-server`
Python	`pyright-lsp`	`pyright-langserver`
Go	`gopls-lsp`	`gopls`
Rust	`rust-analyzer-lsp`	`rust-analyzer`

The full table gives the other seven, and you can create your own LSP plugin for a language that is not on it.

If the install itself fails, match the message rather than guessing. On Marketplace "claude-plugins-official" not found, add the marketplace with /plugin marketplace add anthropics/claude-plugins-official and retry — do not conclude the plugin name is wrong. If the plugin is genuinely not found in the marketplace, then check the name.

It happens in reverse too: if you already have a language server installed, Claude may prompt you to install the corresponding plugin when you open a project.

When it will not be there

The tool is not always available, and two of these three look like a bug until you know them.

Before you install a plugin. Claude Code keeps the LSP tool inactive until a code intelligence plugin for your language is installed. There is no LSP setting to switch on — Claude Code takes the language server's configuration from the plugin, and the plugin is the switch.
In cloud sessions. "In cloud sessions, Claude Code doesn't start plugin language servers, so Claude doesn't get the LSP tool there" (Discover plugins). Same repository, same plugin, no LSP — Claude falls back to reading and searching, so the same symbol lookup costs the many file reads and greps this lesson opened with.
For a file whose server will not start. Claude Code returns an error result for each LSP call on a file whose language server it cannot start (Tools reference). A per-file outcome, not a session-wide one.

And one that bites inside companies: installing from the official marketplace requires network access to GitHub, where the marketplace is hosted. On a restricted network, add the marketplace from an internal Git host or a local path instead. The plugin is not unavailable; the route to it is blocked.

Turning it on for the team

Installing at user scope helps you. A large repository wants everyone navigating it the same way, and that is a committed setting rather than an onboarding instruction nobody reads. enabledPlugins is settable in any settings file (Settings reference), which is what makes the choice meaningful: the same key in your user file turns the plugin on for you alone, and in the project file turns it on for the repository.

To enable a plugin for everyone in the repository rather than installing it yourself, add it to the enabledPlugins project setting. — Set up Claude Code in a monorepo or large codebase

json

{
  "enabledPlugins": {
    "typescript-lsp@claude-plugins-official": true
  }
}

That commit is the easy half. Enabled and installed are not the same word, and the full chain a fresh clone walks — trust the folder, register the marketplace, install, activate, and get the version you shipped — is Lesson 12.2's subject, including the version rules that decide how much of it your commit can do on any given build. Read it before you announce a repo-wide rollout.

What is specific to code intelligence is the link no setting has ever performed: the language server binary. It is a per-machine dependency wearing the costume of a repository setting, which is why it belongs in the same paragraph of your onboarding docs as the package manager version, and why enabling the plugin for the project leaves every developer with the install from the table above still to do.

So when a teammate reports no LSP tool, do not open with "you never installed the plugin". Have them look at the /plugin interface and say which of the two is actually missing — the plugin, or the binary — and whether they have reloaded since. Answering that in the right order is the difference between one message and an afternoon.

Where it stops helping

Turning code intelligence on is not free, and it is not a search replacement.

Memory. Language servers like rust-analyzer and pyright can consume significant memory on large projects. If you hit memory problems, disable the plugin with /plugin disable <plugin-name> and rely on Claude's built-in search tools instead — a documented fallback, not a defeat.
Monorepo false positives. A workspace that is not configured correctly makes language servers report unresolved import errors for internal packages. The docs are explicit that these do not affect Claude's ability to edit code, which is the useful half: otherwise you would spend an afternoon chasing a diagnostic that was never about your change.
Denied paths stay denied. The Read(...) rule format applies to Read, Grep, Glob and LSP (Tools reference), so the deny rules you wrote in Lesson 11.1 bound symbol lookup too. Code intelligence does not open a side door into the generated code you excluded.

That last point is where this lesson and the previous one meet:

This pairs well with claudeMdExcludes and the Read deny rules above. Those keep irrelevant content out of context, and code intelligence keeps Claude from reading through what remains to locate a definition. — Set up Claude Code in a monorepo or large codebase

Checkpoint

A colleague installs pyright-lsp, restarts the session, and reports that Claude is still grepping for definitions. What is the first thing you ask them to check, and where in the interface do they look?

Show answerAnswer
Ask whether the language server binary is installed — pyright-langserver, for pyright-lsp. The plugin configures the connection; it does not install the server for you, and that is a separate install on every machine that wants it. This is the trap the lesson names: the install succeeds, nothing appears to change, and the tempting conclusion is that code intelligence does not work.
They look at the /plugin Errors tab, where a missing binary reads Executable not found in $PATH — the documented place, and one you have to think to check. Restarting covers the other half of the question you would otherwise ask, which is whether the install summary said Plugin is now active. or Run /reload-plugins to activate. Get the plugin active first, because a correctly installed plugin with the binary already on $PATH looks identical to this failure until you do.
You add typescript-lsp@claude-plugins-official to the project's enabledPlugins and push. A teammate pulls, opens Claude Code, and has no LSP tool. Name two distinct reasons this can happen, and say which of them your commit could ever have fixed.

Show answerAnswer
Two distinct reasons first, and your commit could never have fixed either of them. The first is the binary: typescript-language-server is a per-machine dependency wearing the costume of a repository setting, and no setting has ever performed that link. Your commit could not fix it, which is why it belongs in the same paragraph of your onboarding docs as the package manager version. The second is a cloud session: Claude Code doesn't start plugin language servers there, so Claude doesn't get the LSP tool — same repository, same plugin, no LSP, and again nothing your commit can do.
The reason your commit does bear on is the third: enabled and installed are not the same word. A fresh clone still has to trust the folder, register the marketplace, install, activate and end up on the version you shipped — Lesson 12.2's chain, including the version rules that decide how much of it a committed enabledPlugins can do on any given build. So do not open with "you never installed the plugin". Have them look at the /plugin interface and say which is actually missing, the plugin or the binary, and whether they have reloaded since.
Your repository denies Read on packages/*/generated/**. You ask Claude to find every caller of a function that is defined in generated code. What does code intelligence do for you here, and what does it not?

Show answerAnswer
It does not open a side door into the generated code. The Read(...) rule format applies to Read, Grep, Glob and LSP, so the deny rule bounds symbol lookup exactly as it bounds reading — the definition inside packages/*/generated/** stays out of reach, and the fallback search would be blocked on the same paths anyway. If what you actually need is the definition, the deny rule is the thing to change, not the plugin.
What it does for you is everything outside those paths. Finding the callers is a find-references call rather than a repo-wide grep with the hits filtered by hand, and tracing from there is a call-hierarchy request rather than repeated reference searches — more precise navigation over what remains, which is exactly the pairing the docs describe: deny rules keep irrelevant content out of context, code intelligence keeps Claude from reading through what is left to locate something. Two hedges the docs keep and you should too: availability may vary by language and environment, and if the language server will not start for a given file, each LSP call on that file returns an error — a per-file outcome, not a session-wide one.