Meta’s Pyrefly VS Code extension silently writes disableLanguageServices = true to global settings for basedpyright, windsurfpyright, and cursorpyright on activation, with no cleanup on uninstall.
Key Takeaways
Three functions in lsp/src/extension-interop.ts hardcode competitor extension IDs and call config.update(..., vscode.ConfigurationTarget.Global) unconditionally on activation.
ConfigurationTarget.Global writes to the user’s global settings.json, breaking those extensions across every workspace on the machine.
No deactivate() cleanup exists; uninstalling Pyrefly leaves the disabled flags permanently in settings.json with no user-visible cause.
Reproduction confirmed on both VSCodium and stock VS Code 1.118.1 using a clean isolated profile.
package.json also declares a hard dependency on ms-python.python, silently pulling in ms-python.debugpy and ms-python.vscode-python-envs – a problem for VSCodium users who avoid Microsoft extensions.
Hacker News Comment Review
Split between “malicious competitor sabotage” and “clumsy UX hack”: several commenters argue this is a lazy workaround for VS Code’s lack of multi-LSP coordination, not an intentional attack.
The practical fix most commenters converged on is gating the setting writes behind an explicit user prompt on install – the silent global mutation is the real complaint, not the intent.
Notable Comments
@PufPufPuf: frames it as a convenience feature, arguing users who install Pyrefly likely want it active – calls the outrage a “nothingburger”.
@pityJuke: asks pointedly whether a simple install notification would have been sufficient to avoid the entire issue.
