Filtering undesirable clangd header includes at the LSP/neovim level

I use neovim with clangd and nvim-lspconfig. I’m a fan of the completion feature, including its ability to add required #include directives when a given completion requires them. But, I happen to work on a code base that doesn’t quite meet the “include what you use” philosophy that the underlying clangd infrastructure requires.

Despite these difficulties, I almost have completion with header insertion working satisfactorily. If I could onlycoax neovim into excluding a small number of specific undesirable header files (from an exclude list) than I’d have the behavior that I desire. That is, I’d be able to have almost all of the benefits that come from header insertions on completion, with few or no annoyances that are peculiar to the code base I work on. (If it matters, there are one or two headers that are supposed to be included transitively, so if I could only avoid these superfluous direct inclusions than I’d have no issues.)

One way to deal with this would be to add some “IWYU pragma: private” directives to these header files, but for reasons that I won’t go into right now, that is not really workable.

What I think might work is to intercept the undesirable inclusions using the LSP interface, by intercepting the additionalTextEdits, as explained here:

Turning up the verbosity on clangd shows me that the relevant completions (those with the undesirable header inclusions) have an associated additionalTextEdits newText string with the specific header includes that I would like to exclude. Intuitively, it seems like it ought to be possible to intercept all completions from the clangd LSP interface, and then remove the specific header inclusions that I don’t want seeing if the string matches my own short ad-hoc exclude list. I haven’t been able to figure out how to do that myself, though.

Any assistance would be greatly appreciated. I realize that this is really a problem with clangd, but it seems unlikely that they’ll make the feature more configurable anytime soon. Meanwhile, I am already tantalizingly close to getting the behavior that would be most useful to me.