VSCode python debugger does not go inside the third party library code even with justmycode set to false on 1.90 VS code

This was working fine till I got a message in my python extension that I should restart it. After that it has stopped working.

Environment data

debugpy version: 1.6.7
OS and version: Windows 10 Enterprise
Python version : 3.11.9 in Anaconda environment
Using VS Code or Visual Studio: VSCode

Actual behavior

Python code:

import yaml

with open("./config/config.yml", "r") as f:
    data = yaml.safe_load(f)

launch.json:

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

debug point at data = yaml.safe_load(f)
I can ctrl+click and go inside yaml.safe_load() and set a breakpoint in that method but when debugging, the control remain in the my code and does not go inside the safe_load(). Instead I can see that there is a light green debug arrow and a light green horizonal bar in that code. Pressing next jumps to the next statement inside that code but the control goes back to my code and I have to come back to safe_load() to see where the green arrow has moved to.

Please refer the below pics:

Expected behavior

The control, Yellow debug point and the horizontal bar should go inside the safe_load()

I've had the same issue since VS Code updated to v 1.90, using the debugger extension v2024.6.0.

I've had the same issue since VS Code updated to v 1.90, using the debugger extension v2024.6.0.

Were you able to find a solution to resolve this issue?

Found a workaround.
For those who are still scratching their head, downgrade your VS code to v1.89 from here

Thanks for the issue. I can repro. It looks like VS code isn't allowing stepping into the just my code frames, even though the debugger is returning a stop event inside those frames:

D+00015.797: Server[1] --> {
                 "pydevd_cmd_id": 502,
                 "seq": 92,
                 "type": "response",
                 "request_seq": 32,
                 "success": true,
                 "command": "stackTrace",
                 "body": {
                     "stackFrames": [
                         {
                             "id": 12,
                             "name": "load",
                             "line": 79,
                             "column": 1,
                             "source": {
                                 "path": "C:\\Users\\rchiodo\\source\\testing\\test_stepinto\\.venv\\Lib\\site-packages\\yaml\\__init__.py",
                                 "sourceReference": 0
                             },
                             "presentationHint": "subtle"
                         },
                         {
                             "id": 10,
                             "name": "safe_load",
                             "line": 125,
                             "column": 1,
                             "source": {
                                 "path": "C:\\Users\\rchiodo\\source\\testing\\test_stepinto\\.venv\\Lib\\site-packages\\yaml\\__init__.py",
                                 "sourceReference": 0
                             },
                             "presentationHint": "subtle"
                         },
                         {
                             "id": 2,
                             "name": "<module>",
                             "line": 4,
                             "column": 1,
                             "source": {
                                 "path": "C:\\Users\\rchiodo\\source\\testing\\test_stepinto\\test.py",
                                 "sourceReference": 0
                             }
                         },
                         {
                             "id": 5,
                             "name": "_run_code",
                             "line": 88,
                             "column": 1,
                             "source": {
                                 "path": "C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.11_3.11.2544.0_x64__qbz5n2kfra8p0\\Lib\\runpy.py",
                                 "sourceReference": 0
                             },
                             "presentationHint": "subtle"
                         },
                         {
                             "id": 6,
                             "name": "_run_module_as_main",
                             "line": 198,
                             "column": 1,
                             "source": {
                                 "path": "C:\\Program Files\\WindowsApps\\PythonSoftwareFoundation.Python.3.11_3.11.2544.0_x64__qbz5n2kfra8p0\\Lib\\runpy.py",
                                 "sourceReference": 0
                             },
                             "presentationHint": "subtle"
                         }
                     ],
                     "totalFrames": 6
                 }
             }

And I can also verify switching back to 1.89 fixes the problem for me too. This is likely a VS code issue then.

Closing in favor of the VS code issue.

I got same issue when upgrade vscode to 1.90, the debugger have green line in library when debug, but it always switch to outside of library, maybe an issue of vscode

This is the VS code issue causing the problem:
microsoft/vscode#214433

It's marked as a candidate so it should ship soon.

And I can also verify switching back to 1.89 fixes the problem for me too. This is likely a VS code issue then.

I downgraded visual studio to version 1.89.1 and it is still failing to stop in a breakpoint inside a package:

Version: 1.89.1
Commit: dc96b837cf6bb4af9cd736aa3af08cf8279f7685
Date: 2024-05-07T05:14:32.757Z
Electron: 28.2.8
ElectronBuildId: 27744544
Chromium: 120.0.6099.291
Node.js: 18.18.2
V8: 12.0.267.19-electron.0
OS: Darwin arm64 23.4.0

My configuration launch.json is as follows:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python Debugger: Current File",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "stopOnEntry": true,
            "justMyCode": false
        },
        {
            "name": "Python Debugger: Python File",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "stopOnEntry": true,
            "justMyCode": false
        }
    ]
}

Is this fixed yet? On 1.97 currently (on a remote dev server via ssh) and this still appears to be an issue

Alexander Zagajewski (@azagajewski)

Alexander Zagajewski (@azagajewski) I recommend entering a new issue. JustMyCode works for me. It all depends upon how you get debugpy into the process.

Rich Chiodo (@rchiodo)

Rich Chiodo (@rchiodo) Could you share how you set it up? I've just my code in user setting disabled and with following launch.json, it didn't work from python test explorer (the extension which allows you run/debug from UI by clicking a button next to any single test).

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Python: Debug Tests",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "purpose": [
                "debug-test"
            ],
            "console": "integratedTerminal",
            "justMyCode": false
        },
    ]
}

