If the Interactive Debugger is started, then a breakpoint is set, but then the Interactive Debugger is then stopped, the breakpoints are still present and are not synced with the breakpoint activity bar. Further runs will still trigger debug mode even if the system currently isn't in the interactive debugger.
If PSBreakpoints are cleared when the debugger stops, this should fix it. This may be a PSES issue.

Follow the instructions in the README about
capturing and sending logs.
| Name | Version |
| --- | --- |
| Operating System | Windows_NT x64 10.0.19041 |
| VSCode | 1.42.0-insider|
| PowerShell Extension Version | 2019.12.0 |
|Name|Value|
|---|---|
|PSVersion|5.1.19041.1|
|PSEdition|Desktop|
|PSCompatibleVersions|1.0 2.0 3.0 4.0 5.0 5.1.19041.1|
|BuildVersion|10.0.19041.1|
|CLRVersion|4.0.30319.42000|
|WSManStackVersion|3.0|
|PSRemotingProtocolVersion|2.3|
|SerializationVersion|1.1.0.1|
Visual Studio Code Extensions(Click to Expand)
|Extension|Author|Version|
|---|---|---|
|better-align|wwm|1.1.6|
|better-comments|aaron-bond|2.0.5|
|better-powershell-syntax-highlighting|justin-grote|0.0.2|
|bracket-pair-colorizer-2|CoenraadS|0.0.29|
|code-settings-sync|Shan|3.4.3|
|gc-excelviewer|GrapeCity|2.1.32|
|gistfs|vsls-contrib|0.0.21|
|git-graph|mhutchie|1.19.1|
|gitlens|eamodio|10.2.0|
|indent-rainbow|oderwat|7.4.0|
|markdown-all-in-one|yzhang|2.6.1|
|powershell-preview|ms-vscode|2019.12.0|
|remote-containers|ms-vscode-remote|0.95.0|
|remote-ssh-edit-nightly|ms-vscode-remote|2019.12.24000|
|remote-ssh-nightly|ms-vscode-remote|2019.12.24000|
|remote-wsl|ms-vscode-remote|0.41.6|
|todo-tree|Gruntfuggly|0.0.162|
|vscode-icons|vscode-icons-team|9.6.0|
|vscode-peacock|johnpapa|3.2.0|
|vscode-sort-json|richie5um2|1.18.0|
|vscode-zipexplorer|slevesque|0.3.1|
So this is a hard one because VS Code only gives us breakpoint gutter events "while debugging". That's why the Interactive Session exists. I opened a SO question to see if there's some mechanism that we can use to support this, but I think our hands are tied, unfortunately:
This is also related https://github.com/PowerShell/PowerShellEditorServices/issues/1091 but kinda the opposite ask.
So is it not possible to just clear all the breakpoints in the PSES powershell instance on the "stop debugging" event? That will fix the problem.
EDIT: To be clear, clear the breakpoints within PSES but not remove them in VSCode. Then the next time the debugger starts it will just reassign them based on what is currently set in VSCode. Basically this is a PSES post-debug cleanup item, even if the debug ends "unexpectedly" e.g. stop is pressed in Interactive Mode.
I suppose we could do that. The question is really what the expected behavior is... and _how_ do we want to confuse the user given the limitation of VS Code.
If we clear all the breakpoints when the debugger is stopped, a user might run a script (or command from a module) directly in the PSIC that has a breakpoint set in it (clearly looking at the editor) and expect that breakpoint to be hit and the debugger to kick in.
That would still work though wouldn't it? It would get set at time of run.
Also if you set breakpoints prior to starting a debug run in PSES, whatever
is in vscode would just be additive.
Seems like a hard edge case for default behavior, whereas the way it
behaves now affects me every single day.
On Thu, Dec 19, 2019, 3:26 PM Tyler James Leonhardt <
[email protected]> wrote:
I suppose we could do that. The question is really what the expected
behavior is... and how do we want to confuse the user given the
limitation of VS Code.If we clear all the breakpoints when the debugger is stopped, a user might
run a script (or command from a module) directly in the PSIC that has a
breakpoint set in it (clearly looking at the editor) and expect that
breakpoint to be hit and the debugger to kick in.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/PowerShell/vscode-powershell/issues/2371?email_source=notifications&email_token=ADUNKUQUTDRNHGQSQWOIHCLQZP7JNA5CNFSM4J4CF3K2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHLMBQQ#issuecomment-567722178,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADUNKUTUBTKUEUGYLXD57L3QZP7JNANCNFSM4J4CF3KQ
.
Basically, my recommendation would be:
_(Sorry for the pseudo-language, I'm not great at typescript and haven't tried to delve into the actual code)_
@rjmholt @TylerLeonhardt
An alternative thought, is it possible for the extension on a pause to "re-poll" the breakpoints? That way if you had an interruption and start again, the breakpoint list would refresh and you could clean them up at that time.
@JustinGrote that could be an interesting idea, let's reengage on this after our next release