PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
VS Code runs extensions in separate Extension Host environments rather than letting them directly modify the editor’s user interface. Depending on the extension and how you use VS Code, that host can run on your local computer, on the machine holding a remote workspace, or in a browser worker. This separation helps protect the editor, but it does not make extension work free: once activated, an extension can still use CPU and memory while it handles files and editor events.
What the Extension Host does
The Extension Host is the environment in which VS Code runs extension code. It is separate from the editor’s UI implementation: extensions call editor functionality through the VS Code API instead of changing the UI directly. This boundary helps VS Code maintain stability and evolve its interface without making extensions dependent on its internal DOM.
“Separate” does not mean that every extension runs in one identical process beside the editor window. VS Code documents three host configurations: a local Node.js host, a remote Node.js host, and a web host. Which is available—and which one runs a particular extension—depends on the VS Code environment and the extension’s capabilities and configuration. Microsoft’s Extension Host documentation describes these configurations.
The host is where extension code executes; it is not a replacement editor or a second user interface. Extensions contribute features and use VS Code’s APIs to interact with editor functionality. Keeping that code out of the UI’s direct DOM gives VS Code room to change its UI implementation without automatically breaking extensions that depend on internal page structure. It also draws a boundary around the extension’s role: the extension can contribute behavior through supported mechanisms, but it does not get direct access to rewrite the editor’s UI.
#1 Best Overall
Where extensions run: local, remote, or web
| Host context | Where it runs | Runtime and access |
|---|---|---|
| Local | On the same machine as the VS Code user interface. | Node.js. The extension can use capabilities available to its Node environment. |
| Remote | On the machine or environment where the workspace resides, such as a container or other remote location. | Node.js. Workspace extensions can work near the workspace files; some extensions that use Node APIs or shell commands may need adaptation for remote use. |
| Web | In a browser, or locally using a Browser WebWorker runtime, depending on the web-host setup. | Browser WebWorker. No Node.js APIs or child processes; workspace file access uses the VS Code file-system API. |
The table describes capabilities, not speed. The official architecture documentation does not establish a benchmark ranking in which one host type is inherently faster than another. An extension’s workload and the environment in which it runs matter.
These contexts differ along several dimensions, not just distance from the screen. A local Node.js host runs beside the UI. A remote Node.js host runs where workspace files reside, which may be a container or another remote environment. A web host runs using a Browser WebWorker runtime and therefore lacks capabilities that Node.js extensions may use. For a comparison, ask four questions: where does the extension execute, which runtime does it use, how does it access workspace resources, and what capabilities does that runtime provide?
Those questions matter because an extension’s execution location is not necessarily the location where the user sees VS Code. In remote development, the user interacts with a local UI while workspace extensions execute with the remote workspace. In the web context, the extension’s browser runtime changes its available APIs. The host model explains these differences, but it is not a performance scorecard: the documentation does not say that local, remote, or web is categorically fastest.
How VS Code chooses a host
Host selection depends on which hosts are available, the extension’s capabilities, where it is installed, and its extensionKind preference. In that setting, workspace generally refers to the machine where workspace files live; ui refers to the machine running the user interface. An extension that can work in either environment can state an order of preference. In remote development, UI extensions run locally while workspace extensions run where the workspace resides. See Microsoft’s remote development guidance for the distinction.
This arrangement lets an extension work in the environment appropriate to its role. For example, an extension that needs to interact with workspace resources may run with the workspace, while one concerned with the user interface can run with the UI. The actual choice is not inferred from the extension’s name: it follows the manifest, capabilities, installation, and available host configuration.
The terms ui and workspace are useful shorthand for location preference, not a promise that every extension has one fixed location in every VS Code session. The available host configuration matters. An extension may also support more than one environment and express an order of preference. As a result, the answer to “Where does this extension run?” depends on the context in which VS Code is being used as well as on the extension’s declared support and configuration.
In a remote setup, this distinction can prevent a common misunderstanding: “installed in VS Code” does not necessarily mean “executing on the local machine.” A UI extension runs locally, while a workspace extension runs where the workspace resides. The appropriate placement is part of the architecture, especially for extensions that need workspace resources or rely on environment-specific capabilities.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →How an extension becomes active
An extension does not necessarily run all its code as soon as VS Code opens. Its package.json manifest declares an entry point and contributions, and activation events specify when its code should become active. The code can then register behavior through the VS Code API. This lets VS Code defer extension work until it is relevant.
- VS Code reads the manifest. It identifies the extension’s entry point and declared contributions, such as commands.
- An activation event occurs. The event may be associated with a situation in which the extension is needed. The official example is a Markdown extension that loads when a user opens a Markdown file.
- The extension’s code activates. It can register the behavior that implements its contribution, using VS Code APIs.
- The extension handles later work. Once active, it may respond to editor events or analyze files; that work consumes resources while it is performed.
A command extension illustrates the connection between declaration and implementation: its manifest can contribute a command, and its activation code can bind the command to an implementation with commands.registerCommand. Starting with VS Code 1.74.0, invoking a command declared in the manifest automatically activates its extension, so an explicit onCommand activation event is not required for that case. The details are in Microsoft’s Extension Anatomy guide.
The manifest and the implementation serve related but distinct purposes. A contribution such as a command tells VS Code about a feature the extension offers; the extension’s code registers the behavior that carries it out. Activation events determine when that code starts. This separation makes it possible to expose a declared feature without requiring all of the extension’s code to perform work from the moment the window opens.
The Markdown example illustrates the timing principle. If the relevant event is opening a Markdown file, the extension can be loaded when that event occurs rather than simply because VS Code has started. That avoids unnecessary CPU and memory use before activation. The benefit is deferral: once the file is opened and the extension becomes active, any analysis or response it performs still has a runtime cost.
There is also an important version detail for command authors and readers interpreting activation. Since VS Code 1.74.0, a command declared in an extension manifest automatically activates that extension when invoked. An explicit onCommand event is therefore not required for that declared-command case. The rule should not be generalized into a claim that every kind of extension work activates in the same way; activation depends on the events and contributions relevant to the extension.
Why extensions can affect performance
There are two different questions: whether an extension runs before it is needed, and how much work it does after it activates. Lazy activation addresses the first by postponing work until a relevant event. It does not eliminate the work that follows. An active extension may analyze files, respond to editor events, or do other computation, which can use CPU and memory.
VS Code’s process boundary and API design limit how extensions interact with the editor UI; they do not make an extension’s computation disappear. An extension cannot directly modify the UI DOM, but it can still perform resource-consuming work in its host. The Extension Capabilities Overview explains the separation as a way to protect VS Code’s stability and performance and to allow its DOM to change without breaking extensions. Its promise is a boundary, not a guarantee that extensions have no performance impact.
Activation timing therefore matters alongside workload. If code is deferred until a file type, command, or other relevant event is encountered, it avoids doing that work before activation. Once the event occurs and the extension starts, the resulting analysis or event handling still has a cost. A delay that appears only after a particular action is conceptually different from work that happens during startup, even though the architecture alone cannot identify which extension or operation caused a particular slowdown.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsWhat separation protects—and what it does not
- It protects the UI boundary: extensions use VS Code APIs rather than direct DOM access.
- It supports stability: extension code runs in an Extension Host rather than being given direct control of the editor’s UI implementation.
- It can defer work: activation events allow extensions to load when needed, avoiding unnecessary CPU and memory use before that point.
- It does not remove active work: computation and resource use continue to matter after an extension activates.
- It does not make all environments equivalent: local, remote, and browser hosts have different locations and capabilities.
Microsoft summarizes the purpose of the host boundary this way: “To ensure that extensions cannot interfere with the stability and performance of VS Code, and that we can continue to improve the DOM of VS Code without breaking existing extensions, we run extensions in an Extension Host process and prevent direct access to the DOM.” The statement describes the design aim and boundary; it should not be read as saying that extensions cannot consume resources. The same documentation says extensions are loaded lazily so they do not consume unnecessary CPU and memory before they are needed. Both points fit together: the architecture limits direct UI access and avoids some premature work, while active extension computation remains real work.
This distinction helps separate three ideas that are easy to conflate. First, isolation means extensions do not directly manipulate the UI DOM. Second, activation controls when extension code begins running. Third, workload describes what that active code does. Isolation is not a substitute for activation control, and activation control is not a way to erase the work performed after activation. The host provides the environment; extension behavior determines the work done there.
For that reason, “extensions are in a separate process” is not a complete explanation of performance. The process boundary is intended to protect stability and UI implementation, but an extension still runs code. Its analysis of files, responses to editor events, and other computation can use CPU and memory. Lazy loading can keep work from happening before it is relevant, but after activation the question becomes what work is occurring and when.
What changes in remote development and the browser
In remote development, the distinction between UI and workspace location is important. The UI remains on the local machine, while workspace extensions run where the workspace lives. VS Code APIs are designed to operate on the appropriate machine, but an extension that depends on Node APIs or shell commands may require adaptation when used remotely. An extension’s location is therefore part of understanding its behavior; “installed in VS Code” does not by itself mean “running beside the UI.”
Remote execution changes the context in which workspace extensions do their work, not the basic performance principle. They run near the workspace rather than beside the local UI, and extensions using Node APIs or shell commands may need adaptation to work remotely. The documentation does not establish a universal speed advantage or penalty for remote placement. It is safer to ask whether the extension supports that environment and where its work is meant to run than to infer performance from the word “remote.”
Web extensions have a different boundary. Their entry point is declared with browser rather than main, and they execute in a Browser WebWorker. They do not have Node.js APIs or module loading in the same way as a Node extension. They cannot create child processes or run executables, and they use the VS Code file-system API for workspace file access. These constraints change what work a web extension can perform; they are not a claim that web extensions are universally faster. Consult Microsoft’s Web Extensions guide for the browser-specific model.
The browser entry point is a technical distinction, not just a different label for a Node entry point. A web extension executes in a browser worker, without Node.js APIs or module loading in the same way as a Node extension. It cannot start child processes or run executables. For workspace files, it uses VS Code’s file-system API. Those limitations define what implementation approaches are available; a Node-based extension that relies on unavailable capabilities may need a different implementation to support the web.
That difference can help explain why an extension may behave differently across desktop, remote, and web sessions. The available runtime and file-access route differ. But capability differences alone do not say how much CPU or memory an extension will use, and they do not support a universal speed comparison. The host context tells you where and with which runtime extension code executes, not whether a particular workload is efficient.
How to interpret the architecture when VS Code feels slow
The Extension Host explains how extension code is kept apart from the UI and why not all extension work needs to happen at startup. It cannot, by itself, diagnose a particular performance problem. The official documentation cited here describes architecture and activation, not a measured slowdown, a universal resource threshold, or a ranking of individual extensions.
For a useful first distinction, note when the delay happens and what event precedes it. A problem that appears when a relevant file is opened, a command is invoked, or editor activity begins may coincide with extension activation or later event handling. That timing is a clue for investigation, not proof that an extension caused the delay. Likewise, a remote workspace or web session changes where code runs and which APIs it can use, but the host type alone does not establish that the session should be faster or slower.
It is useful to distinguish a delay before activation from a delay after activation. Before activation, lazy loading is intended to avoid unnecessary extension work. After activation, the extension may begin analyzing files or responding to events. If a delay occurs near a file opening or command invocation, the timing can suggest which kind of extension activity to investigate, but timing by itself cannot identify the cause. The architecture gives a vocabulary for asking better questions; it does not provide a diagnosis or a benchmark for a specific extension.
When comparing sessions, keep the location and runtime in view. A remote workspace can place workspace extensions on the remote machine while the UI stays local. A web extension uses a browser worker and has different API and process capabilities. Those facts help explain where work can occur and what it can do. They do not show that one host is inherently more performant, and they do not establish that a slowdown is caused by an extension rather than some other factor.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
The architectural facts support a restrained conclusion: lazy loading reduces unnecessary work before activation, process separation limits direct UI access, and neither mechanism guarantees that active extensions use no resources. To explain a specific slowdown, you need evidence about the extension and work involved; the host model tells you where and under what runtime that work can happen.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Questions readers often ask
Does the Extension Host run every extension at startup?
No. VS Code uses activation events to load extensions lazily. The official example is the Markdown extension, which should be loaded when a user opens a Markdown file. Deferring activation helps avoid unnecessary CPU and memory use before that event, although work can begin once the extension activates.
Does running extensions in a separate process guarantee that VS Code cannot slow down?
No. The separate host and restriction on direct DOM access establish a boundary that supports stability and protects the UI implementation. They do not eliminate the CPU and memory an extension may use for analysis, event handling, or other computation.
Where do VS Code extensions run in remote development?
It depends on the extension’s role and configuration. UI extensions run on the local machine running the interface; workspace extensions run where workspace files reside. Host availability, capabilities, installation, and the extension’s extensionKind preference all contribute to selection.
Recommended Free Tools
Can a web extension use Node.js or launch a process?
A web extension runs in a Browser WebWorker and does not have Node.js APIs in the same way as a Node extension. It cannot create child processes or run executables, and it uses the VS Code file-system API for workspace file access.
Does a remote or web host run extensions faster?
The host descriptions establish location and capabilities, not a benchmark ranking. The documented architecture does not support a general claim that local, remote, or web extensions are inherently faster. Workload and environment still matter.
What changed for command activation in VS Code 1.74.0?
Starting with VS Code 1.74.0, invoking a command declared in an extension’s manifest automatically activates that extension. An explicit onCommand activation event is not required for that declared-command case.
Frequently Asked Questions
Does the Extension Host run every extension at startup?
No. VS Code uses activation events to load extensions lazily. For example, the Markdown extension should be loaded when a user opens a Markdown file. Work may still occur after activation.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Does a separate Extension Host guarantee extensions cannot slow VS Code down?
No. The host boundary limits direct access to the UI DOM and supports stability, but active extension work such as file analysis or event handling can still use CPU and memory.
Where do extensions run in a remote VS Code workspace?
UI extensions run on the local machine running the interface, while workspace extensions run where the workspace resides. The available hosts, extension capabilities, installation, and extensionKind preference affect selection.
Can VS Code web extensions use Node.js APIs or create child processes?
No. Web extensions run in a Browser WebWorker, lack Node.js APIs in the same way as Node extensions, cannot create child processes or run executables, and use the VS Code file-system API for workspace access.
Is a remote or web extension faster than a local one?
The documented host configurations describe location and capability, not a benchmark ranking. They do not establish that any host type is universally faster.
Free tools Windows power users keep installed
One-click scans. No signup required.
What does VS Code 1.74.0 change about command activation?
Since VS Code 1.74.0, invoking a command declared in the extension manifest automatically activates its extension; an explicit onCommand event is unnecessary for that case.
The Bottom Line
VS Code’s Extension Host separates extension code from the editor’s UI, and activation events let VS Code defer extension work until it is relevant. Hosts can be local, remote, or browser-based, with different runtimes and capabilities. These boundaries support stability and reduce unnecessary pre-activation work, but they do not remove the CPU and memory cost of what an active extension does.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
