Latest release version of the debugger will not start the debugging process

The debugging process is not starting when Run/Start Debugging is clicked.

VS Code version:
Version: 1.117.0 (user setup)
Commit: 10c8e557c8b9f9ed0a87f61f1c9a44bde731c409
Date: 2026-04-21T16:12:14-07:00
Electron: 39.8.7
ElectronBuildId: 13841579
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Python Debugger extension version: ms-python.debugpy 2026.4.0

The only workaround I found is to change "type": "debugpy" to "type": "python".

Hi. Can I get your launch.json and the screenshot of the issues?
Does it seem like with the below?

{
  // 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 Debugger: Attach using Process Id",
      "type": "debugpy",
      "request": "attach",
      "processId": "${command:pickProcess}"
    }
  ]
}

Nope, it only has a plain "Current file" debug entry.

Just create a folder, put a test.py in it with a couple of Python lines, place a breakpoint at any of them, create the default debug config file, and start the debugger.

launch.json:

{
// 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 Debugger: Current File",
        "type": "debugpy",
        "request": "launch",
        "program": "${file}",
        "console": "integratedTerminal"
    }
]

}

test.py:
a = 1
b = 2
c = 3

Furthermore, there is no error in the Output window of the Python Debugger:
2026-04-29 12:54:06.394 [info] resolveDebugConfigurationWithSubstitutedVariables: resolving interpreter for program='C:\Users\ionra\OneDrive\Desktop\1\test.py'
2026-04-29 12:54:06.418 [info] getInterpreterDetails: resource='c:\Users\ionra\OneDrive\Desktop\1\test.py' executable='C:\Program Files\Python312\python.exe'
2026-04-29 12:54:06.419 [info] resolveDebugConfigurationWithSubstitutedVariables: setting debugConfiguration.python='C:\Program Files\Python312\python.exe'
2026-04-29 12:54:06.419 [info] Resolving launch configuration with substituted variables
2026-04-29 12:54:06.423 [info] createDebugAdapterDescriptor: request='launch' name='Python Debugger: Current File'
2026-04-29 12:54:06.440 [info] getInterpreterDetails: resource='c:\Users\ionra\OneDrive\Desktop\1' executable='C:\Program Files\Python312\python.exe'
2026-04-29 12:54:06.440 [info] resolveEnvironment: new API resolving from string='C:\Program Files\Python312\python.exe'
2026-04-29 12:54:06.456 [info] getExecutableCommand: executable='C:\Program Files\Python312\python.exe' version='3.12.7'
2026-04-29 12:54:06.457 [info] createDebugAdapterDescriptor: python command parts='C:\Program Files\Python312\python.exe'
2026-04-29 12:54:06.457 [info] DAP Server launched with command: "C:\Program Files\Python312\python.exe" c:\Users\ionra.vscode\extensions\ms-python.debugpy-2026.4.0-win32-x64\bundled\libs\debugpy\adapter

Nope, it only has a plain "Current file" debug entry.

Just create a folder, put a test.py in it with a couple of Python lines, place a breakpoint at any of them, create the default debug config file, and start the debugger.

launch.json:

{ // 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 Debugger: Current File",
        "type": "debugpy",
        "request": "launch",
        "program": "${file}",
        "console": "integratedTerminal"
    }
]
}

test.py: a = 1 b = 2 c = 3

