Copilot CLI indexes whole C++ codebases instead of rediscovering them

Victoria Shinder23 September 2026, 08:062 min read

GitHub has enabled whole codebase indexing for C++ code intelligence in Copilot CLI, announced on 22 September 2026.

The problem it addresses is restated clearly in the notice: C++ repositories can hold millions of lines across deeply connected sources and headers, and without a reusable index, code-intelligence requests may have to rediscover project information as you navigate — making it slower to find a definition, locate references or read unfamiliar code.

Whole codebase indexing builds a persistent index of symbols across the project, including files that are not currently open. The Microsoft C++ Language Server uses the project's compilation information to resolve types, symbols, includes and relationships between files, and that information is then reused rather than recomputed per request.

It is enabled by default. The language server loads the index when a C++ project is first opened, and indexing progress can be checked with /lsp logs. GitHub notes that building the index the first time can take additional time and temporarily increase memory usage, particularly on large or complex repositories; afterwards it is reused and updated dynamically. It can be disabled, and the session must be restarted after changing the setting.

What it means

The dependency named in the notice is the one to register: this runs on the project's compilation information. In C++ that means compile_commands.json or an equivalent, and a repository that cannot produce accurate compilation data for all its targets will index poorly regardless of the feature. Teams with generated build systems, mixed toolchains or platform-gated files will see the quality of this track the quality of that file.

The default-on choice with a first-run cost is the trade worth knowing before it surprises someone. On a large monorepo the first open is slower and heavier than it used to be, which reads as a regression if you do not know why. That is what /lsp logs is for.

Note the boundary of the claim: this is about the speed and completeness of symbol lookup, not about model answers. Better indexing gives the tool more accurate ground truth to work from, but the notice does not claim, and we do not, that generated suggestions improve as a result.