How can I find out why IntelliSense includes a specific path in the file discovery?

[smuehlst]

The problem I have with IntelliSense is that for a large software project it uses extreme amounts of memory after a while, until the whole computer becomes unresponsive. The only solution is to kill the problematic cpptools.exe processes.

The problem probably is caused by the fact that IntelliSense decides to index all the files under a common root directory. There are lots of source directories in different Git repositories. But in the collection of folders that I have opened in a specific VS Code workspace this common root directory is not opened as a folder. Only several selected sub-folders of the common root directory are in the workspace.

How can I find out why IntelliSense decides to include the problematic common root folder in the "Processing folder (recursive):" list in the C/C++ debug output? It is possible that there's a bug that this directory is referenced unintentionally from one of our CMakeLists.txt files for example, but we were not able to locate this yet. I have checked for example the compile_commands.json file, and there the problematic directory is not listed as an include path.

[tigran-sargsyan-w]

Here’s a practical way to track down why that outside folder is being indexed and how to stop it.

---

How to see where the path comes from

1. Run “C/C++: Log Diagnostics” on one of the affected source files.
   In the output, check:

   • Configuration provider (e.g. ms-vscode.cmake-tools)
   • compile_commands path (if used)
   • Include entries and their origin (includePath / system / provider)

2. Open OUTPUT → “C/C++” and set

   "C_Cpp.loggingLevel": "Debug"
   

   Then watch for lines like “Processing folder (recursive): /some/path”.
   That’s usually coming from browse.path (often expanded from a /** pattern), a provider (CMake Tools), or an include directory pulled from compile_commands.json.

3. Search for the offending path in your workspace:

   • .vscode/c_cpp_properties.json (includePath, browse.path)
   • CMakeLists.txt / presets (broad include_directories(${CMAKE_SOURCE_DIR}), add_subdirectory(..))
   • compile_commands.json (absolute include dirs)
   • Symlinks/junctions inside your opened folders that point back to the common root

---

Ways to prevent that root from being indexed

Option A — Exclude it explicitly (quickest): add to your workspace settings:

{
  "C_Cpp.files.exclude": {
    "/absolute/path/to/common-root/**": true
  },
  "files.watcherExclude": {
    "/absolute/path/to/common-root/**": true
  }
}

Option B — Pin browse.path to only what you need:
(avoid broad /** at the root)

{
  "C_Cpp.default.configurationProvider": "",
  "C_Cpp.default.browse": {
    "path": [
      "${workspaceFolder}/projA/include",
      "${workspaceFolder}/projA/src",
      "${workspaceFolder}/projB/include"
    ],
    "limitSymbolsToIncludedHeaders": true
  }
}

Option C — If you use CMake Tools as a provider:
Keep it, but don’t merge in extra paths, and prefer per-target includes in CMake:

{
  "C_Cpp.default.configurationProvider": "ms-vscode.cmake-tools",
  "C_Cpp.default.mergeConfigurations": false,
  "C_Cpp.default.compileCommands": "${workspaceFolder}/build/compile_commands.json"
}

In your CMake, replace broad:

include_directories(${CMAKE_SOURCE_DIR})

with target-scoped:

target_include_directories(myTarget PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/include)

Option D — Tame recursive includes (newer setting):

{
  "C_Cpp.default.recursiveIncludes": {
    "reduce": "always",
    "order": "breadthFirst",
    "priority": "afterSystemIncludes"
  }
}

---

Clean up & verify

1. Run “C/C++: Reset IntelliSense Database” and “C/C++: Rescan Workspace.”
2. Reopen a file, recheck Log Diagnostics, and confirm the “Processing folder (recursive)” line no longer points at the common root.

---

If this helped, please consider marking the answer as Accepted so others can find it faster.