microsoft/vscode-cpptools: the official C/C++ extension, its cache and its limits

What vscode-cpptools actually adds to VS Code

VS Code is an editor. It has no built-in understanding of C++ syntax beyond generic text handling, and it cannot step through a compiled binary. The C/C++ extension fills the editing and debugging halves of that gap: IntelliSense for completion and navigation, and a debugging front end that drives an external debugger.

The repository README is explicit about what it does not fill. "The C/C++ extension does not include a C++ compiler or debugger. You will need to install these tools or use those already installed on your computer." That single sentence defines the audience. If you want a turnkey C++ environment with a bundled toolchain, this is not it. If you already have a compiler on PATH and want VS Code to feel like an IDE for it, this is the extension Microsoft maintains for that purpose.

The supported matrix in the README is narrower than "C++ on any platform". Windows lists MSVC, Clang and GCC across x64, x86, arm64 and arm. Linux lists Clang and GCC across x64, x86, arm64 and arm. macOS lists Clang and GCC across x64, x86 and arm64. The README adds that support for other compilers may be limited, which is a polite way of saying the IntelliSense configuration is tuned for those toolchains.

How IntelliSense and debugging are wired together

The extension does not compile your code to produce completions. It reads your source and a configuration you supply, then asks a compiler-like front end for the symbols it needs. That is why the README points at separate IntelliSense modes per compiler: the mode tells the extension which dialect and which include paths to assume when it parses.

The practical consequence is that IntelliSense quality tracks configuration quality. If your include paths or your standard version are wrong, completion and error squiggles will be wrong too, and the fix lives in your configuration, not in the extension. The README links to a dedicated page on customizing default settings for C/C++ and a page on configuring IntelliSense for cross-compilation, which is where the real work happens for embedded or cross-target projects.

Debugging follows the same pattern. The extension supplies the UI and the launch configuration, and the debugger does the work. The README links to a launch.json reference, so the debugging experience is configured through that file. The repository also contains a Documentation folder at the top level, alongside Extension and ExtensionPack, which reflects that the project is distributed as an extension plus a pack rather than a single artifact.

Installing vscode-cpptools and getting a first build to work

The README does not give a command line for installing the extension. It points at the extension overview and at per-compiler tutorials, and the repository ships a vsix artifact for manual installation. In practice you install it from the VS Code Marketplace, or you install a downloaded vsix through the editor's own extension view. There is no build-from-source step for the user, because the repository is the source of a published extension rather than a tool you compile yourself.

What you must do yourself is supply the toolchain. The README is blunt about this: the extension does not include a C++ compiler or debugger. So the first step is checking that you have one of the supported compilers installed, and the second is picking the tutorial that matches it. The README lists five: MSVC on Windows, GCC and Mingw-w64 on Windows, GCC on WSL, GCC on Linux, and Clang on macOS. Each one walks through the first build and debug cycle for that specific combination.

Configuration happens in two places. IntelliSense behavior is driven by the extension's C/C++ settings, which the README covers under customizing default settings for C/C++. Debugging is driven by a launch.json file, which the README covers through its launch.json reference. If your first debugging session fails, the README points at a page on enabling logging for IntelliSense or debugging, which is the documented way to see what the extension is actually doing.

For a cross-compilation setup, the README links to a page on IntelliSense modes for cross-compilation. That is the relevant page when your build target differs from your host, and it is the one place where the compiler table matters most: the mode you choose has to correspond to the compiler family you are targeting.

The cpptools cache folder, and why users search for it

The most common questions people type about this project are not about IntelliSense modes. They are about disk usage: the cpptools cache, the cpptools folder, ipch, clearing the cache, and the extension taking up space. That pattern is a signal about where the friction actually is.

IntelliSense needs parsed representations of your translation units. Those are cached on disk so that reopening a project does not re-parse everything from scratch. The cache is the price of fast completion on a large codebase, and on a large codebase it can become a significant folder. The README itself does not document the cache location, its size, or a supported way to clear it, so anyone searching for "vscode cpptools clear cache" is working from community knowledge rather than from the project's own documentation.

