CursorPyright's ability to provide useful assistance is broken

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

CursorPyright can’t seem to do anything useful any more, unless the thing you want it to do is in a file that’s either already open, or already imported by a file that’s already open.

For instance, attempting to import a bog-standard django function, render_to_string(), using Quick Fix doesn’t work, because CursorPyright doesn’t seem to know that the function exists. I have the same problem with code that’s in my workspace, unless I currently have the file it’s defined in open in another tab.

Steps to Reproduce

In a Django project, attempt to quickfix import literally any Django function that isn’t already imported somewhere in your open tabs.

Expected Behavior

CursorPyright should know about all the functions in every dependency that’s in my Python environment, and ESPECIALLY all the functions in my own freaking code.

Screenshots / Screen Recordings

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.7.28 (Universal)
VSCode Version: 1.99.3
Commit: adb0f9e3e4f184bba7f3fa6dbfd72ad0ebb8cfd0
Date: 2025-10-01T02:45:21.769Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

Additional Information

Here’s the output from"basedpyright":

[Info - 12:18:47 PM] basedpyright language server 1.31.3 starting
[Info - 12:18:47 PM] Server root directory: file:///Users/coredumperror/.cursor/extensions/anysphere.cursorpyright-1.0.9/dist
[Info - 12:18:47 PM] Starting service instance “palomar_2025”
Received pythonPath from Python extension: /Users/coredumperror/dev/palomar_2025/.venv/bin/python
[Info - 12:18:47 PM] Loading pyproject.toml file at /Users/coredumperror/dev/palomar_2025/pyproject.toml
[Info - 12:18:47 PM] Setting pythonPath for service “palomar_2025”: “/Users/coredumperror/dev/palomar_2025/.venv/bin/python”
[Info - 12:18:47 PM] No include entries specified; assuming /Users/coredumperror/dev/palomar_2025
[Info - 12:18:47 PM] Auto-excluding **/node_modules
[Info - 12:18:47 PM] Auto-excluding **/pycache
[Info - 12:18:47 PM] Auto-excluding */.
[Info - 12:18:47 PM] Assuming Python version 3.13.7.final.0
[Info - 12:18:48 PM] Found 142 source files
[Info - 12:18:48 PM] BG: Background analysis(1) root directory: file:///Users/coredumperror/.cursor/extensions/anysphere.cursorpyright-1.0.9/dist
[Info - 12:18:48 PM] BG: Background analysis(1) started

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hi @coredumperror, could you try setting cursorpyright.analysis.autoImportCompletions to true? In addition, could you verify that workspace files are not being auto-excluded with the cursorpyright.analysis.exclude setting?

I tried enabling cursorpyright.analysis.autoImportCompletions, but it didn’t make Quick Fix do any better about providing import sources. I do not have cursorpyright.analysis.exclude in my settings.json.

Also, I just noticed that the formatting for my logs got messed up, and showed the wrong things for the “Auto-excluding” lines. Here’s what the logs actually look like:

[Info  - 1:05:03 PM] basedpyright language server 1.31.3 starting
[Info  - 1:05:03 PM] Server root directory: file:///Users/coredumperror/.cursor/extensions/anysphere.cursorpyright-1.0.9/dist
[Info  - 1:05:03 PM] Starting service instance "palomar_2025"
Received pythonPath from Python extension: /Users/coredumperror/dev/palomar_2025/.venv/bin/python
[Info  - 1:05:03 PM] Loading pyproject.toml file at /Users/coredumperror/dev/palomar_2025/pyproject.toml
[Info  - 1:05:03 PM] Setting pythonPath for service "palomar_2025": "/Users/coredumperror/dev/palomar_2025/.venv/bin/python"
[Info  - 1:05:03 PM] No include entries specified; assuming /Users/coredumperror/dev/palomar_2025
[Info  - 1:05:03 PM] Auto-excluding **/node_modules
[Info  - 1:05:03 PM] Auto-excluding **/__pycache__
[Info  - 1:05:03 PM] Auto-excluding **/.*
[Info  - 1:05:03 PM] Assuming Python version 3.13.7.final.0
[Info  - 1:05:04 PM] Found 143 source files

I tried setting "cursorpyright.analysis.exclude": ["**/__pycache__"], in order to make it get rid of the default **/.* value, which proved interesting…

I got the following logs:

Received pythonPath from Python extension: /Users/coredumperror/dev/palomar_2025/.venv/bin/python
[Info  - 1:14:47 PM] Loading pyproject.toml file at /Users/coredumperror/dev/palomar_2025/pyproject.toml
[Info  - 1:14:47 PM] Setting pythonPath for service "palomar_2025": "/Users/coredumperror/dev/palomar_2025/.venv/bin/python"
[Info  - 1:14:47 PM] No include entries specified; assuming /Users/coredumperror/dev/palomar_2025
[Info  - 1:14:47 PM] Assuming Python version 3.13.7.final.0
[Info  - 1:14:48 PM] Found 8842 source files

And it took several minutes to go through all those source files… yet it somehow still didn’t fix the problem with QuickFix imports. The only import source that became available for render_to_string() was a file that imports that function… which should never be given as an import source in the first place.

Oddly enough, doing a quick fix the first time gave me just that sole, incorrect option, but when I went back and double-checked, I got a new list of import sources that did actually include the right django source:

I had a similar experience when I tried to Quick Fix settings, with only the second attempt giving me this:

(The first attempt gave me just the allauth options)

Taking out the `cursorpyright.analysis.exclude`setting and restarting cursor to give a completely fresh re-parse actually gives me the same experience. The first Quick Fix gives only the incorrect allauth option(s), but the second one adds the proper django source. How absolutely bizarre.

OK so I think I might know what’s going on here. It may be related to this issue with basedpyright: Language server does't offer autocomplete for functions in modules or packages that haven't been opened or loaded · Issue #545 · DetachHead/basedpyright · GitHub

The strange “QuickFix doesn’t offer the right source until I make a second request” behavior might be because the first request re-parses the file offered in the “incorrect” allauth option, which causes basedpyright to then treat that file as “open in the IDE”, which causes the bug I linked to stop hiding the django source.

This topic was automatically closed 22 days after the last reply. New replies are no longer allowed.