VS Code extension host terminated unexpectedly? Start with the host

Save work and capture the message

Save open files before you reload the window, disable extensions, or repeat a failure. If the editor is unstable, copy critical text to a safe local file first. Then record the exact notification, the time, the command or action that preceded it, and whether the editor recovered.

Write down the VS Code version, operating system, workspace type, active folder, and recent changes. Include an extension update, a new language runtime, a settings change, a remote connection, an authentication change, or a system update if one happened before the first failure. Timing is evidence. It is not proof that the most recent update caused the crash.

Note what still works. The editor window may remain usable while language features, source control, debugging, terminals, authentication, or a remote workspace stops responding. That difference helps you avoid calling every editor problem an extension-host problem.

Identify the failing host

Open Help and choose Process Explorer when the window remains usable. Look for extensionHost and compare it with renderer, shared, ptyHost, language-server, file-watcher, and remote-server processes. The names matter. A terminal failure is not an extension-host failure, and a renderer hang does not name an extension.

From a terminal, run code --status when the command is available. Keep the output with the exact VS Code version and context. Redact usernames, workspace paths, hostnames, repository names, account identifiers, and other private values before you share it.

Use Show Running Extensions to see which extensions run in the local extension host and which run in a remote or workspace host. An extension can be installed locally while its code runs somewhere else. That is why the phrase "extension host" does not, by itself, identify one extension or one computer.

Compare a session with extensions disabled

Start an empty window with all extensions disabled, then repeat the smallest action that triggers the failure. Keep the same workspace and remote context when that context is part of the problem, but avoid making several other changes at the same time.

• The failure disappears. An extension-related branch is plausible. Keep testing before naming one extension.
• The failure remains. The result does not support blaming an installed extension. Check the host, workspace, remote service, resource pressure, authentication path, or VS Code core branch.
• The test changes the context. Record that limitation. A clean local window does not clear a remote extension host, dev container, or workspace-specific configuration.

Do not uninstall extensions to make this comparison. Disabling them gives you a reversible test and preserves the state that another person may need to reproduce.

Use Extension Bisect only after the comparison

If the failure disappears with extensions disabled, use Help: Start Extension Bisect. VS Code changes which extensions are enabled and asks you to report whether the failure returns. Follow the prompts and record the test context.

Bisect can narrow a reproducible conflict. It does not prove that an extension is malicious, incompatible in every workspace, or the only cause of a crash. Test the result in the same workspace, host, and trigger. If the failure persists with every extension disabled, stop using an extension accusation as the explanation.

When the problem stops after one extension is disabled, record the extension identifier, version, host location, workspace, trigger, and the first version that showed the behavior. Give that record to the extension maintainer or the VS Code project with the redacted logs they request.

Separate local, remote, and web contexts

VS Code can run extension code in local, web, and remote extension hosts. A Remote-SSH session, dev container, or another remote workspace can fail on the remote side while the local editor still draws its window. The computer showing the message is not always the computer that needs the next check.

Record the connection type, host or container, workspace folder, operating-system version on that host, and whether the same action fails in an empty local window. Preserve remote access before you change a service, delete a server directory, or restart a container. Check the remote project's own logs and supported steps when the evidence points there.

If the crash follows high CPU or memory use, record the process and the timing before you change startup items or services. The Windows high-CPU guide covers the broader resource branch. A whole-editor hang belongs with the app-not-responding guide, while a browser process belongs with the browser crash guide.

Collect redacted evidence

Build a small evidence packet instead of sending a full user profile. Include the exact message, VS Code version, operating system, local or remote context, workspace type, extension list and versions when relevant, Process Explorer or code --status output, the all-disabled comparison, bisect result, and the timestamp of the last failure.

Add only the logs and extension-host profile that the relevant maintainer or project asks for. Remove credentials, tokens, SSH details, environment values, private source, user names, organization names, repository paths, and host addresses. If you cannot remove a secret with confidence, do not share the file.

Use the same trigger after each controlled change. A clean test that cannot be repeated in the original workspace is a clue, not a repair.

Avoid destructive resets

Do not delete extension folders, profiles, settings, caches, repositories, .git data, remote-server directories, container volumes, or credentials as a universal first step. Those actions can remove the evidence and create a second problem.

Do not disable organization security, endpoint controls, workspace trust, extension allowlists, or managed policy to force an extension to load. Ask the administrator when policy controls the failing path. Reinstalling or changing versions may be relevant after the evidence points there, but it is not a substitute for identifying the host.

Where OmniMend fits

On a supported local Windows PC or Apple Silicon Mac, OmniMend can organize non-secret operating-system, hardware, resource, update, and timeline evidence around the failure. It cannot inspect or bisect VS Code extensions, test a remote Linux host, repair an extension host, install a VS Code update, or prove that a physical component failed.

Use VS Code's own Process Explorer, code --status, disabled-extension comparison, and Extension Bisect for the editor diagnosis. If you want a separate record of the supported local machine's non-secret evidence, download OmniMend and redact the report before sharing it. Do not put source code, credentials, tokens, keys, extension logs, or proprietary workspace data into that record.