Copilot CLI C++ Language Server Adds Automatic MSBuild Configuration, With Limited Rollout

Why a compilation database matters​

A compile_commands.json file is a clang compilation database that lets C++ language services initialize their LSP server and provide code intelligence. The Microsoft C++ Team Blog post by Senior Product Manager Sinem Akinci puts it this way: include paths, preprocessor definitions and compiler options all change how a language server reads your source. Go-to-definition and find-references only resolve symbols correctly if the server knows those settings.

In a large Windows C++ codebase, a stray macro or a missing include directory can send a "find callers" query to the wrong place. A file that doesn't know how it is compiled is a guess.

What changed​

The post describes two earlier ways to configure an MSBuild project from Copilot CLI:

• You supplied your own compile_commands.json.
• Copilot found and ran a configuration skill to produce one.

The blog says the second route added setup time and burned tokens before the agent could use semantic code intelligence. That skill arrived earlier this year. A GitHub changelog from July described a "generate compile commands" skill you triggered with phrases like "regenerate compile commands" or "load project."

The new approach bundles an MSBuild compile-commands extractor inside the language server. It runs automatically at startup when a compile_commands.json needs to be generated. Microsoft lists three claimed benefits:

• Fewer manual steps, since MSBuild projects no longer need a separate configuration skill.
• More predictable setup, because generation is part of server startup and doesn't depend on the agent deciding to call a skill.
• Project-aware code intelligence, because the generated database supplies the context for definitions, references and other symbol relationships.

Microsoft gives no benchmarks. There are no figures for time saved, tokens saved or accuracy gained. Treat those benefits as design intent, not measured results.

How it works​

When you open an MSBuild-based C++ project, the server uses the same MSBuild tooling as Visual Studio. It reads include paths, preprocessor definitions and compiler options from your .vcxproj files and property sheets. It then writes a compilation database describing how each source file is compiled.

Microsoft's own skill documentation says this kind of extraction is design-time. It evaluates projects and runs GetClCommandLines, and it does not compile anything or need build outputs to exist. That document covers the skill-based path. It is reasonable to expect the bundled extractor to behave similarly, but the announcement doesn't spell that out, so treat it as an inference.

Generation runs in the background, and the time depends on solution size and complexity. To check progress, run /lsp logs. The npm package documentation says to select the C++ server in that view and press Enter.

Is it actually on for you?​

The sources disagree on this point.

• The blog presents the feature as available now.
• The configuration page in Microsoft's repository carries a note that automatic MSBuild configuration is disabled by default. It says the feature is available only if an experiment is enabled for you through feature flagging. Otherwise you should generate compile_commands.json yourself.
• The npm package page says automatic MSBuild generation is available to some Windows x64 users and requires no opt-in.

These two documents fit together if the rollout is staged. The feature is probably being exposed gradually to eligible Windows x64 users, and the repository note may simply be older than the npm page. I can't confirm that from the sources. The practical advice is not to assume it will fire on your machine. Run /lsp logs and check.

The repository's quick-start instructions still tell MSBuild users to run the generate-compile-commands skill. That text hasn't caught up with the announcement, so it doesn't mean the feature is missing.

What the automation doesn't cover​

Microsoft is explicit that this automates only the compilation database. You still need the usual onboarding:

• An active GitHub Copilot subscription.
• A Copilot CLI build with session-directory support. The README says it was tested with prerelease 1.0.106-5.
• npm.
• The cpp-language-server plugin, installed with /plugin install cpp-language-server@copilot-plugins.
• Acceptance of the license terms and a GitHub login, done with npx @microsoft/cpp-language-server --accept-eula --login.

After that, launch Copilot CLI from the project directory and run /lsp show. You should see a "cpp" server running. The README says phrases like "use LSP tools" can nudge the agent toward the language server tools. The README also labels the language server a preview that may change.

Other build systems are unchanged. For CMake, ask Copilot CLI to "load project" to use the generate-compile-commands skill. For custom builds, you can supply your own database or write a custom extractor skill.

Timeouts, settings and edge cases​

The blog points to the configuration docs for disabling the feature or adjusting its timeout, and says changes apply at the next language-server startup.

• Timeout: The npm documentation gives the setting as msbuild_extractor_timeout_seconds (its example value is 180), set in %LOCALAPPDATA%\mscppls\state.json. The repository documentation says these settings live in the per-user state file, not in project configuration, and that they apply on Windows.
• Disable switch: I couldn't confirm the exact setting name from the sources, so I won't guess. Check the compile-commands guide in the repository.
• Working directory: An auto_configure_directory setting in the same state file can pin automatic configuration to another directory. It controls cache lookup, database discovery and MSBuild extraction, but not the client workspace used for indexing.
• Existing databases: During automatic configuration, an existing database without a recognized MSBuild extractor stamp is reused and never overwritten. If you have a hand-built or CMake-generated compile_commands.json, the server won't clobber it.
• Discovery: The repository documentation says the server searches for a single compile_commands.json in its configuration directory. Discovery fails if it finds none or more than one. In that case you need an explicit .mscppls/cpp-lsp.json, whose version must be 1.
• Unusual MSBuild setups: Microsoft's guidance says setups with multiple Visual Studio installs, a specific platform toolset or SDK, or projects that must be restored first can still need configuration. Those cases are handled by the skill.

Troubleshooting checklist​

1. Confirm the plugin is installed and the EULA and login step is done.
2. Launch Copilot CLI from the project directory and run /lsp show to see whether the "cpp" server is up.
3. Run /lsp logs to see whether extraction is running or has failed.
4. If nothing happens, you may not be in the rollout. Generate the file with the skill or the manual extractor.
5. If the server finds multiple databases or none, add a .mscppls/cpp-lsp.json pointing at the right one.
6. If the extractor times out on a big solution, raise the timeout in state.json and restart the server.

By default, the repository's logs sit in a session-specific folder under $TEMP/mscppls. You can override that with --log-dir, which is useful when filing an issue in the GitHub repository.

Analysis​

This is a small change that removes a real annoyance. Making setup deterministic matters for AI-assisted workflows, where every extra "figure out how to configure this" step is a chance for the agent to wander off. It also brings Copilot CLI closer to the Visual Studio experience, where project settings are read from the project system directly.

Two caveats keep the enthusiasm in check. The product is in preview, and the rollout appears to be partial. Microsoft's claims about efficiency are also unquantified. For teams on large legacy .vcxproj solutions, the real test is whether extraction finishes reliably within the default timeout.