Meta's Pyrefly sabotages competing Python extensions without telling you

Never attribute to malice what can be explained by vibe-coding

Pyrefly is Meta's new Python type checker and VS Code extension, released earlier this year. While auditing the VSIX before installing it, I found that on activation it silently writes `disableLanguageServices = true` to the user's global settings for three named extensions: basedpyright, windsurfpyright, and cursorpyright.

The write uses `ConfigurationTarget.Global`, so it affects all workspaces. There is no `deactivate()` cleanup, so the setting persists after Pyrefly is uninstalled.

This was verified by live reproduction: installed Pyrefly alongside basedpyright, opened a Python file, and observed the key appear in `settings.json`. Uninstalled Pyrefly — key remained, basedpyright still broken.

The code is in plain TypeScript in the public repo (`lsp/src/extension-interop.ts`), added December 2025. This isn't obfuscated or hidden — it just hasn't been noticed.

Bug report with full details, source references, and reproduction steps: https://github.com/facebook/pyrefly/issues/3292

The fix is straightforward: ask the user before touching settings they didn't set, and restore them in `deactivate()`.

Noticed this myself as a VSCode-derivative user.

But I think this is just because having multiple Python extensions enabled generally breaks the UX...

Since VSCode doesn't really have a nice way for multiple language extensions to cooperate, this looks like just a quick hack to make the initial UX better, unlikely to be "malicious".

EDIT: Silent downvotes, really? Prejudice is strong here...

Fixed title: Pyrefly automatically disables conflicting extensions on installation.

That's a convenient thing to do: if user installs Pyrefly, they probably want to use Pyrefly. Everyone likes a good outrage against Meta, but this is a nothingburger.

Once again; if it has a Meta label, it most likely has added "features" you may not expect ... or want.