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

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

▶ Watch on YouTube & subscribe to The Stack Underflow

Every AI code editor that’s made headlines in the last two years — Cursor, Windsurf, GitHub Copilot — feels brand new. Different branding, different pricing, different marketing. But pop the hood and you’ll find the same skeleton underneath every single one of them: VS Code.

That’s not a coincidence or a shortcut. It’s a deliberate architectural choice, and understanding why these editors converge on VS Code tells you a lot about how the AI layer actually works — and what it can and can’t do.

The one-sentence version: Cursor and Windsurf are forks of VS Code; Copilot is an extension on top of it — 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 in the same way, but they all use it:

A fork means the team took Microsoft’s open-source VS Code repository and created their own copy. They can change anything they want — UI, keybindings, which models get called, how the context window is populated. A extension means the AI features live in a plugin that loads into the standard editor without modifying VS Code itself.

Both approaches give you VS Code’s editing primitives for free: syntax highlighting, go-to-definition, the integrated terminal, the file tree, the debug adapter protocol. The AI features are layered on top. They changed the skin. They kept the skeleton.

VS Code Is Not One Program

Here’s the part that surprises most developers: VS Code isn’t a single process. It’s an orchestration of several separate processes that coordinate to produce what looks like one editor.

┌─────────────────────────────────────┐
│           VS Code Window            │
│  (Electron renderer — draws pixels) │
└────────────────┬────────────────────┘
                 │ IPC / RPC
       ┌─────────┼──────────┐
       ▼         ▼          ▼
 Extension   Language    Terminal
   Host      Server(s)   Process
 (Node.js)  (LSP, one   (pty/shell)
             per lang)

Let’s break down each process:

1. The Editor UI (Electron renderer) This is the Chrome window you actually see. It renders the text, handles mouse clicks, and draws the UI. On its own, it knows almost nothing about your code’s meaning.

2. The Extension Host Extensions don’t run inside the UI process — they run in a separate Node.js process. This is intentional sandboxing: a buggy extension can’t crash your editor window. When GitHub Copilot activates, it runs here. When Cursor’s AI agent takes an action, it’s orchestrated through this layer.

3. Language Servers (LSP) Autocomplete, hover docs, go-to-definition, find-all-references — none of these are built into VS Code itself. They come from language servers: small programs that speak the Language Server Protocol. Pylsp powers Python completions. TypeScript has its own tsserver. Each language can have its own server, running as its own process.

4. The Terminal The integrated terminal is a real shell process (bash, zsh, PowerShell — your choice), connected via a pseudoterminal (pty). When an AI agent runs npm install or executes tests, it’s talking to this process.

Four processes, coordinated by the editor window. When an AI editor does something clever, ask which process it’s hooking into — because that tells you exactly what it can and can’t access.

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:

• Read and edit files → Extension Host has full filesystem access via Node.js APIs
• Understand code semantics → Query the Language Server over LSP
• Run commands → Write to the Terminal process’s stdin
• Show UI → Post messages to the renderer via VS Code’s extension API

An AI editor doesn’t need to rewrite any of these systems. It hooks into what VS Code already provides. That’s why forking VS Code is so appealing: in a weekend, a team can have a working AI editor with language-aware completions, a file tree, debugging support, and a terminal — because VS Code already built all of that.

Common Misconceptions

• “Cursor has its own editor engine.” It doesn’t. Cursor is VS Code with AI features bolted on. If you open a file in Cursor, Monaco (VS Code’s editor component) is rendering it, just like in stock VS Code.

• “Copilot is tightly integrated into VS Code’s core.” Copilot is a regular VS Code extension. It uses the same extension APIs available to any third-party extension author. The tight feel comes from good UX, not special access.

• “The AI understands your code natively.” The AI model gets text — specifically, the text of your files, snippets of context, and whatever the extension author decides to pass in the prompt. It doesn’t have a live connection to the language server’s semantic model unless the extension explicitly queries it.

• “Forked editors will always lag behind VS Code updates.” True in practice, but the lag is a product decision, not an architectural necessity. Teams can and do pull upstream VS Code changes regularly. The risk is merge conflicts on their custom patches.

Frequently Asked Questions

Why do Cursor and Windsurf fork instead of just writing extensions? Extensions are sandboxed on purpose — they can’t modify VS Code’s core UI, change the editor’s command palette UX, or intercept all keypresses. A fork removes those restrictions. If you want to redesign the entire sidebar or add a persistent AI panel that feels native, a fork gives you that freedom.

If they’re all VS Code, why do they feel different? The AI models they use, the prompts they construct, the context they gather, and the UX flows they design are all different. A great forked editor is differentiated by what it does above the VS Code layer — not by replacing it.

Does this mean my VS Code extensions work in Cursor/Windsurf? Mostly yes. Because forks maintain VS Code’s extension API compatibility, most extensions from the VS Code Marketplace work in Cursor and Windsurf — sometimes with a one-click install. A few extensions that depend on proprietary Microsoft services (like some Live Share features) may not work.

What’s the Language Server Protocol and why should I care? LSP is a JSON-RPC protocol that separates “editor” from “language smarts.” Before LSP, every editor had to implement language features from scratch. After LSP, a language team writes one server, and every LSP-compatible editor gets autocomplete, diagnostics, and go-to-definition for free. VS Code pioneered LSP, which is another reason building on VS Code means inheriting a massive ecosystem of language support.

Where This Fits in the Series

This is the opening episode of “How Claude Actually Works” — a course that cracks open AI code editors from the UI down to the model weights. In later episodes we’ll go deeper into how context is gathered and sent to the model, how agents decide what actions to take, and where VS Code’s architecture both helps and limits what AI can do.

Browse all tutorials to see the full series.