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.
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...
This is typical in the Python space. Windows is also broken after installing Conda.
Given that now one has to pray that one does not get Shai Hulud when using PyPI, the best thing Meta could do is switch Instagram to PHP/Hack and PyTorch back to Lua (or Haskell or whatever).
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.
Yeah, I think the OP is overreacting. I am pretty sure it even says it in the initial installation instructions and gives a clear reason why it interferes with other language servers. In the "Features" section of the VsCodium extensions "Adds language features from Pyrefly's analysis like go-to definition, hover, etc. (full list here) and disables Pylance completely (VSCode's built-in Python extension)". I suspect there is an element of LLM-sycophancy-driven activism here.
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()`.
A, B, C — D.
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...
Given that now one has to pray that one does not get Shai Hulud when using PyPI, the best thing Meta could do is switch Instagram to PHP/Hack and PyTorch back to Lua (or Haskell or whatever).
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.
I spent some time figuring out how to disable the default language server after installing Ty.
I'm not outraged (the intentions were probably good), but I also strongly disagree. Don't touch my config without my consent.