Furthermore, there is no error in the Output window of the Python Debugger: 2026-04-29 12:54:06.394 [info] resolveDebugConfigurationWithSubstitutedVariables: resolving interpreter for program='C:\Users\ionra\OneDrive\Desktop\1\test.py' 2026-04-29 12:54:06.418 [info] getInterpreterDetails: resource='c:\Users\ionra\OneDrive\Desktop\1\test.py' executable='C:\Program Files\Python312\python.exe' 2026-04-29 12:54:06.419 [info] resolveDebugConfigurationWithSubstitutedVariables: setting debugConfiguration.python='C:\Program Files\Python312\python.exe' 2026-04-29 12:54:06.419 [info] Resolving launch configuration with substituted variables 2026-04-29 12:54:06.423 [info] createDebugAdapterDescriptor: request='launch' name='Python Debugger: Current File' 2026-04-29 12:54:06.440 [info] getInterpreterDetails: resource='c:\Users\ionra\OneDrive\Desktop\1' executable='C:\Program Files\Python312\python.exe' 2026-04-29 12:54:06.440 [info] resolveEnvironment: new API resolving from string='C:\Program Files\Python312\python.exe' 2026-04-29 12:54:06.456 [info] getExecutableCommand: executable='C:\Program Files\Python312\python.exe' version='3.12.7' 2026-04-29 12:54:06.457 [info] createDebugAdapterDescriptor: python command parts='C:\Program Files\Python312\python.exe' 2026-04-29 12:54:06.457 [info] DAP Server launched with command: "C:\Program Files\Python312\python.exe" c:\Users\ionra.vscode\extensions\ms-python.debugpy-2026.4.0-win32-x64\bundled\libs\debugpy\adapter

Emm, that's pretty weird.
My environment is working well in this case.

Version: 1.117.0 (user setup)
Commit: 10c8e557c8b9f9ed0a87f61f1c9a44bde731c409
Date: 2026-04-21T16:12:14-07:00
Electron: 39.8.7
ElectronBuildId: 13841579
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26100
extension ver: 2026.4.0

Does the 2025.18.0 work well in your environment？You can install that via this button.

One more thing worth trying while you're at it: your repro path is under OneDrive\Desktop..., and OneDrive's Files-On-Demand reparse points may have caused path-resolution issues. Could you move the folder to a plain local path (e.g. C:\Temp\1\test.py) and see if the debugger starts there?

I have had the same problem since the update.
A simple debug configuration with a print("something") Python file has been failing since updating to 2026.4.0.

{
"name": "test_debug",
"type": "debugpy",
"request": "launch",
"program": "path_to_my_py_file",
"console": "integratedTerminal",
"python": "path_to_python11_exe",
}

If I change the type to python, it works just fine.

For now, I’m continuing to use version 2025.18.0.

One more thing worth trying while you're at it: your repro path is under OneDrive\Desktop..., and OneDrive's Files-On-Demand reparse points may have caused path-resolution issues. Could you move the folder to a plain local path (e.g. C:\Temp\1\test.py) and see if the debugger starts there?

Nope, I have exactly the same problem; the debugger won't start. Here are the Python Debugger logging statements for the new location (E:\Temp, a different HDD):

2026-04-29 14:34:27.077 [info] resolveDebugConfigurationWithSubstitutedVariables: resolving interpreter for program='E:\Temp\1\test.py'
2026-04-29 14:34:27.096 [info] getInterpreterDetails: resource='e:\Temp\1\test.py' executable='C:\Program Files\Python312\python.exe'
2026-04-29 14:34:27.097 [info] resolveDebugConfigurationWithSubstitutedVariables: setting debugConfiguration.python='C:\Program Files\Python312\python.exe'
2026-04-29 14:34:27.097 [info] Resolving launch configuration with substituted variables
2026-04-29 14:34:27.100 [info] createDebugAdapterDescriptor: request='launch' name='Python Debugger: Current File'
2026-04-29 14:34:27.117 [info] getInterpreterDetails: resource='e:\Temp\1' executable='C:\Program Files\Python312\python.exe'
2026-04-29 14:34:27.117 [info] resolveEnvironment: new API resolving from string='C:\Program Files\Python312\python.exe'
2026-04-29 14:34:27.132 [info] getExecutableCommand: executable='C:\Program Files\Python312\python.exe' version='3.12.7'
2026-04-29 14:34:27.132 [info] createDebugAdapterDescriptor: python command parts='C:\Program Files\Python312\python.exe'
2026-04-29 14:34:27.132 [info] DAP Server launched with command: "C:\Program Files\Python312\python.exe" c:\Users\ionra.vscode\extensions\ms-python.debugpy-2026.4.0-win32-x64\bundled\libs\debugpy\adapter

I've just updated VS Code to version:

Version: 1.118.0 (user setup)
Commit: 9b8ae15a8cf95b9bce1b590b42954530f440e816
Date: 2026-04-28T15:54:22-07:00
Electron: 39.8.8
ElectronBuildId: 13870025
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

