Claude Code with LSP: from searching text to understanding code

I have been using Claude Code daily for months, and there is one configuration that has completely changed how it works with my code. It is not a new plugin, a more powerful model, or a magic prompt. It is something that has existed since 2016 and that most developers use without knowing it every time they open VS Code: the Language Server Protocol (LSP).

Karan Bansal published an excellent article explaining in detail how to enable LSP in Claude Code and why it matters. After trying it, I can confirm the difference is real and significant.

The problem: Claude Code treats your code as plain text

By default, when Claude Code needs to find a function, a class, or understand how your project components connect, it uses grep, glob, and read. These are text search tools. They work, but they have a fundamental problem: they treat code as if it were any ordinary text file.

If you ask it to find where User is defined, it will find the User class, but also the comment that says // Create a new User, the string "User not found", the import, the type alias, and dozens more matches in files that have nothing to do with what you need. Filtering that takes time. According to Karan’s measurements, between 30 and 60 seconds per query.

With LSP, the same query takes about 50 milliseconds. And it is 100% accurate. No false positives. No filtering needed. The language server knows exactly where the definition is because it understands the code structure, not just the text.

What LSP is and why you should care

Before 2016, every code editor needed its own implementation of support for each language. If you wanted Python autocomplete in Sublime Text, someone had to write a Python plugin for Sublime Text. If you wanted the same in Atom, another plugin. It was an M times N problem: M editors times N languages.

Microsoft created LSP to solve this. It is a protocol that separates language intelligence from the editor interface. A language server (like Pyright for Python or gopls for Go) understands the code. Any editor that speaks LSP can use it. The M times N problem becomes M plus N.

What makes this interesting for Claude Code is that the same capabilities that power your IDE, definition navigation, reference search, type error detection, can be put at the service of an AI agent.

What changes in practice

With LSP enabled, Claude Code gains two types of capabilities:

Passive capabilities (automatic)

The language server sends real-time diagnostics. If Claude Code edits a file and breaks a type, it detects it immediately without needing to compile or run tests. Missing imports, undefined variables, type errors: everything is detected before you see it.

In my experience, this has the most impact. When Claude Code writes code with type errors, it normally needs another editing cycle to correct them. With LSP, it fixes them in the same turn because it receives feedback instantly.

Active capabilities (on-demand)

When you ask about your code, Claude Code can use semantic operations instead of text searches:

• goToDefinition: Go directly to where a function or class is defined
• findReferences: Find all places where a symbol is used
• hover: See type signatures and documentation
• workspaceSymbol: Search symbols across the entire project
• goToImplementation: Find concrete implementations of interfaces
• incomingCalls/outgoingCalls: Trace call hierarchies

The important thing is that you do not need special commands. You ask in natural language and Claude Code chooses the appropriate LSP operation. If you say “where is authenticate defined”, it uses goToDefinition. If you say “who uses UserService”, it uses findReferences.

How to enable it

The setup is straightforward. Karan describes it as “two minutes”, and he is right.

1. Enable the flag

Add to ~/.claude/settings.json:

{
  "env": {
    "ENABLE_LSP_TOOL": "1"
  }
}

This flag is not officially documented yet. It was discovered through GitHub Issue #15619.

2. Install the language servers

You need to install the server corresponding to your languages:

3. Install and enable the plugins

claude plugin marketplace update claude-plugins-official
claude plugin install pyright-lsp
claude plugin enable pyright-lsp

4. Restart Claude Code

On startup, you will see in the debug logs that the language servers initialize. Python, Go, and TypeScript start up in under a second. Java takes about 8 seconds due to the JVM.

My real experience

I work primarily with TypeScript and Go. After enabling LSP, the most noticeable change is in refactoring. When I ask Claude Code to rename a function or move a module, it now finds all call sites reliably. Before, with grep, there was always some stray reference that would show up later as an error in CI.

The other significant change is in exploring code I do not know. When I work in a new repository, Claude Code with LSP can trace call chains and understand the architecture much faster than doing recursive greps. Instead of “search User in all .ts files”, it does findReferences and gets exactly the relevant files, with type context included.

A practical tip

Karan suggests adding instructions to your CLAUDE.md to make Claude Code prioritize LSP over grep. It is good advice. Something like:

Use LSP operations (goToDefinition, findReferences) for code navigation.
Only use grep for text pattern or string searches.

This ensures Claude Code uses the fast path by default instead of falling back to text searches by inertia.

A 900x improvement you can feel

The difference between 30-60 seconds and 50 milliseconds is not an incremental improvement. It is a category change. It is the difference between Claude Code working as an assistant that searches files and working as a developer that understands your code.

It is two minutes of configuration. And once you try it, there is no going back.

References

• The 2-Minute Claude Code Upgrade You’re Probably Missing: LSP - Karan Bansal
• Language Server Protocol - Official specification
• GitHub Issue #15619 - Claude Code LSP flag