Unhandled: on_breakpointlocations_request not available in PyDevJsonCommandProcessor causing debugger to freeze and breakpoints to fail

search
<arg_key>search_query</arg_key>
<arg_value>[{"q": "GitHub issue simple description for debugging breakpoint failure", "recency": 365}, {"q": "how to write a short GitHub issue for vscode breakpoint bug", "recency": 365}, {"q": "vscode-python-debugger issue template short", "recency": 365}, {"q": "GitHub issue format for breakpoint not working", "recency": 365}]</arg_value>
</tool_call>

Reproduction Steps

Open a Python file (e.g., main.py).
Press F5 to start debugging (using Python: Current File).
Breakpoints do not pause execution; the debugger runs the code without stopping.

Error Output

Terminal shows:

Unhandled: on_breakpointlocations_request not available in PyDevJsonCommandProcessor.

Environment

VS Code: 1.122.0
Python: 3.12.0
Debugpy extension: 2026.6.0
OS: Windows 10

Expected vs. Actual

Expected: Breakpoints pause execution.
Actual: Breakpoints fail; debugger runs code without stopping.

Additional Notes

Issue started today (after VS Code/debugpy update).

"version": "0.2.0",
"configurations": [
    {
        "name": "Python deb",
        "type": "debugpy",
        "request": "launch",
        "program": "${file}",
        "console": "integratedTerminal"
    }
]

}

This works for me. Not sure why you'd be getting that error.

Can you turn on logging? like this:

"version": "0.2.0",
"configurations": [
    {
        "name": "Python deb",
        "type": "debugpy",
        "request": "launch",
        "program": "${file}",
        "console": "integratedTerminal",
        "logToFile": true
    }
]

That should generate a bunch of log files in the same folder that the debugger extension is installed. From your output that looks like this folder:

C:\Users\Administrator\.vscode\extensions\ms-python.debugpy-2026.6.0-win32-x64

The log files should end up there. Hopefully they'll help diagnose what the issue is.

Debugpy doesn't support the breakpoint locations request so VS code shouldn't be sending it. This is the list of supported capabilities:

https://github.com/microsoft/debugpy/blob/4c70e13d0e3fc8eee5013cd2a41c7a6d752d55d3/src/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_process_net_command_json.py#L186

The log files should show our response to initialize, which theoretically shouldn't include 'supportsBreakpointLocations' in it.

Exact same issue here, cannot debug any python file. Starting and stopping the program is very slow.
Tried to fix it:

Completely removed python extensions from VSCode.
Completely removed python executables (windows app store version), including manual removing PATH entries, remaining files, etc.
Installed python clean using the python manager. https://www.python.org/downloads/
Reinstalled the VSCode python extensions

