Can VS Code Extensions Run in Web Workers? Exploring Browser‑Based Plugin Architecture

A few months ago I got beta access to GitHub Codespaces, and at the same time I've been refactoring the KAITIAN architecture, also referencing some VS Code implementations; because the content is varied, I'm sharing some interesting points I encountered (in one article).

Web Worker Extension Thread

In my Zhihu column "From Scratch – VSCode Plugin Execution Mechanism" I explained that VS Code plugins run in a separate Node.js process, an architecture also used by the open‑source Thiea project and the KAITIAN IDE developed by my team. To use extensions, each session must start a container environment for file editing and plugin execution.

We needed more customized solutions, such as reusing the editor and plugins without a container, similar to early CodeSandbox. We refactored KAITIAN's file system into an abstract, replaceable layer, allowing us to use BrowserFS or MemoryFS for file I/O in pure‑browser environments. This raised the idea of running plugins in the browser via Web Workers.

During experimentation, I discovered that VS Code itself has a similar direction. In recent VS Code versions (1.52+), the Settings panel under Extensions includes an Enable web worker extension host option, though it currently has no effect.

You can still try Web Worker extensions via the VS Code Web Playground (https://vscode-web-test-playground.azurewebsites.net/?enter=true).

To verify that an extension runs in a Web Worker, open DevTools → Network and you will see many web‑worker scripts being loaded, including Emmet, Merge Conflict, and TypeScript Language Features.

This is currently a test version, but the Web Worker plugin experience is expected to be available in GitHub Codespaces soon.

TypeScript tsserver.web

Curious, I searched the TypeScript repository and found a pull request from the VS Code team titled Adds experimental support for running TS Server in a web worker #39656 (https://github.com/microsoft/TypeScript/pull/39656).

The PR has been merged into the main branch and is slated to be usable in TypeScript 4.2. I plan to write a detailed article on its underlying principles.

Can All Extensions Run in Worker Threads?

Unfortunately, the answer is no. While Web Worker extensions have clear advantages in browser‑based (or Cloud IDE) environments by reducing client‑server communication overhead, they cannot replace every Node.js extension. Workers can substitute extensions that do not depend on file I/O, but they cannot emulate plugins such as Debugger or Terminal, which require deeper integration.