Change:
description: nls.localize({ comment: ['This is the description for a setting'], key: 'launch' }, "Global debug launch configuration. Should be used as an alternative to 'launch.json' that is shared across workspaces."), default: { configurations: [], compounds: [] }, $ref: launchSchemaId <ins> }, 'debug.autoFocusEditor': { type: 'boolean', description: nls.localize('debug.autoFocusEditor', "Controls whether the workbench window should be focused when the debugger stops."), default: true </ins> } } });

Discussion:
VS Code 1.10.2 Windows 10 Anniversary In the latest update of the PowerShell extension (0.11.0) we now use an integrated terminal instead of the Debug Console for interactive execution of commands. PowerShell allows the user to type commands in the console to initiate debugger operations like "stepInto", "stepOut" and "continue". When the user types such a command and presses "Enter", the focus jumps back up to the editor pane when the debugger stops at the next line or breakpoint. I would really appreciate a way to tell the debugger client UI to not change the focus automatically so that the user can keep typing commands into the console without having to manually set focus back there. Thanks!
/cc
First I checked does it make sense in general to pass focus to the editor when stepping and I think it does. As a reference I also checked what Chrome debugger is doing and they also always pass focus to the editor. However I understand your scenario and we could tackle it by either: introducing a vscode settings e.g 'debug.autoFocusEditor' - the problem with this approach is if this setting will be useful to the users in general (I think not) Introduce a field in the DAP stopped event which would specify if we should autoFocus editor - also not a fan of, since we rarely specify how the UX should behave in the protocol I am fine with doing option 1 if the need for this is great or if at least somebody else will also profit. thoughts?
I agree that option 2 isn't ideal since the protocol should focus on the details of the debugging session, not the UX. I don't think the debug.autoFocusEditor is ideal either because it would prevent me from turning that on by default for all PowerShell extension users (unless I automatically add it to their user settings, which I'd prefer not to do). What about a third option, allowing this to be configured by the debugger contribution in my I know there are no UX settings right now for the debugger contributions, but this seems like the most appropriate place to start adding them.
Adding a debugger contribution which specifies how ux behaves in the also feels ugly imho. Since none of the sollutions appear particularly appealing to me I would wait for us to get at least one more use case for this before implementing something.

But let's also wait and see thoughts
This is also happening when I hit F8 to run the "current line" in the PowerShell Extension. The Integrated Terminal is capturing focus, so I have to click back into my code in order to continue working.
Closing because we are not planning to implement this within the next 12 months.

Type: <bBug</bI have and import it to . In I have a breakpoint, either by clicking the breakpoint dot or by the line. In I set: If I open and hit F5, then when the debugger hit the breakpoint on , the editor will automatically switch to that file. Is there a way to set this off? In the setting i have tried to turn of Focus Editor On Break, Focus Window On Break, and set the Open Debug to neverOpen, but it still switches.   VS Code version: Code 1.80.1 (, 2023-07-12T17:22:07.651Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (39)</summaryExtensionVersion ------ Bookmarks13.4.1 htmlplay0.0.10 markdown-mermaid1.19.0 mermaid-markdown-syntax-highlighting1.5.2 vscode-search-long-paths0.0.3 regex0.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 githistory0.6.20 gitlens14.1.1 RunOnSave0.2.0 url-encode1.1.0 ftp-simple0.7.6 graphviz-previewer-web0.0.8 copy-markdown-as-html1.1.0 vscode-graphviz0.0.6 vscode-autohotkey-plus-plus3.3.2 json0.1.2 isort2023.10.1 python2023.12.0 vscode-pylance2023.7.20 jupyter2023.6.

jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-wsl0.80.2 powershell2023.6.0 vscode-markdown-paste-image1.0.0 graphviz-interactive-preview0.3.5 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-mermaid-preview1.6.3 quokka-vscode1.0.547 wordpress-toolbox1.3.15 JavaScriptSnippets1.8.0 yautohotkey1.1.3 esm-cjs-converter1.0.7 vitest-explorer0.2.42 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
No, the settings will avoid focusing the window or focusing the editor but we still open that editor. I think this is important otherwise it can be hard to notice that the debugger paused.
I know it's important to have it on by default, but is it possible to turn it off for individual workspace?
Maybe we could have a setting for it, but it doesn't feel like something that would be widely wanted. Can you say more about why you want it to work that way? When you are debugging and stop somewhere, don't you want to take some action on that file?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
well, since I have made sure that my file works properly, I only need take action on the one. Does that answer your question?
<!-- -a7ce-58b9-b1f9- --This feature request has not yet received the 20 community it takes to make to our backlog. 10 days to go. To learn more about how we handle feature requests, please see our . Happy Coding!

<!-- -b8df-69ca-c20a- --:slightlyfrowningface: In the last 60 days, this feature request has received less than 20 community upvotes and we closed it. Still a big Thank You to you for taking the time to create this issue! To learn more about how we handle feature requests, please see our . Happy Coding!