Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Cursor reports a configuration registration conflict when using Python on a remote SSH workspace:
"Cannot register 'python.venvPath'. This property is already registered."
After investigating the server-side extensions, I discovered that Cursor ships its own modified Python
extension (anysphere.cursorpyright) because Cursor cannot download the official Pyright component from
the Microsoft Python extension (ms-python.python) in some remote environments.
CursorPyright bundles Pyright internally, but at the same time still expects the official
ms-python.python extension to be installed for full Python functionality. As a result, both extensions
end up registering the same configuration key "python.venvPath" in their respective package.json schemas.
This double-registration causes the conflict during startup.
Steps to Reproduce
-
Connect to a remote server using Cursor’s SSH workspace.
-
Ensure Python support is active (Cursor auto-installs its modified Python extension).
-
Also install or let Cursor install
ms-python.python. -
Open any Python file.
-
Cursor shows the warning:
Cannot register 'python.venvPath'. This property is already registered. -
Inspect extension schemas on the remote server:
~/.cursor-server/extensions/anysphere.cursorpyright-/package.json
~/.cursor-server/extensions/ms-python.python-/package.json -
Both extensions define
"python.venvPath"→ causes the conflict.
Expected Behavior
Only the official Microsoft Python extension should define “python.venvPath”.
CursorPyright should not duplicate configuration schema fields owned by ms-python.python, especially if
CursorPyright is positioned as a fallback when official Pyright cannot be downloaded.
Ideally, CursorPyright should either:
- not register Python settings at all, or
- fully replace ms-python.python without requiring both to be active simultaneously.
Operating System
Linux
Current Cursor Version (Menu → About Cursor → Copy)
cursor version: 2.1.50
vscode version: 1.105.1
commit: 56f0a83df8e9eb48585fcc4858a9440db4cc7770
Additional Information
This design causes unintended schema collisions.
The issue does not completely break Python support, but it hints at overlapping ownership of Python
functionality between CursorPyright and Microsoft’s Python extension. A clearer separation of roles or
settings ownership would prevent this conflict.
Does this stop you from using Cursor
No - Cursor works, but with this issue