If you're having trouble with debugpy, check below for information which may help. If something isn't covered here, please file an issue with the information given in Filing an issue.
There are a few known issues in the current version of the debugger:
If you receive an error saying breakpoint not set, then look at your path mappings in launch.json. See Meta-Issue #2976 for more details.
If you want to debug library files, you have to disable justMyCode in launch.json. Previously this setting was debugStdLib. For example:
{
"name": "Terminal",
"type": "python",
"request": "launch",
"pythonPath": "${config:python.pythonPath}",
"program": "${file}",
"console": "integratedTerminal",
"justMyCode": false
},By default, the debugger treats SystemExit with a non-zero exit code as an uncaught exception and breaks on it. If you use sys.exit() intentionally (e.g. in CLI tools, test runners like pytest, or frameworks like Django/Flask), this can be unwanted.
You can control exactly which SystemExit codes the debugger breaks on using the breakOnSystemExit setting in launch.json. It accepts an array of exit codes and/or ranges:
// Never break on any SystemExit:
{
"breakOnSystemExit": []
}
// Only break on specific exit codes:
{
"breakOnSystemExit": [1, 2]
}
// Break on exit codes using ranges (inclusive):
{
"breakOnSystemExit": [{"from": 1, "to": 255}]
}
// Mix specific codes and ranges:
{
"breakOnSystemExit": [0, {"from": 3, "to": 100}]
}When breakOnSystemExit is not specified, the default behavior applies:
SystemExit(0)andSystemExit(None)are ignored (successful exit).- All other non-zero exit codes cause a break.
- When
djangoorflaskistrue, exit code3is also ignored (used for reload signaling). - When
breakOnSystemExitZeroistrue, the debugger also breaks onSystemExit(0)andSystemExit(None).
When breakOnSystemExit is explicitly set, it overrides all of the above — only the listed codes and ranges will cause breaks.
When filing an issue, make sure you do the following: