Repository navigation
PowerShell attach removes existing breakpoints in attached session #4489
Description
Prerequisites
- I have written a descriptive issue title.
- I have searched all open and closed issues to ensure it has not already been reported.
- I have read the troubleshooting guide.
- I am sure this issue is with the extension itself and does not reproduce in a standalone PowerShell instance.
- I have verified that I am using the latest version of Visual Studio Code and the PowerShell extension.
- If this is a security issue, I have read the security issue reporting guidance.
Summary
I use VSCode PowerShell debugger by attaching to a process hosting PowerShell.
Attaching removes breakpoints that I have already set in my session.
PowerShell Version
Name Value
---- -----
PSVersion 7.3.3
PSEdition Core
GitCommitId 7.3.3
OS Microsoft Windows 10.0.19045
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Visual Studio Code Version
1.73.1
6261075646f055b99068d3688932416f2346dd3b
x64Extension Version
ms-vscode.powershell@2023.3.3Steps to Reproduce
(1) Invoke the below script test1.ps1 in some PowerShell session. E.g. I used and saw the problem in powershell and pwsh consoles and in my application hosting PowerShell as well.
function global:test1 {
'hi'
}
Set-PSBreakpoint -Command test1
Set-PSBreakpoint -Script $PSScriptRoot\test1.ps1 -Line 2(2) Run Get-PSBreakpoint -- see 2 breakpoints
(3) In VSCode, launch/attach PowerShell debugger configured as below.
Select the target process where we have set 2 breakpoints.
{
"type": "PowerShell",
"request": "attach",
"name": "PowerShell attach",
"processId": "${command:PickPSHostProcess}",
"runspaceId": 1
},(4) With the debugger attached, run Get-PSBreakpoint again -- see that breakpoints are gone.
Visuals
No response
Logs
No response
Activity
andyleejordan commentedon Apr 3, 2023
Unfortunately that's currently just how it works until we finish #4065. So consider this in progress!
nightroman commentedon Apr 3, 2023
Andy Jordan (@andschwa) Noted, thank you. Looking forward to the progress and improvements.
FWIW, I believe (strongly) it used to work fine, breakpoints were not removed. That was my usual workflow - set breakpoints in the app, then start VSCode debugging. Granted, it was some time ago. Maybe newer versions are "not supposed to work" due to their new tech issues.
andyleejordan commentedon Apr 3, 2023
Hard to say if/when the behavior changed. As far as I remember the debugger has always issued a "clear breakpoints" command on startup, but it's a project with a looong history.
nightroman commentedon Apr 3, 2023
Some sort of proof, my user manual -- https://github.com/nightroman/FarNet/tree/main/PowerShellFar#debugging
nightroman commentedon Apr 3, 2023
Updated the manual and gave the users some hope :)
SeeminglyScience commentedon Apr 3, 2023
Yes I think at one point it "worked" in that it just didn't try to manage breakpoints in the remote session at all. Or at most just repeatedly set the same breakpoints every time you attached. I know it's not the best for your scenario but the old behavior leads to some pretty wonky UX if you are trying to set breakpoints in the UI.
As Andy said though, #4065 should make the behavior more consistent (and I'll be returning to it shortly). I don't think I touch existing breakpoints in remote sessions.
nightroman commentedon Apr 3, 2023
FWIW, PowerShellFar (Far Manager PS host) takes care of breakpoint updates via events, i.e. breakpoints set by a user in UI, or by commands, or, as I can see, even set in VSCode after attaching the debugger.
SeeminglyScience commentedon Apr 3, 2023
Then once that PR is in, breakpoints should automatically sync in both UI's regardless of where they're added 🤞
nightroman commentedon Apr 3, 2023
Anyway, it's good to know that issue is known and addressed, one way or another. I'll adjust.
nightroman commentedon Jan 29, 2024
Hello, with the recent development on fixing the debugger (https://github.com/PowerShell/vscode-powershell/releases/tag/v2024.3.0-preview), is there any chance this issue gets some progress?
andyleejordan commentedon Jan 29, 2024
That work is happening with #4065 which is still in progress.
nightroman commentedon Jan 29, 2024
Andy Jordan (@andyleejordan) It looks a little stagnated though, for a not involved observer. But I hope that "in progress" is the true status and I look forward for the fix. This is needed for some known practical scenarios, when BPs are set in a custom IDE before starting VSCode debugging.
nightroman commentedon Jan 29, 2024
FWIW, not complaining about anything, but please take a look at the manual for my users on using VSCode PowerShell debugger. You might and should be interested in the section "Known issues" (4). It's a lot of pain to make it working, apart from configuring, and IMHO many users will never enjoy VSCode PowerShell debugging by attaching (which actually works at this point, wow!).
https://github.com/nightroman/FarNet/wiki/PowerShellFar-debugging
JustinGrote commentedon Jan 29, 2024
Roman Kuzmin 1967-2026 (@nightroman) it's a very tricky PR and Patrick Meinecke (@SeeminglyScience) who owns it has been on leave for a bit. It is moving forward however.
Kaled1992 commentedon Aug 31, 2024
Kaled1992 commentedon Aug 31, 2024
{
"type": "PowerShell",
"request": "attach",
"name": "PowerShell attach",
"processId": "${command:PickPSHostProcess}",
"runspaceId": 1
},
nightroman commentedon Mar 11, 2025
Hello. Is there any chance the issue is fixed?
I'm about to close the issue as won't fix.
JustinGrote commentedon Mar 11, 2025
Not fixed yet but not forgotten! We did a deep dive into this and without doing some really tricky stuff, we have to implement custom LSP commands to make this work, which is a headache because that means we have to ensure it doesn't break other PSES consumers like neovim and then inform those owners about what they'd need to do to implement.
The LSP spec wasn't really written with "always-on" debuggers in mind, which PowerShell basically is, it was written with the idea that you start a debugee and stop it, and we really don't do that, and can't change that without breaking "ISE-like" behavior.
nightroman commentedon Dec 16, 2025
Is there any progress on this 2023 issue?
Justin Grote (@JustinGrote)
Maybe it's just the "wording", then ignore. It's not about debuggers "always-on". It's about breakpoints set in the PS host applications. Because this may be more convenient that setting them in VSCode later. My use case is PS IDE-like host application, users may set breakpoints in their opened script editors there. Then they start VSCode debugging of this host app. It would be very useful if VSCode picks up existing breakpoints, not removes them.
nightroman commentedon Dec 16, 2025
And I cannot tell my users "Do not set breakpoints in this IDE script editors, do this in VSCode on attaching its debugger".
Because VSCode debugger is not the only available and used, users choose which one to use depending on a case.
This debugger is used as well, it assumes pre-set breakpoints -- Add-Debugger.ps1
JustinGrote commentedon Dec 17, 2025
Roman Kuzmin 1967-2026 (@nightroman) so what I think we might be able to do at least in this case is interrogate the session during an attach for existing breakpoints and use the Breakpoint Event to inform the "client" of those existing breakpoints, so we don't have to reset them. The DAP spec is not clear when these should be sent but it looks like sending it anytime after
configurationDoneis acceptable, so we could send after theattachrequest and either just before or immediately after the acknowledgement. I'm unsure how various DAP clients (vscode, vim, etc.) would behave so we'd have to test it.I don't have any current plans on my roadmap to implement this to be honest, as a volunteer I just have some other project priorities at the moment.