I have been using GitHub Copilot CLI for a while now, and I love it. But there is this one thing that always bugged me. When I ask it to find where a function is defined or what a particular type looks like, it would sometimes give me nonsense answers. It would grep through decompiled JAR files or dump entire node_modules directories and try to make sense of them.
That is not intelligence. That is desperation.
The new LSP Setup skill changes this, and honestly, it feels like someone finally turned on the lights in a room I did not realize wasdark.
What Copilot CLI Actually Does Without LSP
Let me paint you a picture. You are working on a Java project. You ask Copilot CLI: “Hey, what does this method return?” Without an LSP server, the agent has to get creative. It might extract a JAR to a temporary directory, run some grep command on .class files, and try to piece together what the bytecode is telling it. It is resourceful, I will give it that. But it is basically guessing.
For Python projects, the agent ends up cat-ing files inside site-packages somewhere, hunting for type hints or docstrings that might answer the question. For TypeScript, it wanders through node_modules looking for .d.ts files. These approaches work sometimes, sure. But they miss generics entirely. They cannot resolve overloads. They cannot trace types across module boundaries. Forget about seeing compiled bytecode at all.
The real problem is that all of these approaches treat your code as text. Just patterns to match. But code is not just text. It is a structured, typed, interconnected thing, and treating it like a bag of words means losing all the semantic information that makes programming possible in the first place.
How LSP Fixes This
The Language Server Protocol is the standard that powers go-to-definition, find references, and type resolution in editors like VS Code. It has been around for years. The brilliance of it is that the language understanding lives in a separate server process, and any editor can talk to it.
The LSP Setup skill brings this same power to the terminal. When configured, Copilot CLI no longer has to guess. It sends a textDocument/definition request to the language server, and the server responds with the exact source location, fully resolved type, and signature. No more grep. No more decompilation. Just answers.
The skill supports fourteen languages out of the box. It detects your operating system, picks the right package manager, writes the configuration, and verifies everything works. It is a seven-step workflow that handles the messy OS-specific install commands, the configuration file formats, and the path verification. For a lot of developers, this eliminates the biggest barrier to entry with language servers: the setup headache.
Why This Matters for Daily Work
Here is what I noticed after setting this up on my local machine. I asked Copilot CLI a question about a symbol in a fairly complex codebase. Before LSP, this would have triggered a chain of tool calls, each one slightly less confident than the last. Now? One request, one response, accurate every time.
The practical benefits are pretty straightforward. The agent produces more accurate code on the first pass because it actually understands the types it is working with. You spend less time waiting while it rummages through compiled artifacts. And you get fewer wrong turns where it commits to a solution based on a misread signature.
But the bigger implication is that this shifts what kind of tasks you can hand to the agent. Before, I would break problems into tiny steps because I did not trust the agent to reason about unfamiliar code. Now I can give it bigger, messier problems because it has the same structural understanding of my code that I get from my IDE.
This is part of a larger trend I am seeing. The gap between what an AI agent can do in a well-equipped editor and what it can do in the terminal is closing fast. Custom agents, remote control for Copilot sessions, skills that extend capabilities. GitHub is building an ecosystem where the CLI is not a downgrade from the GUI anymore.
Open source tooling has always been about removing friction. The LSP Setup skill removes the friction of setting up language servers, which means more developers will actually use them. That is a win for everyone writing code, honestly.