ZA139

ZA139 Yes, 2025.18.0 works well in my current environment. I will wait for the fix, though. I still use "python" instead of "debugpy" in my launch.json file. Thanks!

I bet the issue is about installing Python in "Program Files" and having a space in the path... :) I'd had this problem in the past, and this was an issue.

Radu Ion (@radu-ion)

Thanks Radu Ion (@radu-ion) and stackfas for the reports and the version bisection — that already narrows things down a lot.

This looks like it may be a regression from #964, which is included in 2026.4.0. That PR moved fileToCommandArgumentForPythonExt(executable) so it now always wraps the interpreter path before it is handed to DebugAdapterExecutable. That matches the symptom of DAP Server launched with command: ... being the last log line with no error after.

The hypothesis predicts the bug only fires when the interpreter path contains a space, &, (, or ) — which would explain why C:\Program Files\Python312\python.exe breaks but my local setup didn't. To confirm, could you both share the exact path of the Python interpreter you're using when it fails? Specifically:

The executable= value from the getInterpreterDetails: ... line in the Output → Python Debugger panel, or
Just the path you see in the VS Code status bar / Python: Select Interpreter quick pick.

I'll try to reproduce locally with a venv at a path with a space and report back.

Quick update: I was able to reproduce locally on Windows.

Repro:

python -m venv "C:\demo dir\.venv" (path intentionally contains a space)
Set the active interpreter to C:\demo dir\.venv\Scripts\python.exe
F5 with a one-line test.py — the same hang as reported

One additional empirical detail from my repro: a debugger console window briefly flashes and disappears, which suggests the adapter process does start in some form and then exits early.
Output → Python Debugger (last few lines, abbreviated):

[info] legacyGetInterpreterDetails: executable='c:\demo dir\.venv\Scripts\python.exe' resource='...'
[info] resolveAndUpdatePythonPath - Initial state: ... python='C:\demo dir\.venv\Scripts\python.exe', ...
[info] createDebugAdapterDescriptor: request='launch' name='Python Debugger: Current File'
[info] legacyResolveEnvironment: Resolved executable='c:\demo dir\.venv\Scripts\python.exe'
[info] getExecutableCommand: executable='c:\demo dir\.venv\Scripts\python.exe' version='3.11.3'
[info] createDebugAdapterDescriptor: python command parts='c:\demo dir\.venv\Scripts\python.exe'
[info] DAP Server launched with command: "c:\demo dir\.venv\Scripts\python.exe" c:\Users\...\ms-python.debugpy-2026.4.0-win32-x64\bundled\libs\debugpy\adapter

Note that createDebugAdapterDescriptor: python command parts=... still shows the path without quotes, but the very next log line (DAP Server launched with command: ...) shows it wrapped in literal "...". That delta lines up exactly with the new line at factory.ts:88:

let executable = command.shift() ?? 'python';
executable = fileToCommandArgumentForPythonExt(executable);  // <-- added in #964
...
return new DebugAdapterExecutable(executable, args);

So the literal quote characters end up as part of the command passed into DebugAdapterExecutable, which goes through child_process.spawn (no shell). So the trigger is likely the new unconditional quoting on the PR#964.

Looks like the new quoting should be reverted.

Radu Ion (@radu-ion)

Confirmed at the spawn layer with a minimal Node repro — it is a clean ENOENT, not a downstream adapter crash.