Result same:
Unhandled:` on_breakpointlocations_request not available in PyDevJsonCommandProcessor.

Downgraded Python VSCode extensions to 2025 versions for both python and the python debugger.
Same issue.

Spend 4 hours trying to get this fixed. Nothing works.
Additionally cleaned python projects .venv, pycache folders etc.
Didnt help.
Debugger broken.

Version

Identifier ms-python.python Version 2026.4.0
Identifier ms-python.debugpy Version 2026.6.0

Relevant logs

898 Client --> Adapter:
{
    "command": "breakpointLocations",
    "arguments": {
        "source": {
            "path": "c:\\test\\hello.py"
        },
        "line": 1,
        "endLine": 4
    },
    "type": "request",
    "seq": 8
}
1005 Client --> Adapter:
{
    "command": "threads",
    "type": "request",
    "seq": 9
}
1703 Client <-- Adapter:
{
    "seq": 17,
    "type": "response",
    "request_seq": 8,
    "success": false,
    "command": "breakpointLocations",
    "message": "Server[1] disconnected unexpectedly"
}
1703 Client <-- Adapter:
{
    "seq": 18,
    "type": "event",
    "event": "thread",
    "body": {
        "reason": "exited",
        "threadId": 1
    }
}
1704 Client <-- Adapter:
{
    "seq": 19,
    "type": "response",
    "request_seq": 9,
    "success": false,
    "command": "threads",
    "message": "Server[pid=28532] disconnected unexpectedly"
}

Additional Notes

Same as OP:
Issue started around a week ago (after VS Code/debugpy update).

Collegue's PC, running exact same VSCode version, Python version and extension version it works fine.

I need the initialize response. That would show if we said we support breakpointLocations or not.

It should look something like this:

D+00000.222: /handling #1 request "initialize" from Client[1]/
             Client[1] <-- {
                 "seq": 4,
                 "type": "response",
                 "request_seq": 1,
                 "success": true,
                 "command": "initialize",
                 "body": {
                     "supportsCompletionsRequest": true,
                     "supportsConditionalBreakpoints": true,
                     "supportsConfigurationDoneRequest": true,
                     "supportsDebuggerProperties": true,
                     "supportsDelayedStackTraceLoading": true,
                     "supportsEvaluateForHovers": true,
                     "supportsExceptionInfoRequest": true,
                     "supportsExceptionOptions": true,
                     "supportsFunctionBreakpoints": true,
                     "supportsHitConditionalBreakpoints": true,
                     "supportsLogPoints": true,
                     "supportsModulesRequest": true,
                     "supportsSetExpression": true,
                     "supportsSetVariable": true,
                     "supportsValueFormattingOptions": true,
                     "supportsTerminateDebuggee": true,
                     "supportsTerminateRequest": true,
                     "supportsGotoTargetsRequest": true,
                     "supportsClipboardContext": true,
                     "exceptionBreakpointFilters": [
                         {
                             "filter": "raised",
                             "label": "Raised Exceptions",
                             "default": false,
                             "description": "Break whenever any exception is raised."
                         },
                         {
                             "filter": "uncaught",
                             "label": "Uncaught Exceptions",
                             "default": true,
                             "description": "Break when the process is exiting due to unhandled exception."
                         },
                         {
                             "filter": "userUnhandled",
                             "label": "User Uncaught Exceptions",
                             "default": false,
                             "description": "Break when exception escapes into library code."
                         }
                     ],
                     "supportsStepInTargetsRequest": true
                 }
             }


15 Client --> Adapter:
{
    "command": "initialize",
    "arguments": {
        "clientID": "vscode",
        "clientName": "Visual Studio Code",
        "adapterID": "debugpy",
        "pathFormat": "path",
        "linesStartAt1": true,
        "columnsStartAt1": true,
        "supportsVariableType": true,
        "supportsVariablePaging": true,
        "supportsRunInTerminalRequest": true,
        "locale": "en",
        "supportsProgressReporting": true,
        "supportsInvalidatedEvent": true,
        "supportsMemoryReferences": true,
        "supportsArgsCanBeInterpretedByShell": true,
        "supportsMemoryEvent": true,
        "supportsStartDebuggingRequest": true,
        "supportsANSIStyling": true
    },
    "type": "request",
    "seq": 1
}
217 Client <-- Adapter:
{
    "seq": 1,
    "type": "event",
    "event": "output",
    "body": {
        "category": "telemetry",
        "output": "ptvsd",
        "data": {
            "packageVersion": "1.8.20"
        }
    }
}

225 Client <-- Adapter:
{
    "seq": 4,
    "type": "response",
    "request_seq": 1,
    "success": true,
    "command": "initialize",
    "body": {
        "supportsCompletionsRequest": true,
        "supportsConditionalBreakpoints": true,
        "supportsConfigurationDoneRequest": true,
        "supportsDebuggerProperties": true,
        "supportsDelayedStackTraceLoading": true,
        "supportsEvaluateForHovers": true,
        "supportsExceptionInfoRequest": true,
        "supportsExceptionOptions": true,
        "supportsFunctionBreakpoints": true,
        "supportsHitConditionalBreakpoints": true,
        "supportsLogPoints": true,
        "supportsModulesRequest": true,
        "supportsSetExpression": true,
        "supportsSetVariable": true,
        "supportsValueFormattingOptions": true,
        "supportsTerminateDebuggee": true,
        "supportsTerminateRequest": true,
        "supportsGotoTargetsRequest": true,
        "supportsClipboardContext": true,
        "exceptionBreakpointFilters": [
            {
                "filter": "raised",
                "label": "Raised Exceptions",
                "default": false,
                "description": "Break whenever any exception is raised."
            },
            {
                "filter": "uncaught",
                "label": "Uncaught Exceptions",
                "default": true,
                "description": "Break when the process is exiting due to unhandled exception."
            },
            {
                "filter": "userUnhandled",
                "label": "User Uncaught Exceptions",
                "default": false,
                "description": "Break when exception escapes into library code."
            }
        ],
        "supportsStepInTargetsRequest": true
    }
}
226 Client --> Adapter:
{
    "command": "launch",
    "arguments": {
        "name": "Python Debugger: Current File",
        "type": "debugpy",
        "request": "launch",
        "program": "C:\\test\\hello.py",
        "console": "integratedTerminal",
        "logToFile": true,
        "__configurationTarget": 6,
        "clientOS": "windows",
        "python": "c:\\Users\\ryan\\AppData\\Local\\Python\\pythoncore-3.14-64\\python.exe",
        "cwd": "c:\\test",
        "envFile": "c:\\test/.env",
        "env": {
            "PYTHONIOENCODING": "UTF-8",
            "PYTHONUNBUFFERED": "1"
        },
        "stopOnEntry": false,
        "showReturnValue": true,
        "internalConsoleOptions": "neverOpen",
        "terminalQuoteCharacter": "\"",
        "debugOptions": [
            "ShowReturnValue",
            "FixFilePathCase"
        ],
        "justMyCode": true,
        "workspaceFolder": "c:\\test",
        "__sessionId": "944ebf60-771a-48c1-96ad-11e5040296bb"
    },
    "type": "request",
    "seq": 2
}

227 Client <-- Adapter:
{
    "seq": 5,
    "type": "event",
    "event": "debugpySockets",
    "body": {
        "sockets": [
            {
                "host": "127.0.0.1",
                "port": 58813,
                "internal": false
            },
            {
                "host": "127.0.0.1",
                "port": 58816,
                "internal": true
            }
        ]
    }
}
227 Client <-- Adapter:
{
    "seq": 6,
    "type": "event",
    "event": "debugpySockets",
    "body": {
        "sockets": [
            {
                "host": "127.0.0.1",
                "port": 58813,
                "internal": false
            },
            {
                "host": "127.0.0.1",
                "port": 58817,
                "internal": true
            },
            {
                "host": "127.0.0.1",
                "port": 58816,
                "internal": true
            }
        ]
    }
}

This morning i repeated the python debugging test on my home pc (instead of my work pc).
Since my home pc is basically only used for gaming, and barely has any development tools installed besides VSCode and Python, I would have expected it to work out of the box. Just like it used to do the past year.
I also didn't run the pc for a few weeks so windows or other software didn't get time to update yet.

I opened VScode, it automatically updated the extensions, and a hello world example also failed with the exact same error.
Why is microsoft pushing updates that are not working properly?

Frankly at this point i dont care what is causing the issue, i need a solution to rollback my system to a working state.
Its been 3 days now that I cannot work properly because Python +VSCode decided to stop working.

As fallback i installed pycharm now, and there the debugging works fine even with debugpy.
So the issue seems to be with VSCode and not debugpy or python itself.

Finally got vscode to work again with python.
A simple downgrade or reinstall of software versions (vscode, vscode extensions or even python itself) didnt work.
Installing pre-release extensions didnt work.

I had to do a hard reset of the vscode configuration by renaming the c:\users\foo\.vscode folder to something else.
You will loose all your configurations and extensions, but afterwards python works again.
(simply disabling all extensions except python related ones also didnt work...)

So the issue seems related to upgrading from an earlier (specific?) vscode configuration to the latest versions.

Also tested with a docker based debug solution, and that kept working but was not usable for me due the the windows GUI requirement of my project.

OKE FINAL CONCLUSION:
If i install the VSCode extension "Arm Keil Studio Pack (MDK v6)" (which is C/C++ language!) then my python environment breaks!
If i disable or uninstall the MDK v6 extension then Python debugger works again! What the hell.

Why does one extension influence another? Even from a completely different language?

Perhaps original OP can confirm he is also using MDK v6?

I would hazard a guess that the MDK v6 extension is somehow participating in Python debugging when it shouldn't.

AnatechRyan

Hello, I was having the same problem and I can confirm that uninstalling the ARM keil studio pack (MDK 6.0) fixes it (thank you AnatechRyan ). I think we should open an issue on that extension because it's kind of infuriating that it can break another extension just like that.

Giuseppe La Capra (@Giuseppe-La-Capra)

That's a good idea Giuseppe La Capra (@Giuseppe-La-Capra) , however I wont be spending more time on this matter. I need to work and get things done.

That having said, this is a mayor security issue in VSCode, that one completely unrelated extension can influence the outcome of another. Before we know it some rogue extension, that's supposedly not even active, is influencing my build environment adding trojans and what not.
In general I completely dislike the way VSCode handles extensions, by enabling them by default and apparently allowing them to influence each other. Imho extensions should be disabled by default and should manually be enabled per workspace! Preferably each workspace runs in its own virtual environment (docker like, but running native).

But I'm drifting off, I leave it to the experts to do whatever they think is proper.

Closing this for now as it's not a vscode-python-debugger problem. I'd hazard a guess it's not ARM keil studio pack's problem either. VS code is getting confused about which debugger supports breakpoint locations is my guess.

Navigation Menu

Repository navigation

Unhandled: on_breakpointlocations_request not available in PyDevJsonCommandProcessor causing debugger to freeze and breakpoints to fail #1047

Reproduction Steps

Error Output

Environment

Expected vs. Actual

Additional Notes

Version

Relevant logs

Additional Notes

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Unhandled: on_breakpointlocations_request not available in PyDevJsonCommandProcessor causing debugger to freeze and breakpoints to fail #1047

Description

Reproduction Steps

Error Output

Environment

Expected vs. Actual

Additional Notes

Activity

2312469331 commented on May 29, 2026

rchiodo commented on May 29, 2026

rchiodo commented on May 29, 2026

rchiodo commented on May 29, 2026

AnatechRyan commented on Jun 3, 2026

Version

Relevant logs

Additional Notes

rchiodo commented on Jun 3, 2026

AnatechRyan commented on Jun 4, 2026

AnatechRyan commented on Jun 4, 2026

AnatechRyan commented on Jun 4, 2026

AnatechRyan commented on Jun 4, 2026

rchiodo commented on Jun 4, 2026

Giuseppe-La-Capra commented on Jun 7, 2026

AnatechRyan commented on Jun 8, 2026

rchiodo commented on Jun 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions