Microsoft Cracks Down On VS Code Forks

Microsoft’s tightening of licensing and distribution rules for Visual Studio Code extensions is breaking key language tooling in VS Code forks—most visibly C++ (and also .NET and other extensions) inside editors like Cursor and Windsurf—leaving developers suddenly unable to use extensions they previously relied on. The disruption matters because VS Code forks exist largely to inherit the VS Code extension ecosystem; when Microsoft restricts where certain extensions can run, those forks lose one of their core advantages overnight.

The immediate trigger is a new error message appearing in April 2025: certain Microsoft language extensions “may only be used” inside a defined set of Microsoft products (including Visual Studio, Visual Studio for Mac, Visual Studio Code, and Azure DevOps). The restriction is especially painful because the affected extensions are not open-source in the usual sense. Even when some parts appear under permissive licenses, key runtime components ship under more restrictive proprietary terms, creating a legal and technical barrier for forks that embed or redistribute the extension binaries.

At the same time, Microsoft has been reducing the ability to obtain extension packages directly from outside the official Microsoft Store. A previously available “download extension” button was removed from the VS Code marketplace browser flow in February 2025, and the change appears to have been motivated by internal version-handling issues—particularly around pre-release versus stable versions. That matters because many fork ecosystems depended on importing or manually installing extensions from the official marketplace; once the download path is removed, the workaround becomes harder.

The broader context is a long-running chain of “platform inheritance.” The transcript traces how modern extensible editors evolved from Sublime Text’s community marketplace model, through Atom’s Electron-based, JavaScript-friendly approach, into VS Code—positioned as Microsoft’s “Visual Studio light” built to capture the extensibility momentum Atom helped popularize. Cursor, in turn, is described as a fork-like product that rides on VS Code’s extension infrastructure: it moved from CodeMirror-based foundations to VS Code-based foundations (via VS Codium), and it previously relied on Open VSX for extension distribution before shifting toward a Cursor marketplace.

A key claim is that Cursor’s marketplace likely functioned as a wrapper around Microsoft’s official extension ecosystem, which may have sat in a gray area under Microsoft’s terms until stricter language was published in January 2025. After that, Microsoft’s later enforcement—removing download access and restricting extension usage—hits forks more directly. The transcript argues that this enforcement looks coordinated at the surface level, but likely came from multiple teams making separate decisions: the download-button change, the agent/MCP push in VS Code, and the extension restrictions may not share a single master plan.

Still, the practical outcome is clear: VS Code forks can no longer assume Microsoft language extensions will work the same way everywhere. The likely path forward, according to the transcript, is a mix of importing what still works, pushing more developers toward Open VSX publishing, and building open alternatives for proprietary pieces—especially in areas like C++ runtime components and .NET experiences. Developers are left balancing frustration with Microsoft’s enforcement against the reality that fork ecosystems may need to reduce dependence on Microsoft-controlled extension distribution and licensing.