Remote extension host crashes when Copilot Chat is installed in Dev Container during search for references with C++ extension

[sagischwarz]

Environment

• OS and Version: macOS 26.3 (25D125)
• VS Code Version: 1.109.5
• C/C++ Extension Version: 1.109.5
• If using SSH remote, specify OS of remote machine: Linux (via Docker Desktop)

Bug Summary and Steps to Reproduce

Bug Summary:
The remote extension host crashes when Copilot Chat is installed in a dev container during longer search for references with C++ extension

Steps to reproduce:

• Open a C++ project in a Docker development container using the Dev Containers Extension
• Install the C/C++ extension and the Copilot Chat extension in the container
• Use the "Go To References" feature on a variable or a function with a lot of references where the search takes some time
• The remote extension host crashes after a few seconds with the message "The remote extension host terminated unexpectedly" and restarts reproducibly

Steps to fix:

• Disable or uninstall Copilot Chat extension
• "Go To References" works without any problems on all symbols (even if it takes longer)

Configuration and Logs

2026-02-25 09:16:07.266 [warning] No ptyHost heartbeat after 6 seconds
2026-02-25 09:16:22.651 [warning] No ptyHost heartbeat after 6 seconds
2026-02-25 09:17:34.905 [warning] No ptyHost heartbeat after 6 seconds
2026-02-25 09:17:39.243 [info] [127.0.0.1][f6f627b1][ExtensionHostConnection] <37220> Extension Host Process exited with code: null, signal: SIGKILL.
2026-02-25 09:17:39.741 [error] [127.0.0.1][f6f627b1][ExtensionHostConnection] Unknown reconnection token (seen before).
2026-02-25 09:17:40.131 [info] [127.0.0.1][0acec5d3][ExtensionHostConnection] New connection established.
2026-02-25 09:17:40.152 [info] [127.0.0.1][0acec5d3][ExtensionHostConnection] <39390> Launched Extension Host Process.
2026-02-25 09:17:40.787 [info] [127.0.0.1][0acec5d3][ExtensionHostConnection] <39390> [reconnection-grace-time] Extension host: read VSCODE_RECONNECTION_GRACE_TIME=10800000ms (10800s)

Other Extensions

The issue is resolved when the Copilot Chat extension is disabled or uninstalled.

Additional context

I had already created an issue for the Copilot Chat plugin, but I've been told that this is a problem of the C++ extension and I have to create a ticket here. See microsoft/vscode#297663

[sean-mcmanus]

@sagischwarz I added a comment in the vscode issue. I don't think the extension host crash is caused by our extension.

[sean-mcmanus]

@sagischwarz Are you able to set C_Cpp.loggingLevel to "Debug" and check the C/C++ logging for logging related to findAllReferences to see what progress it makes?

i.e. look for LSP: (invoked) cpptools/findAllReferences: file: (id: 39)

and then search for the "id: " whatever that is to find:

LSP: Sending response (id: 39)

if it exists.

Also, do you have the C/C++ DevTools extension installed? That has some find all references related Copilot Chat features added.

[sagischwarz]

Hi @sean-mcmanus, thanks for taking care and commenting on the other issue!

Log Output

I set the logging level to "Debug" and searched for references. There are only two entries with the same ID relating to findAllReferences directly at the beginning of the log:

LSP: (received) cpptools/findAllReferences: file:///workspaces/projectname/src/directory/file.cpp (id: 24)
LSP: (invoked) cpptools/findAllReferences: file:///workspaces/projectname/src/directory/file.cpp (id: 24)

There are about 11000 further log messages directly after the call, but I cannot paste the whole log, since it is full of sensitive information. Here's an example how the log continues:

Populating file name cache...
Done populating filename cache. Elapsed time: 116 ms
Requesting a custom configuration for: /workspaces/projectname/unit-test/otherfile.cpp
Custom configurations received:
  uri: file:///workspaces/projectname/unit-test/otherfile.cpp
  config: {
  "includePath": [

[...]

LSP: (received) cpptools/didChangeCustomConfigurationHighPriority
LSP: (invoked) cpptools/didChangeCustomConfigurationHighPriority
LSP: (received) cpptools/didChangeCustomConfiguration
LSP: (received) cpptools/finishedRequestCustomConfig: file:///workspaces/projectname/unit-test/otherfile.cpp
Received a custom configuration for: file:///workspaces/projectname/unit-test/otherfile.cpp
LSP: (invoked) cpptools/finishedRequestCustomConfig: file:///workspaces/projectname/unit-test/otherfile.cpp
LSP: (invoked) cpptools/didChangeCustomConfiguration
Requesting a custom configuration for: /workspaces/projectname/unit-test/anotherfile.cpp
Custom configurations received:

[...]

Shutting down IntelliSense server: /workspaces/projectname/unit-test/otherfile.cpp
sending compilation args for /workspaces/projectname/unit-test/otherfile.cpp
  include: /workspaces/projectname/unit-test

[...]

As soon as the remote extension host crashes, the log disappears, so I have to be fast and copy it before it's gone. Is there a way to persist the log? I might be missing some output right before the crash.

One more observation: The crash reproducibly happens at the same number of confirmed files, in this example at 3/29:

C/C++ DevTools

Yes, I also have C/C++ DevTools 0.2.0 installed. I disabled it, but the remote extension host still crashes.

[sean-mcmanus]

@sagischwarz We have not implemented a way to persist the log (the extension host crashing and the logs not being accessible has not been a problem for us). But the 3 out of 29 confirmations and the lack of a return log implies that we never return a result to VS Code (this could also be confirmed via debugging our open source TypeScript which runs in the extension host, see https://github.com/microsoft/vscode-cpptools/blob/main/Extension/src/LanguageServer/Providers/findAllReferencesProvider.ts#L50 and https://github.com/microsoft/vscode-cpptools/blob/main/Documentation/Building%20the%20Extension.md), so during this time there is no find all references related code running in our extension host that could trigger the crash -- you should instead see cpptools and cpptools-srv processes running.

[sean-mcmanus]

@sagischwarz As mentioned in the VS issue, if you can use https://github.com/microsoft/vscode-bisect to locate a VS Code version which doesn't repro the bug that can help convince them that it's a VS Code bug (and possibly find the commit that caused it).