Whole Codebase Indexing Arrives in GitHub Copilot CLI's C++ Language Server
GitHub's changelog starts from a common C++ problem. Repositories can hold millions of lines of code spread across source files and headers that depend heavily on each other. Without an index that can be reused, a code-intelligence request may have to work out project information again every time you navigate. That makes it slower to find a definition, track down references, or make sense of code you don't know.
According to GitHub, WCI builds a persistent index of symbols for the whole C++ project, including files you don't have open. The Microsoft C++ Language Server reads the project's compilation information to resolve types, symbols, includes and the relationships between files. WCI then keeps that symbol information so later requests can use it again.
GitHub names the operations that should benefit: go-to-definition, find references, find implementations and symbol search. It describes the gain as less waiting and more time spent reviewing and changing code. The changelog gives no benchmark, no timing comparison and no percentage speedup, so any claim of a specific improvement goes beyond what GitHub has published. The aggregator daily.dev summarized the change the same way, saying it speeds up definition lookups, reference searches, and symbol search in large repositories. That summary is based on GitHub's post and doesn't count as separate testing.
Why a Semantic C++ Index Changes How Copilot CLI Searches Code
The update makes more sense once you know what the language server does inside Copilot CLI. Microsoft's C++ team put the Microsoft C++ Language Server into public preview for Copilot CLI on April 22, 2026. The team explained that until then, these C++ code-understanding tools have been tied to GitHub Copilot in Visual Studio and VS Code. They run on the same IntelliSense engine that handles code navigation in those IDEs.
The case for the language server is that plain text search struggles with C++. The C++ team wrote that complex include hierarchies, macros, templates, overloads, and build-system-dependent configurations mean that text search alone can give incomplete or misleading results. The language server gives Copilot semantic data such as symbol definitions, references, call hierarchies and type information, which it uses alongside grep-style search.
Microsoft's launch post gave a concrete before-and-after. Without the language server, Copilot uses iterative grep searches to build its understanding of potentially relevant code. In that mode, it greps a class name instead of jumping to the definition of a key base class, and gets back every instance of that type in the codebase to sort through. With the language server, Copilot can use workspace symbol search and go-to-definition to reach the relevant code directly.
WCI builds on that base. The language server already gave Copilot accurate answers, and the index lets it give those answers without redoing the underlying work for each query. An agent may run many lookups in one task, so saving time on each lookup could add up over a session. That compounding effect is our inference: GitHub hasn't measured it for the CLI.
Visual Studio Got WCI First, and the CLI Shares Its Engine
WCI is new to Copilot CLI but not new to Microsoft's C++ tools. On July 14, 2026, Microsoft's C++ Team Blog introduced WCI in Visual Studio Insiders 18.9, describing it as something that enhances the existing browse database via a deeper, more comprehensive indexing approach. A later C++ team roundup of Visual Studio 2026 versions 18.7 to 18.10 called it a preview feature that adds richer symbol-use information to the C++ browse database, so Visual Studio can reuse semantic data that has been indexed as you work instead of repeatedly computing some relationships on demand.
Microsoft framed the Visual Studio version partly around Copilot. It said the deeper integration helps Copilot spend less time searching for symbol information, making the full agentic loop quicker and more responsive. It also said the biggest gains come in larger codebases especially when symbols have many reference locations. That's a vendor claim about the IDE, not a measured result for the CLI. Still, it shows what Microsoft built the index for.
The two versions differ in ways that affect you. In Visual Studio, WCI is a preview feature, and some editor extras built on it are off by default. One example is an "Enable CodeLens for References" sub-setting that shows reference counts inline above functions. In Copilot CLI, GitHub's changelog says WCI is enabled by default. The CLI has no editor surface like CodeLens, so the benefit shows up only in how fast and how accurately Copilot's own lookups run. Visual Studio settings and behavior don't carry over to the CLI. They are separate products that share an engine.
The First-Run Cost: Indexing Time and Memory in Copilot CLI
GitHub is upfront about the overhead. The language server loads the index the first time you open a C++ project. Building it for the first time can take longer and temporarily raise memory use, particularly in large or complex repositories. Once the first index is done, it is reused and updated as the code changes, so the extra cost falls mainly on initial setup.
That changes how you should think about a first session. If you start Copilot CLI in a large C++ repository and lookups seem slow, or memory use jumps, the one-time indexing pass is the obvious suspect. Since the index persists, the second session in the same project should skip most of that work.
GitHub gives one command for checking what's happening: /lsp logs, which shows indexing progress at any time. The changelog doesn't explain how to read the log output, give expected indexing times, or list memory figures, index sizes or refresh delays. It also doesn't say at what repository size the overhead becomes noticeable. On shared build agents, small VMs or laptops, you'll have to judge the memory spike from your own environment, because GitHub hasn't published a number to plan around.
The changelog doesn't restate platform support. Microsoft's April launch post said the language server runs on Windows, Linux, and macOS. Nothing in the September announcement says WCI is limited to any of these.
Turning WCI Off: What GitHub Documents and What It Leaves Out
Some developers will want to turn indexing off, for example on a machine with little memory or while investigating a performance problem. GitHub says WCI can be disabled temporarily by following the Microsoft C++ Language Server's indexing documentation, and that you have to restart your Copilot session after changing the setting.
The changelog doesn't name the setting or show its configuration syntax. It points to indexing documentation for the language server, which is published in Microsoft's issue-only GitHub repository for the project. daily.dev also describes the switch as living in the indexing documentation in the Microsoft C++ Language Server repository. We haven't independently confirmed the setting's exact name or current form, and this article won't guess one. The verified procedure has three parts: change the indexing setting as that repository's documentation describes, restart the Copilot CLI session, and use /lsp logs to see what the language server is doing.
The word "temporarily" is worth noticing. GitHub's wording treats disabling WCI as a troubleshooting or resource-saving step, not a long-term setup. That fits the reasoning behind the default: the index is what lets the language server understand relationships across the whole project. Without it, requests go back to rediscovering project information as needed.
Prerequisites That Still Apply to the Microsoft C++ Language Server
WCI adds no new setup steps of its own, but it only works where the Microsoft C++ Language Server works in Copilot CLI. The index depends on the project's compilation information, so the language server's own requirements still matter. As of the April 2026 preview, those were:
- Authenticate with GitHub Copilot CLI. The language server also requires an active GitHub Copilot subscription.
- Create a
compile_commands.jsonfile for the project, which gives the language server the compilation information it uses to resolve types, includes and symbols. - Configure the project for use with the CLI.
For CMake projects, Microsoft's issue-only repository includes a skill that automates the second and third steps, along with instructions for doing them by hand. For MSBuild (vcxproj) projects, Microsoft said it had built a sample application to help extract compile_commands.json from C++ MSBuild projects. At the time, GitHub said integrated MSBuild support was planned for a future release. The September changelog doesn't update the MSBuild status, so Windows teams on Visual Studio solutions should assume the sample-based extraction route still applies unless Microsoft says otherwise.
The April guidance also included a tip: add "Use the C++ LSP" to your prompts, or create a custom instructions file that tells Copilot to prefer the C++ LSP. That advice is from before WCI, but the logic still holds. An index only helps if the agent actually calls the language server instead of falling back to grep.
The September changelog doesn't say whether the language server has left public preview. The post is labeled a release, but the most recent explicit status statement is still April's "public preview."
What this means for you
If you already run the Microsoft C++ Language Server in Copilot CLI, you don't need to do anything to get WCI. Your job is to let the first index finish on each large repository and watch memory while it runs. If you haven't set up the language server, WCI makes that setup more worthwhile, and the compile_commands.json requirement is still the real entry point. Teams working on memory-limited machines or shared environments are the ones who should read the disable procedure before rolling this out widely.
- WCI is on by default in GitHub Copilot CLI's C++ support as of GitHub's September 22, 2026 changelog, and the index loads when you first open a C++ project.
- Run
/lsp logsin Copilot CLI to check indexing progress, especially if your first session in a large repository seems slow. - Expect higher memory use and extra time during the first index build on large or complex codebases. GitHub says later sessions reuse the index and update it as code changes.
- To disable WCI temporarily, follow the indexing documentation in the Microsoft C++ Language Server's GitHub repository, then restart your Copilot session so the change takes effect.
- WCI depends on the language server's existing prerequisites: Copilot CLI authentication, an active Copilot subscription and a
compile_commands.json. For MSBuild projects that still means Microsoft's extraction sample. - GitHub has published no speedup figures for the CLI, so judge the benefit on your own repositories rather than expecting a specific gain.
Copilot CLI now gets the same persistent C++ symbol index that Microsoft first built for Visual Studio, running on the same IntelliSense engine. The index turns the language server's accurate answers into cheaper ones by storing work that used to be repeated on every query. The cost is a first indexing pass that GitHub admits can be slow and memory-hungry. GitHub hasn't given numbers for either the cost or the payoff, so your own /lsp logs output and memory readings on your largest repository are the best evidence you'll have. MSBuild integration and the language server's move out of preview are the remaining items GitHub has said are coming.
Update: Microsoft says WCI includes MSBuild setup support (September 23, 2026)
Microsoft’s C++ Team Blog now says the language server provides built-in configuration skills for both CMake and MSBuild projects, alongside guidance for custom build systems. That supersedes the earlier assumption that Windows teams using vcxproj projects still needed Microsoft’s separate compile_commands.json extraction sample.
The post also says whole-codebase indexing can benefit parallel-agent workflows: agents working in the same indexed workspace can reuse repository understanding rather than independently reparsing the code for each task.
The practical requirement remains a valid compile_commands.json file. Microsoft says the index starts loading or building when a configured C++ project is opened, and it can be checked through /lsp logs.