Why Cursor, Windsurf, and Copilot Are All Built on VS Code

June 23, 2026 · updated June 25, 2026 · The Engine Behind Every AI Code Editor (part 1)

▶ Watch on YouTube & subscribe to The Stack Underflow

Every AI code editor that has made headlines in the last two years — Cursor, Windsurf, GitHub Copilot — feels brand new. Different branding, different pricing, different AI models underneath. But look past the marketing and you will find the same skeleton inside every single one of them: VS Code. Not “inspired by” VS Code. Actually VS Code — its processes, its protocols, its extension system, running right there on your machine.

That convergence is not a shortcut. It is a deliberate architectural choice, and understanding why these editors converge on VS Code tells you exactly what the AI layer can and cannot do, and why some things that seem impossible in an extension suddenly become possible in a fork.

The one-sentence version: Cursor and Windsurf are forks of VS Code’s open-source codebase; Copilot is an extension on top of the standard editor — the AI is a layer, VS Code is the skeleton, and the skeleton itself is four separate processes working together.

The Three Flavors of “Built on VS Code”

Not all AI editors use VS Code the same way, but they all use it:

A fork means the team cloned Microsoft’s open-source microsoft/vscode repository and created their own derivative. They can change anything — UI layout, keybindings, which model gets called, how the context window is populated. An extension means the AI features live in a plugin that loads into the standard editor without modifying VS Code itself.

Both approaches inherit VS Code’s editing primitives for free: syntax highlighting, go-to-definition, the integrated terminal, the file tree, the Debug Adapter Protocol (DAP). The AI features are layered on top. They changed the skin. They kept the skeleton.

One nuance worth knowing: the repository Microsoft publishes is called Code - OSS and is MIT-licensed. The product you download as “Visual Studio Code” adds proprietary assets on top — the Visual Studio Marketplace integration, parts of the Remote Development extensions, the C#/.NET debugger, telemetry keys, and the update service. When Cursor or Windsurf fork, they fork Code - OSS, then wire in their own extension gallery and AI infrastructure (microsoft/vscode GitHub wiki, 2024).

VS Code Is Not One Program

Here is the part that surprises most developers: VS Code is not a single process. It is an orchestration of several isolated processes that coordinate to produce what looks like one editor. This multi-process architecture predates AI editors by years — it was designed for stability and security, not for AI. But it turns out to be exactly the right shape for AI integration.

┌──────────────────────────────────────────────┐
│           VS Code Window (Workbench)          │
│   Electron renderer — Chromium, sandboxed     │
│   No Node.js access since late 2022           │
└──────────────────┬───────────────────────────┘
                   │  IPC via message ports
         ┌─────────┼───────────────┐
         ▼         ▼               ▼
   Extension    Shared         Main Process
     Host       Process        (lifecycle,
  (Electron     (file watch,   window mgmt,
  utility       terminals)     OS dialogs)
  process,
  Node.js)
         │
         │  LSP (JSON-RPC)
         ▼
   Language Server(s)
   one per language, own process
   (tsserver, pylsp, rust-analyzer ...)

The sandboxed renderer is the Chromium window you see — it draws pixels, handles mouse clicks, and renders the Monaco editor. Since VS Code’s sandbox migration (shipped incrementally through 2022-2023), the renderer has zero Node.js access. It cannot touch the file system directly. Every privileged operation goes through a message-port bridge to a process that can (code.visualstudio.com/blogs/2022/11/28/vscode-sandbox).

The Extension Host is where all installed extensions run — including every AI extension. Microsoft contributed a new “utility process” API to Electron specifically to enable this: the extension host now runs as an Electron utility process spawned from the main process, with full Node.js access and its own child-process spawning capability. It communicates with the sandboxed renderer via Web API message ports, bypassing the main process for performance. This isolation is intentional: a buggy or slow extension cannot freeze your editor UI.

Language Servers implement the Language Server Protocol (LSP), a JSON-RPC protocol Microsoft introduced alongside VS Code in 2016. LSP’s core insight is that “editor smarts” — autocomplete, hover docs, go-to-definition, find-all-references, rename symbol — can be separated from the editor itself into a standalone server process. The editor and the server speak a common protocol; you write one language server and every LSP-compatible editor gets those features for free. The current LSP specification is version 3.18 (microsoft.github.io/language-server-protocol). TypeScript ships its own tsserver; Python has pylsp; Rust has rust-analyzer. Each runs as its own process, independent of the editor.

The integrated terminal is xterm.js rendered in the editor’s webview, connected to a real shell process through a pseudoterminal (pty). On macOS and Linux this is a POSIX pty. On Windows 10 and later, VS Code defaults to ConPTY — the Windows Console API’s native pseudoterminal implementation, introduced in Windows 10 build 18309. ConPTY works differently from a POSIX pty: it maintains compatibility with the Windows Console API and considers itself the viewport owner, which is why the terminal occasionally redraws unexpectedly after certain operations (code.visualstudio.com/docs/terminal/advanced).