That is a real gap. The extension's own README covers pre-requisites, tutorials, editing features, debugging, logging and FAQs, but not cache management or disk footprint. If disk usage matters to you, plan to inspect the cache folder yourself rather than expecting a documented setting. The related searches around the cpptools folder and its size exist precisely because the documentation is silent here.

Where vscode-cpptools is the wrong choice

The clearest wrong case is a machine with no compiler. The README states the extension does not include a compiler or debugger, so installing it on a clean system produces an editor that can highlight C++ but cannot build or run it. That is not a defect; it is the design. But it catches people who install the extension first and only then discover they needed MSVC, Clang or GCC all along.

The second wrong case is an unsupported or unusual toolchain. The README's table is the supported set, and it notes that support for other compilers may be limited. If your build depends on a vendor compiler outside that table, IntelliSense may be approximate, and the debugging configuration may need manual work that the tutorials do not cover.

The third case is disk-constrained environments. Because the cache is not documented or configurable through a documented setting in the README, a container or a small VM running this extension on a large project can accumulate data with no documented knob to bound it. If your environment has a hard disk budget, test the footprint before committing.

Finally, Microsoft's data collection notice applies. The README states the software may collect information about you and your use of the software and send it to Microsoft, and that you can turn telemetry off via the same setting provided by Visual Studio Code, `"telemetry.enableTelemetry"`. If your environment forbids telemetry, that setting is the documented control.

vscode-cpptools versus clangd

The comparison users ask about most is this extension against clangd. The difference is architectural, not cosmetic.

vscode-cpptools is maintained by Microsoft and is designed around a set of supported compilers listed per platform: MSVC, Clang and GCC on Windows, Clang and GCC on Linux, Clang and GCC on macOS. Its IntelliSense modes correspond to those compilers, and its debugging story is built around launch configurations and an external debugger. It is the natural choice when your toolchain is one of those, particularly MSVC on Windows.

clangd is built on the Clang toolchain and derives its understanding of your code from a compilation database, typically compile_commands.json, produced by your build system. That means it follows whatever flags your build actually uses, which is an advantage for projects with complex or non-standard build setups, and a disadvantage if generating that database is extra work in your workflow.

Neither is strictly better. If you are on MSVC and want the configuration the README's tutorials describe, vscode-cpptools is the path of least resistance. If your build already emits compile_commands.json and you want the language server to mirror your exact compile flags, clangd's approach is a closer match. Running both at once on the same files is a configuration question the README does not address.

Licence, distribution and upgrade cost

The repository's licence is reported as NOASSERTION, which means the metadata does not resolve to a standard SPDX identifier. The repository does contain a LICENSE.md at the top level and a RuntimeLicenses folder, so the terms are in the tree rather than summarized in the README. If you plan to redistribute the extension or bundle it into a product, read LICENSE.md and the RuntimeLicenses contents directly; this article cannot tell you what they permit.

Upgrade cost is low in the ordinary case. Releases are frequent and versioned, with v1.35.1, v1.35.0 and v1.34.4 all published within September 2026, and the last push to the repository was on 2026-09-22. VS Code updates the extension through the marketplace, so there is no build step for the user. The upgrade risk sits in configuration: a change in how IntelliSense modes or launch configurations are interpreted can surface as new squiggles or a failed debug session after an update, which is why pinning a known-good extension version matters in a team setting.

The trademark section of the README is worth noting for anyone forking. Authorized use of Microsoft trademarks or logos must follow Microsoft's Trademark and Brand Guidelines, and modified versions must not imply Microsoft sponsorship. Contributions are covered by a separate contributing guide and the Microsoft Open Source Code of Conduct.

Editorial conclusion

Adopt vscode-cpptools if you already have a supported compiler and debugger installed and you want editing and debugging inside VS Code on Windows, Linux or macOS. Do not adopt it expecting a bundled toolchain: the README states the extension does not include a C++ compiler or debugger, and support for compilers outside its listed set may be limited. Before installing, confirm which compiler you have (MSVC, Clang or GCC) and which IntelliSense mode matches it, then check the size of the cpptools cache folder after your first large project, since that is the part of the extension users ask about most.

Frequently asked questions

Official sources

1. Issues
2. microsoft/vscode-cpptools on GitHub
3. README
4. Releases