OpenKal grants omit MSVC headers when Visual Studio is installed outside Program Files

Start with src/engine/clangd/grants.cpp and its grant interface in src/engine/clangd/grants.cppm; trace how toolchain root arguments and include paths become grants. Then inspect existing grant tests and add coverage for an MSVC installation outside Program Files, including separate and joined root arguments. Done means derived grants cover the MSVC header directory and the regression test passes.

Version

Extension and server: 0.0.20. Bundled clangd: 23.1.0-mcppls.9.

The diagnostic bundle identifies the payload as a from-source build of 8923698cde330586bca99534dedea012d161dcf7 with dirty: true, built on 2026-11-06. The analysis below uses that commit's source.

Editor

Visual Studio Code 1.145.2, Windows x64.

Operating system

Windows, build 10.0.26300.9711.

Build system

mcpp; the captured project model reports producer version 2026.10.31.3, LLVM 23.1.3, target x86_64-pc-windows-msvc, MSVC STL 14.51.36231 and Windows SDK 10.0.26100.0.

What happened

Opening an mcpp C++ modules project produces missing MSVC runtime/STL header diagnostics even though those files exist and the toolchain paths are correctly identified. Visual Studio is installed outside Program Files, at D:/VisualStudio2026.

The first relevant failure in the captured session is:

2026-11-08T09:35:07.182Z
clangd could not scan D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/modules/std.ixx
for its modules: fatal error: 'vcruntime.h' file not found

Other scans fail with 'excpt.h' file not found, 'type_traits' file not found, etc. std and other modules then get stand-ins; subsequent errors include use of undeclared identifier 'std'. The final plan has 148 issues, 18 left-out units and 19 stand-ins. Resetting the workspace cache during this session did not resolve the problem.

What you expected

clangd should be able to read headers belonging to the selected MSVC toolchain regardless of where Visual Studio was installed. A correctly detected toolchain should not require a manual directory grant.

Evidence and likely cause

The compile command explicitly contains:

-Xmicrosoft-visualc-tools-root D:\VisualStudio2026\VC\Tools\MSVC\14.51.36231
-Xmicrosoft-windows-sdk-root C:\Program Files (x86)\Windows Kits\10
-Xmicrosoft-windows-sdk-version 10.0.26100.0
--target=x86_64-pc-windows-msvc

However, the engine-start event's grants contains only this part of the MSVC installation:

{
  "path": "D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/modules",
  "unchanging": false,
  "writable": false
}

Neither D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/include nor an ancestor covering it appears in the grant list. Default system grants include C:/Program Files, C:/Program Files (x86) and C:/ProgramData, which cover the Windows SDK but not this Visual Studio installation. engine.confine is already false; the explicit OpenKal directory grants are still supplied.

In grants.cpp at the payload commit, PATH_FLAGS handles -I, -isystem, -imsvc, etc., but not -Xmicrosoft-visualc-tools-root or -Xmicrosoft-windows-sdk-root. system_roots() uses the Program Files/ProgramData environment variables. Thus, the MSVC modules directory is collected from its source path, while the sibling header directory is missed.

The grant interface documentation explains that an engine given explicit grants can only access those directories. This appears to be an mcppls grant-derivation defect, rather than a missing header installation or a clangd parser defect.

Independent checks

All three files exist:

D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/include/vcruntime.h
D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/include/excpt.h
D:/VisualStudio2026/VC/Tools/MSVC/14.51.36231/include/type_traits

With the same explicit MSVC/SDK flags, the native LLVM 23.1.3 compiler successfully checks:

#include <vcruntime.h>
#include <excpt.h>
#include <type_traits>
static_assert(std::is_same_v<int, int>);

Running the installed clangd.okb directly through okrun.exe --check=..., without mcppls's explicit grant list, also reports All checks completed, 0 errors. A small module/importer probe using the same toolchain flags passes too. These checks establish that the files are readable and the bundled engine can handle them when launched independently; they are not a constrained-grant regression test.

Steps to reproduce

1. Install Visual Studio/MSVC outside the default Program Files roots, for example under D:/VisualStudio2026.
2. Open an mcpp modules project whose compile commands select it using -Xmicrosoft-visualc-tools-root and import its std module.
3. Use the OpenKal engine payload with default mcppls.grants: [].
4. Inspect the engine's derived grants and module-scanning diagnostics: the MSVC modules directory is accessible, but its sibling include directory is missing from the grant coverage.

Suggested fix / workaround

Derive grants from the selected toolchain roots as well as include flags, covering the MSVC headers and supporting SDK/toolchain-root arguments with separate or joined values. A regression test should place MSVC outside the default system roots and verify that the derived grants cover its header directory.

A possible temporary workaround is:

"mcppls.grants": [
  "D:/VisualStudio2026/VC/Tools/MSVC"
]

Then restart the language server. This workaround has not yet been verified in the editor.

Diagnostic bundle

• I attached the diagnostic bundle

The local bundle is mcppls-bundle-20261108T094157.162Z.zip; relevant excerpts are included above. The full ZIP is not attached to this issue.

The same session also records failed mcpp model refreshes with previous compiler unit is occupied or unknown, after which mcppls retains the cached model. That is a separate observation; this report concerns the header-directory grant omission, which is visible before those refresh failures.