The Debug Adapter Protocol (DAP) mirrors LSP’s architecture, but for debuggers. Current spec is version 1.71.0 (microsoft.github.io/debug-adapter-protocol). A debug adapter translates between VS Code’s generic debug UI — breakpoints, variable inspection, call stacks, REPL — and a language-specific debugger like GDB, the Python debugger, or the Node.js inspector. One UI, N debuggers, all speaking the same protocol.

Why This Architecture Matters for AI Editors

The multi-process design is what makes AI integration tractable. Consider what an AI agent actually needs to do:

An AI editor does not need to rewrite any of these systems. It hooks into what VS Code already provides. That is why forking VS Code is so appealing: in days, a team has a working AI editor with language-aware completions, file-tree navigation, debugging, and a terminal — because VS Code already built all of that.

The extension API does have hard limits, though. Extensions have no access to the DOM of the VS Code UI. They cannot apply custom CSS to core UI elements, cannot inject HTML into the editor chrome, and cannot intercept all keyboard events at a global level (code.visualstudio.com/api/extension-capabilities/overview). This is a deliberate Microsoft policy to protect their design freedom and keep extensions from breaking across VS Code updates. It is also precisely why teams fork: a fork removes those restrictions entirely.

Remote Development: One More Layer

VS Code’s Remote Development model deserves its own section because it directly shapes what AI editors can and cannot do in cloud-hosted environments.

Your local machine                Remote machine (SSH / container / tunnel)
┌─────────────────┐               ┌──────────────────────────────────┐
│  VS Code UI     │               │  VS Code Server                  │
│  (renderer +    │◄── tunnel ───►│  (extension host, language       │
│   local exts)   │               │   servers, filesystem, terminal) │
└─────────────────┘               └──────────────────────────────────┘

The key insight: VS Code Server is the same extension host that runs locally, just deployed on the remote machine. Your UI runs locally; your extensions, language servers, and terminal run where the code lives. Three connection modes exist:

• Remote - SSH: Connects to any machine you can reach via SSH. VS Code Server installs itself on the remote host on first connect.
• Dev Containers: Spins up a Docker container defined by a devcontainer.json; VS Code Server runs inside it.
• Remote Tunnels: Creates an authenticated secure tunnel (no SSH configuration needed) through Microsoft’s relay service — this is the proprietary-adjacent part that requires the Microsoft-distributed VS Code rather than a bare Code-OSS build.

The Remote Development extensions are partly proprietary: the connection-negotiation components use restricted licensing tied to the Visual Studio product family (github.com/microsoft/vscode/wiki). This is why VSCodium (a pure Code-OSS build) cannot use Remote - SSH out of the box, and why Cursor and Windsurf ship their own remote connectivity solutions.

How to Apply This as a Developer

Concrete guidance grounded in the architecture above:

Choosing between an extension and a fork: If your AI feature needs to modify VS Code’s core UI chrome, intercept global keyboard events, or ship custom UI at the shell level, you need a fork. If you can build inside the WebView API, TreeView, or inline-chat extension points, an extension is simpler to maintain and works in every VS Code-based editor including Cursor and Windsurf.

Understanding context limits: When you ask Cursor’s Composer or Windsurf’s Cascade to read your codebase, they are building a local embedding index, then passing relevant file excerpts into the model’s context window. They are not passing a live feed of your language server’s semantic model. LSP queries are possible from the extension host, but they add latency — most AI editors use file text plus embeddings rather than live LSP queries for broad context.

Extension compatibility in forks: Because Cursor and Windsurf maintain VS Code’s extension API, most VS Code Marketplace extensions install and work. Extensions that depend on proprietary Microsoft services — certain GitHub integrations, Live Share, some Remote Development features — may not work identically. The closer the fork tracks upstream VS Code, the better compatibility tends to be.

Remote AI workflows: Cursor’s Cloud Agents (since early 2026) and Windsurf/Devin’s cloud execution model both extend the remote architecture: the agent runs in the cloud while your local editor remains the UI. This mirrors VS Code’s own remote model, just with the agent as the “remote user” rather than a human at an SSH terminal.

Common Misconceptions

“Cursor has its own editor engine.” It does not. Cursor is VS Code with AI features added. The text you type is rendered by Monaco — VS Code’s editor component, the same one that powers VS Code itself and even the web version at vscode.dev. Monaco handles syntax highlighting, bracket matching, multi-cursor editing, and the virtual document model. Cursor did not replace any of that.

“Copilot has special API access that third-party extensions don’t get.” GitHub Copilot ships as two regular VS Code extensions (GitHub.copilot and GitHub.copilot-chat) and uses the same extension APIs available to any publisher. The tight feel comes from first-class UX design and Microsoft’s ability to ship proposed APIs to themselves in stable releases — a small but real advantage. Architecturally, Copilot is just a very well-made extension.

“The AI understands your code semantically.” The AI model receives text tokens — file contents, selected snippets, whatever the extension author decides to include in the prompt. Unless the extension explicitly queries the language server via LSP and includes those results in the prompt, the model has no live connection to the semantic index. Most AI editors complement file-text context with embedding-based retrieval, not live LSP queries.

“Forked editors always lag dangerously behind VS Code security patches.” Lag is a product decision, not an architectural necessity. Cursor and Windsurf both track upstream VS Code and pull changes regularly. The risk is merge conflicts on their custom patches, not an inability to update. The lag in practice tends to be weeks to a couple of months for major VS Code releases.

“Windsurf is still a standalone Codeium product.” As of June 2026, Windsurf has been rebranded to Devin Desktop following Cognition’s acquisition of the Codeium IP and team (after Google acquired the founding team in a separate $2.4B deal in July 2025). The Cascade agent reached end-of-life July 1, 2026, replaced by Devin Local — a Rust-based agent roughly 30% more token-efficient with subagent support.

Frequently Asked Questions

Why do Cursor and Windsurf fork instead of just writing extensions?

Extensions are sandboxed by design. They cannot modify VS Code’s core UI chrome, cannot change the command palette’s fundamental UX, and cannot intercept all keyboard events globally. A fork removes those restrictions entirely. If you want to redesign the sidebar, embed a persistent AI panel that feels native to the shell, or change how the editor handles every keystroke for autocomplete, you need a fork. Extensions give you UI contribution points; forks give you the entire codebase.

If they are all VS Code, why do they feel so different?

The differentiation lives entirely above the VS Code layer: the AI models they call, the prompts they construct, the codebase indexing they do, the context they gather and rank, and the UX flows they design. A great forked editor is differentiated by what it builds on VS Code — not by replacing it.

Does this mean my VS Code extensions work in Cursor and Windsurf?

Mostly yes. Both forks maintain VS Code’s extension API compatibility, so most extensions install with one click from their built-in galleries. Extensions that depend on proprietary Microsoft services — some Live Share features, certain GitHub authentication flows, Remote Tunnels — may not work identically because those services are tied to the proprietary VS Code distribution rather than Code-OSS.

What is LSP and why did it matter so much?

Before LSP, every editor had to implement language features (autocomplete, go-to-definition, diagnostics) from scratch for every language. After LSP, a language team writes one server and every LSP-compatible editor inherits those features. Microsoft created LSP alongside VS Code in 2016; it is now an industry standard at version 3.18, adopted by Neovim, Emacs, JetBrains IDEs, Helix, and dozens more. When you get Rust autocomplete in Cursor, that is rust-analyzer — a language server Microsoft and the Rust community wrote — running through the same LSP connection it uses in stock VS Code.

What is DAP and how does it relate to AI editors?

The Debug Adapter Protocol (DAP, current spec 1.71.0) does for debuggers what LSP does for language servers. One generic debug UI in VS Code; N debug adapters translating to N language-specific debuggers. AI editors inherit all of this for free from their VS Code base. When an AI agent runs your tests and parses failures, it can optionally query the debug adapter to get structured variable state rather than parsing terminal output — a richer signal for deciding what to fix next.

How does the extension host sandboxing affect AI extensions like Copilot?

Since VS Code’s sandbox migration completed in 2022-2023, the renderer process has no Node.js access. Extensions — including Copilot — run in the Extension Host, which is an Electron utility process with full Node.js. This means Copilot can read files, make HTTPS calls to the GitHub Copilot API, and write edits back to the document through VS Code’s API. It cannot directly touch the DOM or renderer memory, but it does not need to. The extension API surfaces everything it needs through documented, stable channels.

Where This Fits in the Series

This is the opening episode of VS Code Decoded — a series that cracks open how the editor actually works, from the Electron shell down to the language server protocols and beyond. The next episode looks at what happens when an extension crashes and why your editor keeps running: Why VS Code Survives Extension Crashes.

To go deeper on the language intelligence layer, see How Autocomplete and Go-to-Definition Work. For remote and container-based development, VS Code Remote Development Explained covers the VS Code Server architecture in full detail. And if you want to see how these primitives underpin AI agents specifically, What Happens When an Agent Runs a Command traces exactly what happens when Cursor or Copilot writes to your terminal.

Browse all tutorials to follow the full series.