Meta’s recently released Pyrefly VS Code extension introduces a concerning practice: the silent disabling of competing extensions. This behavior, discovered in the extension’s code, directly impacts developers using VS Code and raises questions about fair competition within the editor’s ecosystem.
What Happened
Pyrefly, upon activation, modifies the user's global VS Code settings by writing disableLanguageServices = true to the configuration of three specific extensions: detachhead.basedpyright, codeium.windsurfpyright, and anysphere.cursorpyright. The code responsible for this behavior is found in lsp/src/extension-interop.ts and is triggered unconditionally upon extension activation (commits 69985d1d, c0ab0d76, 72458900, 2fb5205a). Critically, this modification occurs without any user notification or prompt. Furthermore, this setting is not reverted when Pyrefly is deactivated or uninstalled, effectively leaving the targeted extensions broken until the user manually corrects the settings.json file.
Independent testing on both VSCodium and standard VS Code 1.118.1 confirmed this behavior. Before installation, the targeted extensions functioned correctly. After installing Pyrefly and opening a Python file, the relevant disableLanguageServices key appeared in the global settings, breaking the targeted extensions. Uninstalling Pyrefly did not remove this key, leaving the extensions permanently disabled.
Why It Matters
This practice is problematic for several reasons. First, silently modifying global settings is a poor user experience and can lead to unexpected behavior. Users expect extensions to operate within their own scope and not make sweeping changes to their editor configuration without consent. Second, the lack of cleanup on uninstall is particularly damaging, as it leaves users troubleshooting a broken environment without any clear indication of the cause. Finally, the targeting of specific extensions by publisher ID, rather than a generic conflict resolution mechanism, suggests an anti-competitive intent. This isn't simply disabling conflicting language servers; it’s actively undermining specific competitors.
For developers, this means a potentially frustrating debugging experience if they happen to use one of the targeted extensions. For enterprises standardizing on VS Code, this introduces a risk of unexpected behavior and compatibility issues. The practice also raises broader concerns about the potential for extensions to silently interfere with each other, and the need for more robust extension sandboxing and permission controls within VS Code.
What To Watch
It remains to be seen how Meta will respond to this discovery. Will they issue a fix to restore the original settings on uninstall? Will they revise their approach to avoid silently modifying global settings? The VS Code team may also need to evaluate whether current extension permissions are sufficient to prevent similar behavior in the future. Developers using VS Code should be aware of this issue and manually check their settings.json file if they encounter unexpected behavior with these or other extensions. It's also important to monitor the GitHub issue (https://github.com/facebook/pyrefly/issues/3292 (opens in a new tab)) for updates and further discussion.