Test: child_process.spawn invoked exactly the way factory.ts:105 invokes the adapter, with the executable string literally wrapped in "..." (matching what fileToCommandArgumentForPythonExt(executable) produces after #964):

// test-spawn-quoted.js
const cp = require('child_process');
const exe = '"c:\\demo dir\\.venv\\Scripts\\python.exe"'; // literal " wrapping
const args = ['c:\\Users\\<me>\\.vscode\\extensions\\ms-python.debugpy-2026.4.0-win32-x64\\bundled\\libs\\debugpy\\adapter'];
cp.spawn(exe, args, { stdio: 'inherit' })
  .on('error', e => console.error('SPAWN_ERROR:', e.code, e.message))
  .on('exit', c => console.log('EXIT_CODE:', c));

Result:

SPAWN: file="\"c:\\demo dir\\.venv\\Scripts\\python.exe\""
SPAWN: args=["c:\\Users\\<me>\\.vscode\\extensions\\...\\debugpy\\adapter"]
SPAWN_ERROR: ENOENT spawn "c:\demo dir\.venv\Scripts\python.exe" ENOENT

The control run with the same path without the literal " wrapping (exe = 'c:\\demo dir\\.venv\\Scripts\\python.exe') starts the adapter normally and waits on stdin for DAP messages.

So the failure path is:

libuv treats the leading " character as part of the file name → CreateProcessW returns ERROR_FILE_NOT_FOUND
no python.exe process is ever created (any brief UI element seen during F5 is a VS Code debug toolbar / terminal tab being created and torn down, not a real process)
VS Code's DAP layer swallows the spawn error, so DAP Server launched with command: ... ends up as the last visible line in the Output → Python Debugger channel — matching the exact symptom Radu Ion (@radu-ion) and stackfas reported

Fix: drop the executable = fileToCommandArgumentForPythonExt(executable); line at src/extension/debugger/adapter/factory.ts:88. DebugAdapterExecutable's command parameter is a literal path consumed by child_process.spawn (no shell), so shell-style quoting must not be applied to it. The two src/test/unittest/adapter/factory.unit.test.ts cases titled "Add quotes to interpreter path with spaces ..." need their expected DebugAdapterExecutable values updated from the quoted form back to the raw path.

Happy to put up a PR for this if it matches what you'd like.

Stop quoting interpreter path in adapter factory

Good evening, I’ve been having the same problem since the VS Code 1.118.0 update.
So what should we do to fix the issue?

You can rollback to the previous version until the bug is fixed.

I just love when we release to production with zero testing whatsoever

Same issue for me, I just updated my Python debugger and now it doesn't work as well, I changed to the old version but it still doesn't work, I tried uninstalling and reinstalling, still doesn't work. And I don't debug with launch.json, just current file

If you downgrade the version does it work? Does not for me

Hi Guys, I had the same issue after the extension updated. I downgraded the version.

My launch.json:

{
"version": "0.2.0",
"configurations": [
{
"name": "Debug Pytest File",
"type": "debugpy",
"request": "launch",
"module": "pytest",
"args": [
"${file}"
],
"justMyCode": false,
"console": "integratedTerminal"
}
]
}

I just installed the previous version and it works for me now.

Okay fix just shipped in version 2026.6.0. Should be available now.

ZA139

Thanks to ZA139 for the fix

Ugh, just missed this closing. If your user directory has a space in it (along with your Python install directory having one (like Program Files pointed out above), where .vscode\extensions are stored, it also causes an issues with the Python plugin and launching the debugger.

remutro (@remutro)

remutro (@remutro) are you saying it still doesn't work for you? My user id doesn't have a space but maybe I can replicate this on WSL

Oh I guess in Linux user names can't have spaces.

Navigation Menu

Repository navigation

Latest release version of the debugger will not start the debugging process #1013

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Latest release version of the debugger will not start the debugging process #1013

Description

Activity

ZA139 commented on Apr 29, 2026

radu-ion commented on Apr 29, 2026

ZA139 commented on Apr 29, 2026

ZA139 commented on Apr 29, 2026

stackfas commented on Apr 29, 2026

radu-ion commented on Apr 29, 2026

radu-ion commented on Apr 29, 2026

ZA139 commented on Apr 29, 2026

ZA139 commented on Apr 29, 2026

ZA139 commented on Apr 29, 2026

adrien95370 commented on Apr 29, 2026

rchiodo commented on Apr 29, 2026

5 remaining items

ProfessorDragon commented on Apr 30, 2026

mclarenmp4-22 commented on Apr 30, 2026

mclarenmp4-22 commented on Apr 30, 2026

mclarenmp4-22 commented on Apr 30, 2026

rchiodo commented on Apr 30, 2026

rchiodo commented on Apr 30, 2026

remutro commented on Apr 30, 2026

rchiodo commented on Apr 30, 2026

rchiodo commented on Apr 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions