Python Code Not Running – Broken debugpy Integration (v2025.6.0)

[Thiago_Maffei]

Describe the Bug

System Details

macOS: Apple Silicon M3 Pro

Cursor version: Latest (as of [insert today’s date])

Python version: 3.12.8 (in virtual environment)

Python extension: ms-python.debugpy-2025.6.0-darwin-arm64

Launch.json:
{
“version”: “0.2.0”,
“configurations”: [
{
“name”: “Python: Run file”,
“type”: “debugpy”,
“request”: “launch”,
“program”: “${file}”,
“console”: “integratedTerminal”
}
]
}

What Happens

The following command is triggered by Cursor:
/usr/bin/env /Users/thiagodardis/Documents/test/venv/bin/python
/Users/thiagodardis/.cursor/extensions/ms-python.debugpy-2025.6.0-darwin-arm64/bundled/libs/debugpy/launcher
53056 – /Users/thiagodardis/Documents/test/test.py

But:

• Nothing happens
• No terminal output appears
• No errors are thrown
• test.py is not executed at all

What I Tried (All Failed)

• Full deletion of ~/.cursor and ~/Library/Application Support/Cursor
• Reinstalling Cursor from scratch
• Reinstalling the Python extension via the built-in prompt
• Confirming the interpreter is selected correctly
• Creating a minimal project with only test.py
• Using “console”: “externalTerminal” or “integratedTerminal”
• Downgrading Python in the venv
• Running debugpy manually (works outside Cursor)

Additional Findings

• The issue seems tied to the ms-python.debugpy-2025.6.0 extension downloaded by Cursor

• Manually running
  python -m debugpy --listen 5678 --wait-for-client test.py
  works fine from terminal, but not from Cursor.

• Manually attaching Cursor to port 5678 also works, confirming the issue is with Cursor’s internal launcher usage, not with debugpy itself.

Please investigate the behavior of the launcher script bundled inside:
~/.cursor/extensions/ms-python.debugpy-2025.6.0-darwin-arm64/bundled/libs/debugpy/launcher

It appears to be broken or misconfigured, resulting in complete failure to run Python scripts via Cursor.

Temporary Workaround
Currently using VS Code instead — all functionality works there with the same launch.json and venv.

Would love to return to Cursor once this is resolved.

Steps to Reproduce

1. Create a simple file called test.py:
   print(“hello world”)

2. Create and activate a virtual environment:
   python3 -m venv venv
   source venv/bin/activate

3. Open the project in Cursor and select the venv interpreter.

4. Click Run.

Expected Behavior

Clicking “Run” or pressing F5 should:

• Run test.py
• Show output in terminal
• Allow breakpoint debugging

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.2.4 (Universal)
VSCode Version: 1.99.3
Commit: a8e95743c5268be73767c46944a71f4465d05c90
Date: 2025-07-10T16:55:16.443Z
Electron: 34.5.1
Chromium: 132.0.6834.210
Node.js: 20.19.0
V8: 13.2.152.41-electron.0
OS: Darwin arm64 23.3.0

Does this stop you from using Cursor

Yes - Cursor is unusable

[ravirahman]

Hi @Thiago_Maffei, curious if you tried earlier versions of the debugpy extension?

[Thiago_Maffei]

Hi @ravirahman,

I tested with debugpy==1.6.7, and manually copied it into Cursor’s expected path.
However, the problem persists.

When I run the same command Cursor triggers, I get:

ConnectionRefusedError: [Errno 61] Connection refused

It seems the launcher is being called before the adapter is listening on the port, which causes a silent crash.

Can you confirm if there’s a bug in the debugger launch sequence (adapter not ready before launcher runs)?
And is there a way to fix or work around this internally in Cursor?

Thanks,
Thiago

[Thiago_Maffei]

Hi @ravirahman,

I downgraded the ms-python.debugpy extension to version 2024.8.0, but the problem persists.

When I run the same command triggered by Cursor manually:

/path/to/python /path/to/debugpy/launcher 60487 -- test.py

I get a ConnectionRefusedError, which confirms that the launcher is being invoked before the adapter is listening on the target port.

So, this isn’t related to the debugpy version. The issue seems to be in Cursor’s debugger startup sequence.

Let me know if there’s a workaround or patch planned.

Thanks,
Thiago

[Thiago_Maffei]

Hi @ravirahman,

I just did a full audit of my environment:

• No PYENV or PYTHONPATH variables set globally
• Clean PATH, starting with the correct venv/bin
• No residual pyenv in .zshrc, .zprofile, or launchctl
• VIRTUAL_ENV is active and correct

Given this clean environment, the issue clearly isn’t caused by any global configuration or shell pollution.

The problem is still that the launcher is being called before the debugger adapter is listening on the port, which causes a ConnectionRefusedError.

Let me know if there’s any patch or workaround being considered.

Thanks,
Thiago