Switching back to python from debugpy worked straight away.

This is what I was using:

    {
        "name": "Python: Debug Tests",
        "type": "debugpy",
        "request": "launch",
        "program": "${file}",
        "purpose": [
            "debug-test"
        ],
        "console": "integratedTerminal",
        "justMyCode": false,
    },

My test looked like this:

import pytest

def test_debugstepinto():
    pytest.approx(1.0, 1.2)
    print("after")

test_debugstepinto()

And I was able to step into the 'pytest.approx' function

Rich Chiodo (@rchiodo)

Rich Chiodo (@rchiodo) Thanks for a very fast response; I've just set up the dummy test above and gave it a go, I wasn't able to step into approx with debugpy however with python it worked. Bizarre. What else can I provide to help us here?

Not sure what you mean by 'python'. As the 'type' in the launch.json?

Maybe that's using a different way to launch. I get this when I put that there:

You should make sure your extensions are the latest if that warning isn't coming through.

Otherwise it should be starting debugpy like so when you debug the test:

My terminal output looks like so.

C:\Users\rchiodo\source\testing\test_debugpy_pytest>  ${env:DEBUGPY_LOG_DIR}='c:\Users\rchiodo\.vscode\extensions\ms-python.debugpy-2025.6.0-win32-x64'; & 'c:\Users\rchiodo\AppData\Local\Programs\Python\Python313\python.exe' 'c:\Users\rchiodo\.vscode\extensions\ms-python.debugpy-2025.6.0-win32-x64\bundled\libs\debugpy\launcher' '58329' '--' 'c:\Users\rchiodo\.vscode\extensions\ms-python.python-2025.4.0-win32-x64\python_files\vscode_pytest\run_pytest_script.py' '--rootdir=c:\Users\rchiodo\source\testing\test_debugpy_pytest' '--capture=no' 
Running pytest with args: ['-p', 'vscode_pytest', '--rootdir=c:\\Users\\rchiodo\\source\\testing\\test_debugpy_pytest', '--capture=no', 'c:\\Users\\rchiodo\\source\\testing\\test_debugpy_pytest\\test_debugpy.py::test_debugstepinto']
============================= test session starts =============================
platform win32 -- Python 3.13.3, pytest-8.3.3, pluggy-1.5.0
rootdir: c:\Users\rchiodo\source\testing\test_debugpy_pytest

Rich Chiodo (@rchiodo)

Not sure what you mean by 'python'. As the 'type' in the launch.json?

Maybe that's using a different way to launch. I get this when I put that there:

You should make sure your extensions are the latest if that warning isn't coming through.

Rich Chiodo (@rchiodo) Yes the python to replace debugpy in type=debugpy. I did also get the warning but it was a deprecation only, I believe we can still fall back to the option python, i.e., type=python.

The terminal output looks similar, the key part is that I am calling debugpy,

ms-python.debugpy-2024.6.0-linux-x64/bundled/libs/debugpy/adapter/../../debugpy/launcher 51549 -- /home/demo/Live-usb-storage/projects/python/real_alpha/atm/tests/unit_tests/data_source/rest/orats/test_dummy.py

But I didn't seem to get the pytest relevant output.

If I ran it just by clicking the button next to the test, a typical way Python Test Explorer; I wasn't able to access the library code with keyboard shortcut either.

Clicking the green triangle button on the debugging pane (alt+5 for me on the keyboard would open it on the left side) does seem to let me get into the library code. Other than this, to no avail.

Actually, never mind, I found this on python test explorer repo:

Configuring debug
The extension will look for a configuration in launch.json with "type": "python" and "purpose": ["debug-test"] (or "request": "test") to load any of the following options during debugging

name
console
env
stopOnEntry
showReturnValue
redirectOutput
debugStdLib
justMyCode
subProcess
envFile

They seem to fall behind the schedule there.

This issue has been bugging me for a while as well. I have solved it simply by unchecking "Raised Exceptions" in the Breakpoints tab of VSCode.
This way it only breaks for uncaught exceptions.

Navigation Menu

Repository navigation

VSCode python debugger does not go inside the third party library code even with justmycode set to false on 1.90 VS code #1596

Environment data

Actual behavior

Expected behavior

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

VSCode python debugger does not go inside the third party library code even with justmycode set to false on 1.90 VS code #1596

Description

Environment data

Actual behavior

Expected behavior

Activity

couteau commented on Jun 7, 2024

uvnikgupta commented on Jun 7, 2024

uvnikgupta commented on Jun 7, 2024

rchiodo commented on Jun 7, 2024

rchiodo commented on Jun 7, 2024

rchiodo commented on Jun 7, 2024

nguyenvanhuybk99 commented on Jun 13, 2024

rchiodo commented on Jun 13, 2024

joanPlepi commented on Aug 12, 2024

azagajewski commented on Feb 17, 2025

rchiodo commented on Feb 18, 2025

qiuxiaomu commented on May 5, 2025

rchiodo commented on May 5, 2025

qiuxiaomu commented on May 5, 2025

rchiodo commented on May 5, 2025

rchiodo commented on May 5, 2025

qiuxiaomu commented on May 6, 2025

qiuxiaomu commented on May 6, 2025

clement-moulin-frier commented on Jul 5, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions