IntelliSense & Code Completion Fails Unless Compiler Paths are Added to PATH Environmental Variable

[jjATL]

Environment

• OS and Version: Windows 11
• VS Code Version: 1.125.1
• C/C++ Extension Version: 1.33.4
• If using SSH remote, specify OS of remote machine:

Bug Summary and Steps to Reproduce

The ms-vscode.cpptools extension fails to evaluate the PATH variables provided by e.g. a CMake preset, terminal.integrated.env.windows or cmake.environment (or any other cmake.*Environment) variables, nor is there an option to explicitly specify a PATH environmental variable to be used by the extension, like C_Cpp.path.

This results in the build environment not being detected correctly. IntelliSense and code completion does not work.

Building via the ms-vscode.cmake-tools extension works perfectly fine, since it is evaluating the environment specified in a CMakePresets.json (s. excerpt):

{
    "configurePresets": [
        {
            "name": "<PRESET_NAME>",
            "displayName": "'<PRESET_NAME>' config",
            "description": "'<PRESET_NAME>' configure using 'Unix Makefiles' generator",
            "generator": "Unix Makefiles",
			"environment": {
                "PATH": "<PATH_TO_COMPILER_ROOT>/sysroots/x86_64-petalinux-mingw32/usr/bin:$penv{PATH}"
            }
        }
    ],
  
}

I do not want to alter the PATH environmental variable of the system, in order not to create conflicts with other projects I am working on. This means I have to manually specify the path every time in a CMD.exe,

C:\PATH\TO\PROJECT>set PATH=<PATH_TO_COMPILER_ROOT>\sysroots\x86_64-petalinux-mingw32\usr\bin;%PATH%

C:\PATH\TO\PROJECT>code .

or create a batch file, to start code with the correct environment.

---

Am I missing a way how to set the environment, particularly for a project - not system wide?

Could you please add a feature to set the PATH used by ms-vscode.cpptools ? Ideally the one from the CMake preset is automatically used.

Configuration and Logs

[7/10/2026, 12:12:00 PM] Unable to resolve configuration with compilerPath "<PATH_TO_COMPILER_ROOT>/sysroots/x86_64-petalinux-mingw32/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-g++.exe".  Using "cl.exe" instead.

Other Extensions

No response

Additional context

No response

[sean-mcmanus]

@jjATL How are you configured? You're using ms-vscode.cmake-tools as the configurationProvider, right?

[jjATL]

I do not have a configurationProvider set explicitly, i.e. the default seems to be used. Setting it explicitly in my settings.json

"C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools"

does not make a difference.

CLion for example is using toolchains, which is not a concept I favour, since it is vendor specific and I have to extend my CMakePresets.json by a vendor specific option, like so:

{
    "configurePresets": [
        {
            "name": "<PRESET_NAME>",
            "displayName": "'<PRESET_NAME>' config",
            "description": "'<PRESET_NAME>' configure using 'Unix Makefiles' generator",
            "generator": "Unix Makefiles",
			"environment": {
                "PATH": "<PATH_TO_COMPILER_ROOT>/sysroots/x86_64-petalinux-mingw32/usr/bin:$penv{PATH}"
            }
            "vendor": {
                "jetbrains.com/clion": {
                    "toolchain": "My CLion Specific Toolchain"
                }
            },
        }
    ],
  
}

and additionally configure that toolchain in the CLion IDE.

But, I at least have the ability to specify - not a project, but a toolchain specific - environment via a script, which gives me all control necessary regarding the environment. I can easily create e.g. a .bat file where I set the path. This is neat.

From my perspective, the entire CLion toolchain concept defeats the purpose of CMake presets, though, and serves as a negative example. I don't want to maintain different logics for different IDEs, since everything is already specified in my CMake preset. This also seems to be encouraged by the CMake developers:

[...] IDE vendors are encouraged to read and evaluate this file the same way CMake does, and present the user with the presets listed in the file. Users should be able to see (and possibly edit) the CMake cache variables, environment variables, and command line options that are defined for a given preset. The IDE should then construct the list of appropriate cmake(1) command line arguments based on these settings, [...]

As mentioned, it would be sufficient for me to have a project-wide environment setting, since the multiple toolchains I am using are not in conflict with each other when all paths are added to the PATH environmental variable, but ideally I could specify it per toolchain, via the enviroment option in each CMake configure preset.