My editor underlines every include in red but the code compiles and runs fine

You have identified it exactly: two different programs are looking for those headers, and only one of them is doing the build.

• The compiler is invoked by the build system, which knows your board, your framework and your libraries, and passes a long list of include directories on the command line. It finds everything. That is why the firmware works.
• The editor's language server is a separate analyser providing squiggles and autocomplete. It has no idea what your build system is doing unless somebody tells it, and by default it guesses at a generic set of paths.

So the red underlines are the analyser being uninformed, not the build being broken. That is worth internalising because it changes the fix: you are not correcting an error, you are giving a second tool the same information the first one already has.

The general lesson transfers well beyond this ecosystem: whenever the editor and the build disagree, believe the build.

The same split exists in almost every toolchain. The editor's analyser is a convenience layer that approximates the build, and there is a mechanism somewhere to feed it the real thing — a compilation database, a generated configuration file, a project index.

Worth learning what that mechanism is for whatever you work in. It converts a permanent low-grade annoyance into a solved problem, and it also fixes autocomplete and go-to-definition, which are the things you actually lose.

How to make them agree, in order of how well it works:

1. Regenerate the project's editor configuration. The build system usually has a command that emits the include paths and defines for the analyser. This is the intended mechanism and it is the fix in most cases — often available from the command palette, or it happens on a full build.

2. Do a full build first. The paths cannot be generated until the dependencies have been resolved and downloaded. On a fresh checkout the analyser is wrong until the first successful build, which is why this appears on new projects and fixes itself later.

3. Reload the window. The analyser caches aggressively and frequently keeps stale paths after a change. Reloading is not superstition here; it is genuinely the step that applies the new configuration.

4. Check you opened the right folder. Opening a subfolder rather than the project root means the analyser cannot find the project configuration at all, and this is a surprisingly common cause.

One thing to avoid: manually adding paths to the analyser configuration by hand.

It works, and then a library updates or you add a board and the hand-written list is wrong, silently, in a file nobody remembers editing. The generated version is regenerated; the hand-edited version rots.

If you must add something by hand, add it in the place the generator does not overwrite, and leave a comment saying why.