Microsoft Cracks Down On VS Code Forks

This video dives into the recent drama where Microsoft extensions, like the C++ one, suddenly stopped working in VS Code forks such as Cursor. While it looks like Microsoft is directly attacking competitors, the situation is more complex, involving licensing, marketplace terms, and potentially uncoordinated decisions across different Microsoft teams.

Here's a breakdown of the key points and discussion:

The Problem: Broken Extensions in Forks

• Users of VS Code forks like Cursor and Windsurf started seeing errors preventing them from using certain Microsoft-published extensions, notably the C++ and .NET extensions.
• This broke workflows for developers relying on these extensions within their preferred editors, causing frustration.
• Cursor managed to get the C++ extension working again (likely via older versions or workarounds) and has a plan for the future.

Historical Context: The Editor Revolution

• Sublime Text: Kicked off the trend of minimal, fast, extensible editors with a community marketplace, though it wasn't open source and extensibility was added later.
• Atom (by GitHub): Built specifically around community extensibility using web technologies (JavaScript) and introduced Electron (originally built for Atom) to enable cross-platform compatibility. It was fully free and open source but often criticized for being slow.
• Visual Studio (Classic): Acknowledged as one of the best, most comprehensive IDEs ever, especially for its time (.NET development). It pioneered integrated debugging and testing UIs.
• VS Code (by Microsoft): Microsoft saw the success of Atom/Sublime and the desire for a lighter, extensible editor, especially for web development. They leveraged the experienced Visual Studio team and the Electron platform pioneered by Atom.
  • Positioned as "Visual Studio for web devs," it was free, open source, and built around community extensibility.
  • Its performance was better than Atom's, though extensions could slow it down.
  • Crucially, its tight integration with TypeScript, another Microsoft project that exploded in popularity, gave it a massive advantage. VS Code became the de facto editor for TypeScript.
  • VS Code essentially executed Atom's playbook much better, leading to Atom's eventual deprecation after Microsoft acquired GitHub.

The Rise of Cursor (and other forks)

• Cursor initially used CodeMirror but later switched to a VS Code base (specifically VS Codium, an open-source build).
• Just as VS Code built on Atom/Electron's foundation, Cursor builds on VS Code's foundation, adding significant AI features.
• The presenter (an investor in both Cursor and Microsoft) finds Cursor essential now, as it allows for faster iteration and exploration of different coding approaches, improving code quality.

Microsoft's Actions & Marketplace Shenanigans

• Marketplace Shift: Cursor initially used the OpenVSX marketplace (an open alternative). Later, around September 2023, it seems they switched to using a wrapper around the official Microsoft VS Code Marketplace. This was likely against Microsoft's Terms of Service (TOS), although the older TOS wasn't super explicit about banning wrappers, only scraping.
• TOS Update (Jan 2024/2025 in transcript): Microsoft published much stricter TOS, explicitly forbidding the use of Microsoft/GitHub extensions in products other than specified Microsoft services (like VS Code itself, Azure DevOps, etc.).
• Return to OpenVSX (Nov 2024 in transcript): Around this time (likely anticipating or reacting to the TOS change), Cursor seems to have switched back to OpenVSX. This meant official extensions only on the MS marketplace weren't searchable in Cursor.
• The Manual Install Workaround: Cursor published a guide on manually downloading the .vsix extension file from the Microsoft marketplace website and dragging it into Cursor.
• Download Button Removed (Feb 2024/2025 in transcript): Microsoft removed the manual download button from the marketplace website. A Microsoft employee stated this was partly due to technical issues with handling pre-release vs. stable extension versions, not necessarily malice.
• Extension Restrictions (April 2024/2025 in transcript): Specific Microsoft extensions (C++, .NET, Python debugger components) started actively checking where they were running and throwing errors if not in an official Microsoft product.
  • This is technically enforcing existing license terms. Many core MS extensions (like C++/.NET runtimes) were never fully open source (MIT license might apply to the extension code, but not the compiled binaries/runtimes they bundle, which have proprietary licenses).
  • This particularly hurts paying Visual Studio subscribers who used the .NET extension in Cursor.
• Agent Mode Launched (April 2024/2025 in transcript): Around the same time, Microsoft launched its own AI agent features in VS Code, competing directly with Cursor's core value proposition.

The "It's Not a Conspiracy" Theory

• The presenter doesn't believe these actions were a single, coordinated plan by Microsoft leadership to crush forks like Cursor.
• Instead, it's likely separate decisions by different teams:
  • Marketplace Team: Removed the download button for technical reasons (pre-release versions).
  • Language Extension Teams (e.g., .NET, C++): Got tired of bug reports from outdated or slightly incompatible forks (Cursor/VS Codium might lag behind official VS Code updates). Enforcing the license terms was the easiest way to stop these bug reports (similar to how the presenter blocks Brave browser on their own service due to compatibility issues causing support overhead).
  • VS Code AI Team: Launched Agent Mode simply because they were excited about the tech and wanted to compete, not necessarily as part of a plot against forks.
• VS Code's original goal was developer goodwill and improving Microsoft's image, not direct profit. Making aggressive moves against forks could backfire and damage that goodwill.

Future Outlook & Takeaways

• Forks like Cursor will likely rely more on users importing extensions from existing VS Code installs and encourage developers to publish on OpenVSX.
• We might see better open-source alternatives emerge for things like the C++ language server components.
• This move particularly hurts .NET developers who preferred using forks like Cursor, as a good .NET experience there seems unlikely now.
• Microsoft is unlikely to sue these forks due to the potential negative PR fallout (remembering the Netscape lawsuit era).
• The situation highlights the tension between open platforms and proprietary extensions/services built on top of them.