Summary
The debugpy extension appends its noConfigScripts directory to the integrated terminal's PATH without a leading semicolon, mangling whichever entry was last in the user's PATH. This appears to be a regression of #843 (closed by #958) and #882 — both closed, but the bug is reproducible on 2025.18.0.
Environment
- VS Code: 1.117.0
- ms-python.debugpy: 2025.18.0-win32-x64
- ms-python.python: 2026.4.0-win32-x64
- OS: Windows 11 Pro 26200
- Shell: PowerShell 7.6.0 (pwsh.exe)
Steps to reproduce
- On Windows, ensure your user
PATH does not end with a trailing semicolon (this is normal — Windows strips them on save). Note the last entry.
- Open a new integrated terminal in VS Code with the Python extension active.
- Run
$env:Path -split ';' | Select-Object -Last 1.
Expected
The last PATH entry equals the user's PATH final entry, intact. The injected noConfigScripts directory appears as its own separate entry preceding it (or after, separated by ;).
Actual
The user's final PATH entry is concatenated with c:\Users\<me>\.vscode\extensions\ms-python.debugpy-2025.18.0-win32-x64\bundled\scripts\noConfigScripts to form one nonexistent merged directory.
Example from my system, where my final user-PATH entry was C:\Users\<me>\.local\bin:
C:\Users\<me>\.local\binc:\Users\<me>\.vscode\extensions\ms-python.debugpy-2025.18.0-win32-x64\bundled\scripts\noConfigScripts
Get-Command claude (whose exe lives in .local\bin) returns nothing in the integrated terminal but works in any terminal launched outside VS Code, and & "C:\Users\<me>\.local\bin\claude.exe" succeeds — confirming the file is fine and only the PATH entry is mangled.
Diagnostic snippet
$entries = $env:Path -split ';'
$entries[-1]
Output ends in ...\.local\binc:\Users\<me>\.vscode\extensions\ms-python.debugpy-...\noConfigScripts instead of ...\.local\bin.
Workaround
Append a sacrificial trailing entry to user PATH so debugpy's append-without-separator clobbers a throwaway dir instead of a real one. Not a fix — should be addressed upstream by always inserting a ; before the appended path or by appending via a list-aware API rather than string concatenation.
References
Summary
The debugpy extension appends its
noConfigScriptsdirectory to the integrated terminal'sPATHwithout a leading semicolon, mangling whichever entry was last in the user'sPATH. This appears to be a regression of #843 (closed by #958) and #882 — both closed, but the bug is reproducible on 2025.18.0.Environment
Steps to reproduce
PATHdoes not end with a trailing semicolon (this is normal — Windows strips them on save). Note the last entry.$env:Path -split ';' | Select-Object -Last 1.Expected
The last
PATHentry equals the user'sPATHfinal entry, intact. The injectednoConfigScriptsdirectory appears as its own separate entry preceding it (or after, separated by;).Actual
The user's final
PATHentry is concatenated withc:\Users\<me>\.vscode\extensions\ms-python.debugpy-2025.18.0-win32-x64\bundled\scripts\noConfigScriptsto form one nonexistent merged directory.Example from my system, where my final user-PATH entry was
C:\Users\<me>\.local\bin:Get-Command claude(whose exe lives in.local\bin) returns nothing in the integrated terminal but works in any terminal launched outside VS Code, and& "C:\Users\<me>\.local\bin\claude.exe"succeeds — confirming the file is fine and only the PATH entry is mangled.Diagnostic snippet
Output ends in
...\.local\binc:\Users\<me>\.vscode\extensions\ms-python.debugpy-...\noConfigScriptsinstead of...\.local\bin.Workaround
Append a sacrificial trailing entry to user PATH so debugpy's append-without-separator clobbers a throwaway dir instead of a real one. Not a fix — should be addressed upstream by always inserting a
;before the appended path or by appending via a list-aware API rather than string concatenation.References