Cannot type in new pane or tab until focus is manually activated with mouse click #17812

@praimmugen commented on GitHub (Jul 26, 2022):

when the terminal does get into this state (where apparently nothig is focused), what does pressing tab do? That should move focus to the "next" UI element, which might help us figure out where focus is currently.

Unfortunately, pressing tab has no effect - I can't see anything getting focus no matter how many times I press the key.

I'm gonna focus in on the PowerShell repro case here. The fact that the Terminal loses focus when a WSL tab is opened is a well-known bug (I believe in WSLg).

Not sure it changes things, but in my case focus is also lost when opening new WSL panes within a tab.

@praimmugen commented on GitHub (Jul 26, 2022): > when the terminal does get into this state (where apparently nothig is focused), what does pressing tab do? That should move focus to the "next" UI element, which might help us figure out where focus is currently. Unfortunately, pressing `tab` has no effect - I can't see anything getting focus no matter how many times I press the key. > I'm gonna focus in on the PowerShell repro case here. The fact that the Terminal loses focus when a WSL tab is opened is a well-known bug (I believe in WSLg). Not sure it changes things, but in my case focus is also lost when opening new WSL panes within a tab.

claunia commented

@zadjii-msft commented on GitHub (Jul 26, 2022):

Is there anything in your PowerShell profile? If pressing tab does nothing, then I'd suspect that maybe the Terminal HWND itself doesn't even have focus, and something else is the forground window. Maybe there's something in your profile.ps1 that's like, shelling out to WSL or something

@zadjii-msft commented on GitHub (Jul 26, 2022): Is there anything in your PowerShell profile? If pressing tab does nothing, then I'd suspect that maybe the Terminal HWND itself doesn't even have focus, and something else is the forground window. Maybe there's something in your profile.ps1 that's like, shelling out to WSL or something

claunia commented

@praimmugen commented on GitHub (Jul 27, 2022):

Nothing in my PS profile, it's completely empty.

Long shot, but I also tried stopping a few apps that were running in background (things like AltDrag, AutoHotkey scripts, X server and several others), but unfortunately it didn't help.

@praimmugen commented on GitHub (Jul 27, 2022): Nothing in my PS profile, it's completely empty. Long shot, but I also tried stopping a few apps that were running in background (things like AltDrag, AutoHotkey scripts, X server and several others), but unfortunately it didn't help.

claunia commented

2026-01-31 05:54:24 +00:00

@zadjii-msft commented on GitHub (Aug 1, 2022):

I WONDER.

I wonder if this is another facet of #13589. Like, if the WS_TOOLWINDOW created by conpty becomes the foreground window for some reason? It absolutely never should, it's not visible but... clearly there's something weird happening. Maybe this is a clue as to why on Windows 10 the taskbar seems to think that it should restore the hidden window first. Maybe that's why we can't repro this either, we're checking on Windows 11. Hmm.

NOTE TO SELF: Assigning to myself to investigate on the Win10 VM to see if I can't repro this.

Also use as an opportunity to double check the taskbar code, and see what heuristic they're using, and why it thinks the conpty window is the one it should operate on.

@zadjii-msft commented on GitHub (Aug 1, 2022): I WONDER. I wonder if this is another facet of #13589. Like, if the WS_TOOLWINDOW created by conpty becomes the foreground window for some reason? It absolutely never should, it's not visible but... clearly there's something weird happening. Maybe this is a clue as to why on Windows 10 the taskbar seems to think that it should restore the hidden window first. Maybe that's why we can't repro this either, we're checking on Windows 11. Hmm. NOTE TO SELF: Assigning to myself to investigate on the Win10 VM to see if I can't repro this. Also use as an opportunity to double check the taskbar code, and see what heuristic they're using, and why it thinks the conpty window is the one it should operate on.

claunia commented

@matthuisman commented on GitHub (Aug 9, 2022):

I have similar issue, but only using command prompt in terminal.
Does not get focus. Need to click to allow typing
Multiple laptops at my company have same issue - so it may be something they have installed...

@matthuisman commented on GitHub (Aug 9, 2022): I have similar issue, but only using command prompt in terminal. Does not get focus. Need to click to allow typing Multiple laptops at my company have same issue - so it may be something they have installed...

claunia commented

2026-01-31 05:54:24 +00:00

@enlavin commented on GitHub (Aug 9, 2022):

I'm experiencing a similar issue too, no matter if I use powershell, cmd or WSL. The window does not accept input and is not reacting to other window manager shortcuts like Win-Down/Win-Up to minimize/maximize the window. Alt-Space opens a context menu at the top-left of the active screen, if that's of any help. I have tried with and without Powertoys and the behavior is the same for me.

I have also identified 3 ways to restore the focus to the terminal window:

Click inside with the mouse.
Pin the terminal to the taskbar and use Win-Number to minimize/restore the window. Restoring the window focuses it.
Try to close the window with Alt-F4. For some reason the window refocuses (it does not close) and then works as expected.

@enlavin commented on GitHub (Aug 9, 2022): I'm experiencing a similar issue too, no matter if I use powershell, cmd or WSL. The window does not accept input and is not reacting to other window manager shortcuts like Win-Down/Win-Up to minimize/maximize the window. Alt-Space opens a context menu at the top-left of the active screen, if that's of any help. I have tried with and without Powertoys and the behavior is the same for me. I have also identified 3 ways to restore the focus to the terminal window: * Click inside with the mouse. * Pin the terminal to the taskbar and use Win-Number to minimize/restore the window. Restoring the window focuses it. * Try to close the window with Alt-F4. For some reason the window refocuses (it does not close) and then works as expected.

claunia commented

2026-01-31 05:54:24 +00:00

@jimmunn commented on GitHub (Aug 15, 2022):

I see the exact behavior @enlavin reported, including the 3 ways to restore focus. It's pretty odd that alt-F4 doesn't close the app but does give my keyboard focus in the open tab. It seems like some other executable is getting focus and alt-F4 kills that executable and that sets focus to Terminal.

I am using Windows 10: 19044.1826
Windows Terminal Version: 1.14.1962.0
My default profile is Command Prompt

@jimmunn commented on GitHub (Aug 15, 2022): I see the exact behavior @enlavin reported, including the 3 ways to restore focus. It's pretty odd that alt-F4 doesn't close the app but does give my keyboard focus in the open tab. It seems like some other executable is getting focus and alt-F4 kills that executable and that sets focus to Terminal. I am using Windows 10: 19044.1826 Windows Terminal Version: 1.14.1962.0 My default profile is Command Prompt

claunia commented

@kh185193 commented on GitHub (Aug 18, 2022):

I have been having the same issue for a while now. My default terminal is WSL (Ubuntu), but I see the same occur with Powershell and Command Prompt.

New windows and tabs have no focus before mouse click. After the mouse click I can alt+tab between that window and other applications with focus acting as expected. Creating a new tab on the now focused window will return the window to its unfocused state and require a further mouse click to regain it.

The only functions that seem to work on the new window (before focusing with a mouse click) are alt+f4 and minimising the window with win+down. win+up will not maximise the window when open, or re-open the window when recently minimised either.

Weirdly minimising the window with win+down then using alt+tab to open again gives the window focus again. New tabs in this window will work also. I may edit my terminal hotkey to do this for me in the meantime.

@kh185193 commented on GitHub (Aug 18, 2022): I have been having the same issue for a while now. My default terminal is WSL (Ubuntu), but I see the same occur with Powershell and Command Prompt. New windows and tabs have no focus before mouse click. After the mouse click I can `alt+tab` between that window and other applications with focus acting as expected. Creating a new tab on the now focused window will return the window to its unfocused state and require a further mouse click to regain it. The only functions that seem to work on the new window (before focusing with a mouse click) are `alt+f4` and minimising the window with `win+down`. `win+up` will not maximise the window when open, or re-open the window when recently minimised either. Weirdly minimising the window with `win+down` then using `alt+tab` to open again gives the window focus again. New tabs in this window will work also. I may edit my terminal hotkey to do this for me in the meantime.

claunia commented

@codewzrd commented on GitHub (Aug 29, 2022):

I'm experiencing the same behavior on version 1.14.2281.0. In my case, this applies to all profiles, Command Prompt, Powershell (pwsh), Ubuntu (WSL). None of the Windows keyboard shortcuts work for me.

When creating a new tab with any profile, the cursor does not blink till the tab gets focus.

I get focus in the new tab when i press Alt-F4.

@codewzrd commented on GitHub (Aug 29, 2022): I'm experiencing the same behavior on version 1.14.2281.0. In my case, this applies to all profiles, Command Prompt, Powershell (pwsh), Ubuntu (WSL). None of the Windows keyboard shortcuts work for me. When creating a new tab with any profile, the cursor does not blink till the tab gets focus. I get focus in the new tab when i press `Alt-F4`.

claunia commented

@spootle commented on GitHub (Aug 31, 2022):

Adding to the list of people with identical symptoms, with the added note that having acrylic material in the tab row enabled makes it more obvious that the entire Terminal app appears to lose focus (new tab makes the tab row go opaque, Alt+F4 kills the invisible window that is spawned at the top left of the window space and Terminal gets focus / tab row goes translucent

@spootle commented on GitHub (Aug 31, 2022): Adding to the list of people with identical symptoms, with the added note that having acrylic material in the tab row enabled makes it more obvious that the entire Terminal app appears to lose focus (new tab makes the tab row go opaque, `Alt+F4` kills the invisible window that is spawned at the top left of the window space and Terminal gets focus / tab row goes translucent

claunia commented

2026-01-31 05:54:26 +00:00

@hassec commented on GitHub (Sep 4, 2022):

I have the problem on Windows 10 that opening a new terminal won't focus the terminal.
But I also noticed the following that I though might be helpful:

using AutoHotkey's Window Spy when launching a new windows terminal instance I see it reporting that focus is on:

ahk_class PseudoConsoleWindow
ahk_exe OpenConsole.exe

So If I create a hotkey like this:

#t::
Run, wt.exe
WinWait, ahk_class PseudoConsoleWindow
WinClose, ahk_class PseudoConsoleWindow
Return

I can use Win + t to launch windows terminal and I can directly start typing as focus is correctly in the terminal because the PseudoConsoleWindow was closed.

@hassec commented on GitHub (Sep 4, 2022): I have the problem on Windows 10 that opening a new terminal won't focus the terminal. But I also noticed the following that I though might be helpful: using AutoHotkey's Window Spy when launching a new windows terminal instance I see it reporting that focus is on: ``` ahk_class PseudoConsoleWindow ahk_exe OpenConsole.exe ``` So If I create a hotkey like this: ```autohotkey #t:: Run, wt.exe WinWait, ahk_class PseudoConsoleWindow WinClose, ahk_class PseudoConsoleWindow Return ``` I can use `Win + t` to launch windows terminal and I can directly start typing as focus is correctly in the terminal because the PseudoConsoleWindow was closed.

claunia commented

@zadjii-msft commented on GitHub (Sep 6, 2022):

🐉 HERE BE DRAGONS 🐉

I wouldn't do the above post(s) and close the PseudoConsoleWindow. That might just work for now as a workaround for this bug, but could lead to all sorts of weird behavior in the future. It might lead to crashes, or APIs not working right. I know in the past mingw has taken a dependency on that HWND's existence.

As much as it might seem like a viable workaround now, I'd much rather just fix the root cause, than have people try and close that window. I'm gonna collapse comments suggesting to do that for this reason. I don't know why yet the PseudoConsoleWindow is showing up as something that can steal focus (and even be closed in the first place!), but don't go closing it.

@zadjii-msft commented on GitHub (Sep 6, 2022): ## 🐉 HERE BE DRAGONS 🐉 I wouldn't do the above post(s) and close the `PseudoConsoleWindow`. That might just work for now as a workaround for this bug, but could lead to all sorts of weird behavior in the future. It might lead to crashes, or APIs not working right. I know in the past mingw has taken a dependency on that HWND's existence. As much as it might seem like a viable workaround now, I'd much rather just fix the root cause, than have people try and close that window. I'm gonna collapse comments suggesting to do that for this reason. I don't know why yet the PseudoConsoleWindow is showing up as something that can steal focus (and even be closed in the first place!), but don't go closing it.

claunia commented

2026-01-31 05:54:26 +00:00

@telb99 commented on GitHub (Oct 13, 2022):

Having this same problem on one computer, not on another.
v1.15.2524.0
Consistently works as expected on my personal computer, Windows 10 latest patches.
Consistently needs manual focus with mouse click on the work computer, managed Windows 10.

The normal Windows keys to resize/move the main Terminal app do not work until I click it with the mouse.
New Terminal windows, tabs, and panes opened within Terminal always need to be manually focused and its driving me nuts :)

@telb99 commented on GitHub (Oct 13, 2022): Having this same problem on one computer, not on another. v1.15.2524.0 Consistently works as expected on my personal computer, Windows 10 latest patches. Consistently needs manual focus with mouse click on the work computer, managed Windows 10. The normal Windows keys to resize/move the main Terminal app do not work until I click it with the mouse. New Terminal windows, tabs, and panes opened within Terminal always need to be manually focused and its driving me nuts :)

claunia commented

2026-01-31 05:54:26 +00:00

@TVolden commented on GitHub (Oct 27, 2022):

I have a similar problem on Windows 10 and Windows Terminal Version: 1.15.2874.0
When I open a new terminal window, the caret does not blink and it does not respond to keyboard input.
It's not possible to open new tabs via hotkeys or to use the windows button to minimize/maximize the terminal window.
CTRL+TAB to focus on the window does not help.

The problem can be fixed by mouse-clicking on the terminal window or by pressing the ALT+F4 hotkey. (The caret starts blinking and hotkeys work).

@TVolden commented on GitHub (Oct 27, 2022): I have a similar problem on Windows 10 and Windows Terminal Version: 1.15.2874.0 When I open a new terminal window, the caret does not blink and it does not respond to keyboard input. It's not possible to open new tabs via hotkeys or to use the windows button to minimize/maximize the terminal window. CTRL+TAB to focus on the window does not help. The problem can be fixed by mouse-clicking on the terminal window or by pressing the ALT+F4 hotkey. (The caret starts blinking and hotkeys work).

claunia commented

@mgrossmann commented on GitHub (Nov 8, 2022):

Same problem with v1.15.2524.0

@mgrossmann commented on GitHub (Nov 8, 2022): Same problem with v1.15.2524.0

claunia commented

@zadjii-msft commented on GitHub (Nov 8, 2022):

Lawds I can't repro this. We've got piles of reports, so this is definitely a real bug, but I can't get it to happen with any regularity.

Maybe it has something to do with DPI scaling?

Maybe there's something I can script up to insert in the powershell startup, to debug this? Theoretically, I can't have y'all click on the window to run commands, cause that would manually focus it (destroying the bad state we're curious about). But maybe there's something we can gather at the time the tab is created, automatically?

@zadjii-msft commented on GitHub (Nov 8, 2022): Lawds I can't repro this. We've got piles of reports, so this is definitely a real bug, but I can't get it to happen with any regularity. Maybe it has something to do with DPI scaling? Maybe there's something I can script up to insert in the powershell startup, to debug this? Theoretically, I can't have y'all click on the window to run commands, cause that would manually focus it (destroying the bad state we're curious about). But maybe there's something we can gather at the time the tab is created, automatically?

claunia commented

@zadjii-msft commented on GitHub (Nov 8, 2022):

Wait is WSL installed and running when this repros? Maybe this is the WSLg thing, in secret? Does this happen every time the terminal launches? Maybe it's not the conpty window that's stealing foreground. How to check...

@zadjii-msft commented on GitHub (Nov 8, 2022): Wait is WSL installed **and running** when this repros? Maybe this is the WSLg thing, in secret? Does this happen every time the terminal launches? Maybe it's not the conpty window that's stealing foreground. How to check...

claunia commented

@matthuisman commented on GitHub (Nov 8, 2022):

happens everytime when I launch terminal.
I do have WSL installed

Opening any other shell also does not get focus until clicked

@matthuisman commented on GitHub (Nov 8, 2022): happens everytime when I launch terminal. I do have WSL installed ![image](https://user-images.githubusercontent.com/6225961/200687281-7e45d87a-3e38-405a-8c18-cb9aa9f81827.png) Opening any other shell also does not get focus until clicked

claunia commented

@spootle commented on GitHub (Nov 8, 2022):

Wait is WSL installed and running when this repros?

If I open a powershell tab, run wsl --shutdown and open another powershell tab it still fails to get focus in the same way, if that helps.

@spootle commented on GitHub (Nov 8, 2022): > Wait is WSL installed **and running** when this repros? If I open a powershell tab, run wsl --shutdown and open another powershell tab it still fails to get focus in the same way, if that helps.

claunia commented

@zadjii-msft commented on GitHub (Nov 9, 2022):

Alright, a friend on the input team has an idea. For the folks that are hitting this consistently, we've got an idea how to debug. For this, you'll need InputCore.wprp from: https://gist.github.com/zadjii-msft/b67cc8946202593725f7ada64c6cb0c1

Grab that file and save it somewhere.
Open a conhost window (conhost.exe from the run dialog should work). (This might need to be run as admin, I forget)
In that window, run
```
wpr -start path\to\InputCore.wprp
```
Open the terminal. Start typing. Obviously, the input won't go into the Terminal window, but the trace should capture who is getting it.
Switch back to the conhost window, and run
```
wpr -stop input_trace.etl
```
Share that input_trace.etl file here.

This is basically a specific Feedback Hub trace, but without all the extra steps. I'll pass those along to @ekoschik, and hopefully we can get to the bottom of what's going on here.

@zadjii-msft commented on GitHub (Nov 9, 2022): Alright, a friend on the input team has an idea. **For the folks that are hitting this consistently**, we've got an idea how to debug. For this, you'll need `InputCore.wprp` from: https://gist.github.com/zadjii-msft/b67cc8946202593725f7ada64c6cb0c1 1. Grab that file and save it somewhere. 2. Open a conhost window (`conhost.exe` from the run dialog should work). (This might need to be run as admin, I forget) 3. In that window, run ``` wpr -start path\to\InputCore.wprp ``` 4. Open the terminal. Start typing. Obviously, the input won't go into the Terminal window, but the trace should capture who _is_ getting it. 5. Switch back to the conhost window, and run ``` wpr -stop input_trace.etl ``` 6. Share that `input_trace.etl` file here. This is basically a specific Feedback Hub trace, but without all the extra steps. I'll pass those along to @ekoschik, and hopefully we can get to the bottom of what's going on here.

claunia commented

@spootle commented on GitHub (Nov 9, 2022):

6. Share that input_trace.etl file here.

input_trace.zip

@spootle commented on GitHub (Nov 9, 2022): > 6\. Share that `input_trace.etl` file here. [input_trace.zip](https://github.com/microsoft/terminal/files/9975048/input_trace.zip)

claunia commented

@lbise commented on GitHub (Nov 11, 2022):

input_trace.zip

There you go, when opening a WSL window.

@lbise commented on GitHub (Nov 11, 2022): [input_trace.zip](https://github.com/microsoft/terminal/files/9991013/input_trace.zip) There you go, when opening a WSL window.

claunia commented

@zadjii-msft commented on GitHub (Nov 11, 2022):

Hokay, now I'm maybe asking too much here. Would anyone who's reproing this consistently be willing to check out the Terminal code, build main (just to validate that the issue is still happening on a dev build), then check out dev/migrie/b/13388-experiments-0, and see if the issue persists? Apparently, there's definitely a WM_ACTIVATE in the trace, on the hidden window (which should absolutely never really get brought to the FG).

The theory is that MA_NOACTIVATEANDEAT should prevent that? Again, I can't seem to repro the issue myself, which is why I'm asking for a little help here ☺️

@zadjii-msft commented on GitHub (Nov 11, 2022): Hokay, now I'm maybe asking too much here. Would anyone who's reproing this consistently be willing to check out the Terminal code, build `main` (just to validate that the issue is still happening on a dev build), then check out [`dev/migrie/b/13388-experiments-0`](https://github.com/microsoft/terminal/compare/dev/migrie/b/13388-experiments-0), and see if the issue persists? Apparently, there's definitely a `WM_ACTIVATE` in the trace, on the hidden window (which should absolutely never really get brought to the FG). The theory is that `MA_NOACTIVATEANDEAT` should prevent that? Again, I can't seem to repro the issue myself, which is why I'm asking for a little help here ☺️

claunia commented

@spootle commented on GitHub (Nov 12, 2022):

Unfortunately I can't seem to get it to even build on my machine currently so it's going to be up to @lbise from the look of it

@spootle commented on GitHub (Nov 12, 2022): Unfortunately I can't seem to get it to even build on my machine currently so it's going to be up to @lbise from the look of it

claunia commented

@lbise commented on GitHub (Nov 12, 2022):

Looks like I can only reproduce at work and I will be off next week so it will have to wait a bit.

@lbise commented on GitHub (Nov 12, 2022): Looks like I can only reproduce at work and I will be off next week so it will have to wait a bit.

claunia commented

@trueuto commented on GitHub (Nov 18, 2022):

The theory is that MA_NOACTIVATEANDEAT should prevent that? Again, I can't seem to repro the issue myself, which is why I'm asking for a little help here ☺️

Hi @zadjii-msft,
your own remark from previous comments:
"NOTE TO SELF: Assigning to myself to investigate on the Win10 VM to see if I can't repro this."

Have you tried that already? ;)

T

@trueuto commented on GitHub (Nov 18, 2022): > The theory is that `MA_NOACTIVATEANDEAT` should prevent that? Again, I can't seem to repro the issue myself, which is why I'm asking for a little help here ☺️ Hi @zadjii-msft, your own remark from previous comments: "_NOTE TO SELF: Assigning to myself to investigate on the Win10 VM to see if I can't repro this._" Have you tried that already? ;) T

claunia commented

@zadjii-msft commented on GitHub (Nov 18, 2022):

Have you tried that already? ;)

You know, I actually have. This didn't repro on my 19041 laptop, my Win10 VM, my 22000 VM, nor my 25249 PC. Hence why I'm looking for some help.

@zadjii-msft commented on GitHub (Nov 18, 2022): > Have you tried that already? ;) You know, I actually have. This didn't repro on my 19041 laptop, my Win10 VM, my 22000 VM, nor my 25249 PC. Hence why I'm looking for some help.

claunia commented

@trueuto commented on GitHub (Nov 18, 2022):

That's what I thought, but it was worth trying anyway...

I am hitting this all the time now, but I am not able to build it on this PC. I will check on another one if I face the same and try it there.

@trueuto commented on GitHub (Nov 18, 2022): That's what I thought, but it was worth trying anyway... I am hitting this all the time now, but I am not able to build it on this PC. I will check on another one if I face the same and try it there.

claunia commented

@zadjii-msft commented on GitHub (Nov 18, 2022):

Alright I'm trying something new:

Dev Build

That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo.

Can folks try that out? (I haven't tried sharing a build like this yet so we might have some technical difficulties)

@zadjii-msft commented on GitHub (Nov 18, 2022): Alright I'm trying something new: [Dev Build](https://microsoft-my.sharepoint-df.com/:f:/p/migrie/EuiraTosG31KjKAUN34yp9wBRAnbxfPbV8E2dLUw2mvCNg?e=lZjSzz) That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo. Can folks try that out? (I haven't tried sharing a build like this yet so we might have some technical difficulties)

claunia commented

@spootle commented on GitHub (Nov 19, 2022):

Got the dev build installed (I quite like the green dev label), unfortunately doesn't resolve the issue. Terminal still doesn't get focus on launch, or when opening a new tab.

e: for those also looking to install it on Win10, I had to extract the .msix to a folder and run Add-AppxPackage -Register against the manifest to get it to install unsigned in case anyone tries and fails to install the .msix directly

e2: another thing I noticed that I can't remember if it was mentioned earlier, is closing a tab correctly gives focus to the next tab, it's only opening a new tab that triggers this

@spootle commented on GitHub (Nov 19, 2022): Got the dev build installed (I quite like the green dev label), unfortunately doesn't resolve the issue. Terminal still doesn't get focus on launch, or when opening a new tab. e: for those also looking to install it on Win10, I had to extract the .msix to a folder and run Add-AppxPackage -Register against the manifest to get it to install unsigned in case anyone tries and fails to install the .msix directly e2: another thing I noticed that I can't remember if it was mentioned earlier, is closing a tab correctly gives focus to the next tab, it's only opening a new tab that triggers this

claunia commented

@trueuto commented on GitHub (Nov 20, 2022):

Not sure if this matters, but I thought I may share one more observation: it happens that when I start Terminal (i.e. new and first instance) it is already visible as icon on the taskbar, visible in the Alt-Tab list, but window itself is not visible yet. Initially I thought it was my computer lagging or so, but now I think it could have been that this first "invisible" window is up, and the actual terminal is yet to start (due to a lagging PC possibly).

Another idea to check is to install one of the older Terminal releases on a recent Windows 10/11 VM - this may help to determine if there was some change in the Terminal code itself, or maybe some Windows related patch changed its behaviour. Just a thought...

@trueuto commented on GitHub (Nov 20, 2022): Not sure if this matters, but I thought I may share one more observation: it happens that when I start Terminal (i.e. new and first instance) it is already visible as icon on the taskbar, visible in the Alt-Tab list, but window itself is not visible yet. Initially I thought it was my computer lagging or so, but now I think it could have been that this first "invisible" window is up, and the actual terminal is yet to start (due to a lagging PC possibly). Another idea to check is to install one of the older Terminal releases on a recent Windows 10/11 VM - this may help to determine if there was some change in the Terminal code itself, or maybe some Windows related patch changed its behaviour. Just a thought...

claunia commented

@lousyd commented on GitHub (Nov 21, 2022):

Hokay, now I'm maybe asking too much here. Would anyone who's reproing this consistently be willing to check out the Terminal code, build main (just to validate that the issue is still happening on a dev build), then check out dev/migrie/b/13388-experiments-0, and see if the issue persists?

Do you still need someone to do this, @zadjii-msft?

@lousyd commented on GitHub (Nov 21, 2022): > Hokay, now I'm maybe asking too much here. Would anyone who's reproing this consistently be willing to check out the Terminal code, build `main` (just to validate that the issue is still happening on a dev build), then check out [`dev/migrie/b/13388-experiments-0`](https://github.com/microsoft/terminal/compare/dev/migrie/b/13388-experiments-0), and see if the issue persists? Do you still need someone to do this, @zadjii-msft?

claunia commented

@zadjii-msft commented on GitHub (Nov 21, 2022):

@lousyd sounds like @spootle tried the release I built manually, and that didn't seem to fix it.

We'll need to come up with some other hypothesis 😕

@zadjii-msft commented on GitHub (Nov 21, 2022): @lousyd sounds like @spootle tried the [release I built manually](https://github.com/microsoft/terminal/issues/13388#issuecomment-1320317867), and that didn't seem to fix it. We'll need to come up with some other hypothesis 😕

claunia commented

@Anutrix commented on GitHub (Nov 27, 2022):

Another idea to check is to install one of the older Terminal releases on a recent Windows 10/11 VM - this may help to determine if there was some change in the Terminal code itself, or maybe some Windows related patch changed its behaviour. Just a thought...

I suspect it's some Windows related patch too.
I came to this train of thought because I was facing this almost consistently past few months. This behavior annoyed me to point that I developed a habit of clicking terminal after the first seconds.

~~Oddly, I haven't faced the issue in past few weeks. I'm on Windows 11(Microsoft Windows 10.0.22621) now. Not sure if was fixed in 22H2.~~

Update : The issue is still there.

@Anutrix commented on GitHub (Nov 27, 2022): > Another idea to check is to install one of the older Terminal releases on a recent Windows 10/11 VM - this may help to determine if there was some change in the Terminal code itself, or maybe some Windows related patch changed its behaviour. Just a thought... I suspect it's some Windows related patch too. I came to this train of thought because I was facing this almost consistently past few months. This behavior annoyed me to point that I developed a habit of clicking terminal after the first seconds. ~Oddly, I haven't faced the issue in past few weeks. I'm on Windows 11(Microsoft Windows 10.0.22621) now. Not sure if was fixed in 22H2.~ Update : The issue is still there.

claunia commented

@JoeTeumer commented on GitHub (Nov 28, 2022):

Windows Terminal
Version: 1.15.2874.0

Windows 10 Enterprise
21H2
19044.2251

I started having the issue with Opening New Tabs/Windows and I cannot type in them.
I need to use the mouse and click in the pane to focus.

This had worked OK for years.
I did install a round of Windows updates last week and now Windows Terminal focus is broken.

Status=Installed, Title=2022-11 .NET Core 3.1.31 Update for x64 Client (KB5020930)
Status=Installed, Title=2022-11 Cumulative Update for .NET Framework 3.5, 4.8 and 4.8.1 for Windows 10 Version 21H2 for x64 (KB5020687)
Status=Installed, Title=2022-11 .NET 6.0.11 Update for x64 Client (KB5020743)
Status=Installed, Title=2022-11 Cumulative Update for Windows 10 Version 21H2 for x64-based Systems (KB5019959)

@JoeTeumer commented on GitHub (Nov 28, 2022): Windows Terminal Version: 1.15.2874.0 Windows 10 Enterprise 21H2 19044.2251 I started having the issue with Opening New Tabs/Windows and I cannot type in them. I need to use the mouse and click in the pane to focus. This had worked OK for years. I did install a round of Windows updates last week and now Windows Terminal focus is broken. Status=Installed, Title=2022-11 .NET Core 3.1.31 Update for x64 Client (KB5020930) Status=Installed, Title=2022-11 Cumulative Update for .NET Framework 3.5, 4.8 and 4.8.1 for Windows 10 Version 21H2 for x64 (KB5020687) Status=Installed, Title=2022-11 .NET 6.0.11 Update for x64 Client (KB5020743) Status=Installed, Title=2022-11 Cumulative Update for Windows 10 Version 21H2 for x64-based Systems (KB5019959)

claunia commented

@JvdBossche commented on GitHub (Dec 1, 2022):

I'm also having this problem.
Specifically after opening wt (defaults to (old) "Command Prompt") or any new tab (using any shell) I can see that in the first few milliseconds the new window (or tab) has focus and then loses it. This is visible since I have some GUI setting that highlights the focussed window with a colored border.

I could not run wpr as suggested above. It returns

Failed to enable the policy to profile system performance.  
Profile Id: Core.Verbose.Memory  
Error code: 0xc5585011  
Failed to enable the policy to profile system performance.

This happens both when conhost is run normally or as administrator. This is a company laptop that is greatly locked down, but I do have admin rights (though I have to fill in a form that pops-up every time I do something like this, before it starts the as-admin-process). For that reason, I'm not even going to try to install the dev version, sorry.

My little machine, PPC15491, is a Windows 10 Enterprise build 10.0.19044
Windows Terminal is the 1.15.2874.0 version
Patches:

C:\Users\jvdboss1\Downloads>wmic qfe list
Caption                                     CSName    Description      FixComments  HotFixID   InstallDate  InstalledBy          InstalledOn  Name  ServicePackInEffect  Status
http://support.microsoft.com/?kbid=5020613  PPC15491  Update                        KB5020613               NT AUTHORITY\SYSTEM  11/16/2022
https://support.microsoft.com/help/5003791  PPC15491  Update                        KB5003791                                    10/6/2021
https://support.microsoft.com/help/5012170  PPC15491  Security Update               KB5012170               NT AUTHORITY\SYSTEM  10/11/2022
https://support.microsoft.com/help/5019959  PPC15491  Security Update               KB5019959               NT AUTHORITY\SYSTEM  11/17/2022
                                            PPC15491  Security Update               KB5014032               NT AUTHORITY\SYSTEM  6/24/2022
                                            PPC15491  Update                        KB5014035               NT AUTHORITY\SYSTEM  6/24/2022
                                            PPC15491  Update                        KB5016705               NT AUTHORITY\SYSTEM  10/11/2022
                                            PPC15491  Update                        KB5018506               NT AUTHORITY\SYSTEM  11/16/2022
                                            PPC15491  Security Update               KB5005699                                    10/6/2021

@JvdBossche commented on GitHub (Dec 1, 2022): I'm also having this problem. Specifically after opening wt (defaults to (old) "Command Prompt") or any new tab (using any shell) I can see that in the first few milliseconds the new window (or tab) has focus and then loses it. This is visible since I have some GUI setting that highlights the focussed window with a colored border. I could not run wpr as suggested above. It returns ``` Failed to enable the policy to profile system performance. Profile Id: Core.Verbose.Memory Error code: 0xc5585011 Failed to enable the policy to profile system performance. ``` This happens both when conhost is run normally or as administrator. This is a company laptop that is greatly locked down, but I do have admin rights (though I have to fill in a form that pops-up every time I do something like this, before it starts the as-admin-process). For that reason, I'm not even going to try to install the dev version, sorry. My little machine, PPC15491, is a Windows 10 Enterprise build 10.0.19044 Windows Terminal is the 1.15.2874.0 version Patches: ``` C:\Users\jvdboss1\Downloads>wmic qfe list Caption CSName Description FixComments HotFixID InstallDate InstalledBy InstalledOn Name ServicePackInEffect Status http://support.microsoft.com/?kbid=5020613 PPC15491 Update KB5020613 NT AUTHORITY\SYSTEM 11/16/2022 https://support.microsoft.com/help/5003791 PPC15491 Update KB5003791 10/6/2021 https://support.microsoft.com/help/5012170 PPC15491 Security Update KB5012170 NT AUTHORITY\SYSTEM 10/11/2022 https://support.microsoft.com/help/5019959 PPC15491 Security Update KB5019959 NT AUTHORITY\SYSTEM 11/17/2022 PPC15491 Security Update KB5014032 NT AUTHORITY\SYSTEM 6/24/2022 PPC15491 Update KB5014035 NT AUTHORITY\SYSTEM 6/24/2022 PPC15491 Update KB5016705 NT AUTHORITY\SYSTEM 10/11/2022 PPC15491 Update KB5018506 NT AUTHORITY\SYSTEM 11/16/2022 PPC15491 Security Update KB5005699 10/6/2021 ```

claunia commented

@trueuto commented on GitHub (Dec 14, 2022):

I have installed recent updates today, unfortunately no change. I am running Win 10 21H2.

Security Update  KB5021233     NT AUTHORITY\SYSTEM  2022-12-14
Update           KB5020372     NT AUTHORITY\SYSTEM  2022-12-14
Update           KB5020872     NT AUTHORITY\SYSTEM  2022-12-14

@trueuto commented on GitHub (Dec 14, 2022): I have installed recent updates today, unfortunately no change. I am running Win 10 21H2. ``` Security Update KB5021233 NT AUTHORITY\SYSTEM 2022-12-14 Update KB5020372 NT AUTHORITY\SYSTEM 2022-12-14 Update KB5020872 NT AUTHORITY\SYSTEM 2022-12-14 ```

claunia commented

2026-01-31 05:54:32 +00:00

@MrStrik3 commented on GitHub (Dec 14, 2022):

It won't be of any help in fixing this issue but I have been using Windows Terminal for more than a year now, and I always had have this terminal focusing issue. Saying so, I don't thing it's related to the past windows updates. Lots of thank yous to everybody who is trying to fix this issue, it's very appreciated 🥇

@MrStrik3 commented on GitHub (Dec 14, 2022): It won't be of any help in fixing this issue but I have been using Windows Terminal for more than a year now, and I always had have this terminal focusing issue. Saying so, I don't thing it's related to the past windows updates. Lots of thank yous to everybody who is trying to fix this issue, it's very appreciated 🥇

claunia commented

@trueuto commented on GitHub (Dec 15, 2022):

I have just received Terminal Preview update to the 1.16.3463.0 version and it seems there is no more focus issue! I will confirm over the next couple of days.

@trueuto commented on GitHub (Dec 15, 2022): I have just received Terminal Preview update to the 1.16.3463.0 version and it seems there is **no more focus issue!** I will confirm over the next couple of days.

claunia commented

2026-01-31 05:54:32 +00:00

@zadjii-msft commented on GitHub (Dec 15, 2022):

I have just received Terminal Preview update to the 1.16.3463.0 version and it seems there is no more focus issue! I will confirm over the next couple of days.

👀

I honestly don't think there's anything in that latest 1.16 patch that should have fixed this...

@zadjii-msft commented on GitHub (Dec 15, 2022): > I have just received Terminal Preview update to the 1.16.3463.0 version and it seems there is **no more focus issue!** I will confirm over the next couple of days. # 👀 I honestly don't think there's anything in that latest 1.16 patch that should have fixed this...

claunia commented

2026-01-31 05:54:32 +00:00

@JoeTeumer commented on GitHub (Dec 15, 2022):

Thanks for the tip on the Preview build.
After installing it unexpectedly fixed my Stable build 1.15.3456.0.
I can split terminal panes and open new tabs and focus is correctly following the new pane. Will keep testing...

@JoeTeumer commented on GitHub (Dec 15, 2022): Thanks for the tip on the Preview build. After installing it unexpectedly fixed my Stable build 1.15.3456.0. I can split terminal panes and open new tabs and focus is correctly following the new pane. Will keep testing...

claunia commented

@zadjii-msft commented on GitHub (Dec 15, 2022):

if #14196 fixed this I'll literally venmo Dustin a beer, cause we've had NO leads for the longest time.

Though, I'd reckon it'd be something that merged after https://github.com/microsoft/terminal/issues/13388#issuecomment-1322337109

@zadjii-msft commented on GitHub (Dec 15, 2022): if #14196 fixed this I'll literally venmo Dustin a beer, cause we've had NO leads for the longest time. Though, I'd reckon it'd be something that merged after https://github.com/microsoft/terminal/issues/13388#issuecomment-1322337109

claunia commented

@nephewtom commented on GitHub (Dec 15, 2022):

I am also having this issue.
Exactly as it is described here: https://github.com/microsoft/terminal/issues/13846

Currently:

Windows Terminal
Version: 1.15.2874.0

Microsoft Windows 10 Enterprise
10.0.19044 N/A Build 19044

This has been happening since the first day Windows Terminal was installed on a September.
And though several Windows 10 patches have been installed, the issue persists.

@nephewtom commented on GitHub (Dec 15, 2022): I am also having this issue. Exactly as it is described here: https://github.com/microsoft/terminal/issues/13846 Currently: > Windows Terminal > Version: 1.15.2874.0 > > Microsoft Windows 10 Enterprise > 10.0.19044 N/A Build 19044 > This has been happening since the first day Windows Terminal was installed on a September. And though several Windows 10 patches have been installed, the issue persists.

claunia commented

@zadjii-msft commented on GitHub (Dec 15, 2022):

@tomasorti You wanna try out https://github.com/microsoft/terminal/releases/tag/v1.15.3465.0? I have literally no reason to suspect that fixes it, but other people have had success?

@zadjii-msft commented on GitHub (Dec 15, 2022): @tomasorti You wanna try out https://github.com/microsoft/terminal/releases/tag/v1.15.3465.0? I have _literally no reason_ to suspect that fixes it, but other people have had success?

claunia commented

2026-01-31 05:54:34 +00:00

@nephewtom commented on GitHub (Dec 15, 2022):

It seems to work with that version, thank you.
Hope it does not break other stuff...

@nephewtom commented on GitHub (Dec 15, 2022): It seems to work with that version, thank you. Hope it does not break other stuff...

claunia commented

@JoeTeumer commented on GitHub (Dec 15, 2022):

Thanks for the tip on the Preview build. After installing it unexpectedly fixed my Stable build 1.15.3456.0. I can split terminal panes and open new tabs and focus is correctly following the new pane. Will keep testing...

Unfortunately, this update causes other issues.

Steps:
open an app such as Microsoft Edge or OneNote
open Windows Terminal 1.15.3456.0
select OneNote, start entering text
randomly, the Windows Terminal opens up and the text input is now directed to terminal instead of OneNote

@JoeTeumer commented on GitHub (Dec 15, 2022): > Thanks for the tip on the Preview build. After installing it unexpectedly fixed my Stable build 1.15.3456.0. I can split terminal panes and open new tabs and focus is correctly following the new pane. Will keep testing... Unfortunately, this update causes other issues. Steps: open an app such as Microsoft Edge or OneNote open Windows Terminal 1.15.3456.0 select OneNote, start entering text randomly, the Windows Terminal opens up and the text input is now directed to terminal instead of OneNote

claunia commented

2026-01-31 05:54:34 +00:00

@trueuto commented on GitHub (Dec 16, 2022):

I have the same issue as @JoeTeumer.

My observations are:

initially terminal (new window and new tab) opens properly, i.e. with focus as it should be
it happens only once for each newly opened window or tab
it is not specific to any application (Edge, OneNote); it happens also when you do not switch to other app
it takes ~30 seconds to occur
in my case input is not directed into terminal when this happens. In fact it goes nowhere. Or maybe into this invisible window that we were dealing with earlier.
it is not the terminal stealing focus, it seems it is this invisible window "showing up". If I just leave terminal active for ~30 seconds after opening new tab it gets "inactive" (this is well visible if you set unfocusedAppearance)
if this happens when terminal was the active application, first alt-tab press simply goes to terminal and not to the next app on the list(!) but there is no entry on the window list for this "invisible" window.

It seems that we're still facing the same issue but it is only delayed now...

@trueuto commented on GitHub (Dec 16, 2022): I have the same issue as @JoeTeumer. My observations are: - initially terminal (new window and new tab) opens properly, i.e. with focus as it should be - it happens only once for each newly opened window or tab - it is not specific to any application (Edge, OneNote); it happens also when you do not switch to other app - it takes ~30 seconds to occur - in my case input is **not** directed into terminal when this happens. In fact it goes nowhere. Or maybe into this invisible window that we were dealing with earlier. - it is not the terminal stealing focus, it seems it is this invisible window "showing up". If I just leave terminal active for ~30 seconds after opening new tab it gets "inactive" (this is well visible if you set unfocusedAppearance) - if this happens when terminal was the active application, first alt-tab press simply goes to terminal and not to the next app on the list(!) but there is no entry on the window list for this "invisible" window. It seems that we're still facing the same issue but it is only delayed now...

claunia commented

@hassec commented on GitHub (Dec 16, 2022):

Just upgraded my terminal too, and I can repro what @trueuto explained.

@hassec commented on GitHub (Dec 16, 2022): Just upgraded my terminal too, and I can repro what @trueuto explained.

claunia commented

@neilrees commented on GitHub (Dec 19, 2022):

After installing the dev build above...
On launch the new window does not receive focus, but after clicking once to bring it to the foreground newly created tabs do focus correctly. It doesn't persist though, sometimes switching away and then ALT+TAB to return doesn't return focus to it, but once clicking it works correctly again.
Interestingly I observe the same behaviour in the main Windows Terminal whilst the Dev Windows Terminal is running - new tabs open correctly and it generally works much better. When Dev Windows Terminal is closed the old behaviour returns.

Hope that's useful to your fault finding.

@neilrees commented on GitHub (Dec 19, 2022): After installing the dev build above... On launch the new window does not receive focus, but after clicking once to bring it to the foreground newly created tabs do focus correctly. It doesn't persist though, _sometimes_ switching away and then ALT+TAB to return doesn't return focus to it, but once clicking it works correctly again. Interestingly I observe the same behaviour in the main Windows Terminal whilst the Dev Windows Terminal is running - new tabs open correctly and it generally works much better. When Dev Windows Terminal is closed the old behaviour returns. Hope that's useful to your fault finding.

claunia commented

@trueuto commented on GitHub (Dec 19, 2022):

Hi, I have the following update to my observations above:

it takes this issue 35 seconds to materialize
when focus switch occurs, the new window handle seems to belong to the shell process that was started in the new tab

I have used this quick and dirty script below to get that info - I am not sure if this is a valid troubleshooting, though. I have started it in the Windows PowerShell session running in one of the Windows Terminal tabs. Changing the profile started by the wt new-profile -p "profile" command makes this new invisible window to belong to the respective shell process.

I hope this helps.

try {
	Add-Type @"
using System;
using System.Runtime.InteropServices;
public class Tricks {
    [DllImport("user32.dll")]
    public static extern IntPtr GetForegroundWindow();
}
"@
} catch {
	Write-Host "Add-Type #1 exception"
}

try {
	$user32 = Add-Type -MemberDefinition @'
[DllImport("user32.dll", SetLastError=true)]
public static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId);
'@ -PassThru -Name user32Func
} catch {
	Write-Host "Add-Type #2 exception"
}

function log($txt) {
	$ts = Get-Date
	Write-Host "[$ts] $txt"
}

$stopwatch = [System.Diagnostics.Stopwatch]::new()

log "Starting WT..."
wt new-tab -p "PowerShell"
$stopwatch.Start()
log "...done"

# Get current (wt) window ID
$current_wt_win_handle = $([tricks]::GetForegroundWindow())
log "Current WT handle: $current_wt_win_handle"
$wt_proc = 0
$wt_thread_id = $user32::GetWindowThreadProcessId($current_wt_win_handle, [ref]$wt_proc)

log "Current WT process: $wt_proc / $wt_thread_id"

log "Wating for focus issue to occur."
while (1) {
	$new_win_handle = $([tricks]::GetForegroundWindow())
	if ($new_win_handle -ne $current_wt_win_handle) {
		$stopwatch.Stop()
		log "Got new handle ($new_win_handle) after $($stopwatch.Elapsed)"
		$new_proc = 0
		$new_thread_id = $user32::GetWindowThreadProcessId($new_win_handle, [ref]$new_proc)
		$new_proc_name = (Get-Process -Id $new_proc).Name
		log "New process: PID: $new_proc / TID: $new_thread_id / Name: $new_proc_name"
		exit
	}
	Start-Sleep .1
}

@trueuto commented on GitHub (Dec 19, 2022): Hi, I have the following update to my observations above: - it takes this issue 35 seconds to materialize - when focus switch occurs, the new window handle seems to belong to the shell process that was started in the new tab I have used this quick and dirty script below to get that info - I am not sure if this is a valid troubleshooting, though. I have started it in the Windows PowerShell session running in one of the Windows Terminal tabs. Changing the profile started by the `wt new-profile -p "profile"` command makes this new invisible window to belong to the respective shell process. I hope this helps. ``` powershell try { Add-Type @" using System; using System.Runtime.InteropServices; public class Tricks { [DllImport("user32.dll")] public static extern IntPtr GetForegroundWindow(); } "@ } catch { Write-Host "Add-Type #1 exception" } try { $user32 = Add-Type -MemberDefinition @' [DllImport("user32.dll", SetLastError=true)] public static extern uint GetWindowThreadProcessId(IntPtr hWnd, out uint lpdwProcessId); '@ -PassThru -Name user32Func } catch { Write-Host "Add-Type #2 exception" } function log($txt) { $ts = Get-Date Write-Host "[$ts] $txt" } $stopwatch = [System.Diagnostics.Stopwatch]::new() log "Starting WT..." wt new-tab -p "PowerShell" $stopwatch.Start() log "...done" # Get current (wt) window ID $current_wt_win_handle = $([tricks]::GetForegroundWindow()) log "Current WT handle: $current_wt_win_handle" $wt_proc = 0 $wt_thread_id = $user32::GetWindowThreadProcessId($current_wt_win_handle, [ref]$wt_proc) log "Current WT process: $wt_proc / $wt_thread_id" log "Wating for focus issue to occur." while (1) { $new_win_handle = $([tricks]::GetForegroundWindow()) if ($new_win_handle -ne $current_wt_win_handle) { $stopwatch.Stop() log "Got new handle ($new_win_handle) after $($stopwatch.Elapsed)" $new_proc = 0 $new_thread_id = $user32::GetWindowThreadProcessId($new_win_handle, [ref]$new_proc) $new_proc_name = (Get-Process -Id $new_proc).Name log "New process: PID: $new_proc / TID: $new_thread_id / Name: $new_proc_name" exit } Start-Sleep .1 } ```

claunia commented

2026-01-31 05:54:36 +00:00

@trueuto commented on GitHub (Dec 20, 2022):

Yet another update:

time required for the focus issue to occur is not always ~30 seconds. Today it was ~20 for me.
if I open a new tab, then open yet another new tab and close it, issue will not occur.

@trueuto commented on GitHub (Dec 20, 2022): Yet another update: - time required for the focus issue to occur is not always ~30 seconds. Today it was ~20 for me. - if I open a new tab, then open yet another new tab and close it, issue will **not** occur.

claunia commented

@rwasef1830 commented on GitHub (Dec 25, 2022):

I'm experiencing a similar issue as this but on Microsoft Edge, in addition to Windows Terminal. Quickly alt-tab from an app to edge, the edge title lights up but then no keyboard button works i have to click inside to use it. I think this is not just a Windows Terminal issue. Windows 11 22H2 being used over RDP on a Dell Precision 7510 running Windows 10 22H2.

My issue got solved by disabling all extensions and enabling them one by one. I don't understand why that worked.

@rwasef1830 commented on GitHub (Dec 25, 2022): ~~I'm experiencing a similar issue as this but on Microsoft Edge, in addition to Windows Terminal. Quickly alt-tab from an app to edge, the edge title lights up but then no keyboard button works i have to click inside to use it. I think this is not just a Windows Terminal issue. Windows 11 22H2 being used over RDP on a Dell Precision 7510 running Windows 10 22H2.~~ My issue got solved by disabling all extensions and enabling them one by one. I don't understand why that worked.

claunia commented

2026-01-31 05:54:36 +00:00

@trueuto commented on GitHub (Jan 4, 2023):

Hi @zadjii-msft

do you have any new idea of how to approach this issue? Any hope to have it resolved? 🥺

Regards,
T

@trueuto commented on GitHub (Jan 4, 2023): Hi @zadjii-msft do you have any new idea of how to approach this issue? Any hope to have it resolved? 🥺 Regards, T

claunia commented

2026-01-31 05:54:36 +00:00

@zadjii-msft commented on GitHub (Jan 4, 2023):

Nope, not yet. Just getting back from the holidays for the last couple weeks. I'll probably needs some help from my resident User32 expert colleague, who I think is still out this week. The MA_NOACTIVATEANDEAT thing didn't work, so it's back to the drawing board.

@zadjii-msft commented on GitHub (Jan 4, 2023): Nope, not yet. Just getting back from the holidays for the last couple weeks. I'll probably needs some help from my resident User32 expert colleague, who I think is still out this week. The `MA_NOACTIVATEANDEAT` thing didn't work, so it's back to the drawing board.

claunia commented

@zadjii-msft commented on GitHub (Jan 11, 2023):

New year, new shot in the dark to fix it. Could I have some folks who are still hitting this bug try the following build?

>> Get the .msix here <<

That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo.

Can folks try that out?

@zadjii-msft commented on GitHub (Jan 11, 2023): New year, new _shot in the dark to fix it_. Could I have some folks who are still hitting this bug try the following build? \>\> [Get the .msix here](https://microsoft-my.sharepoint-df.com/:f:/p/migrie/EuKbBAK9P-ZMtoRIotv9F_wBLzqHDV95AgMy1Ocbmk6A8Q?e=M4uKv8) << That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo. Can folks try that out?

claunia commented

@spootle commented on GitHub (Jan 11, 2023):

maintainer note: editorialized to focus on topic at hand. the white text issue was moved to #14667

This build appears to have resolved it for me in initial testing ... (but it at least appears to resolve this actual issue from what I can see so far)

Original post

Can folks try that out?

This build appears to have resolved it for me in initial testing, with a completely unrelated side effect of the dark mode for settings having the light mode color background rendering it completely unreadable (but it at least appears to resolve this actual issue from what I can see so far)

@spootle commented on GitHub (Jan 11, 2023): _maintainer note: editorialized to focus on topic at hand. the white text issue was moved to #14667_ This build appears to have resolved it for me in initial testing ... (but it at least appears to resolve this actual issue from what I can see so far) <details> <summary>Original post</summary> > Can folks try that out? This build appears to have resolved it for me in initial testing, with a completely unrelated side effect of the dark mode for settings having the light mode color background rendering it completely unreadable (but it at least appears to resolve this actual issue from what I can see so far) ![image](https://user-images.githubusercontent.com/17488780/211924397-f6dc36d0-dc26-4e83-9382-24a055efe441.png) </details>

claunia commented

@zadjii-msft commented on GitHub (Jan 11, 2023):

Hmm. That's probably a regression from #14567 oh god yea I definitely broke that. But that's totally unrelated (thankfully)!

That's great to hear. I'll give folks a bit longer to see if there's any other feedback. If I get any more confirmation that it seems to work, I'll probably just file a PR to put that in 1.17 for later this month.

@zadjii-msft commented on GitHub (Jan 11, 2023): Hmm. That's probably a regression from #14567 oh god yea I definitely broke that. But that's totally unrelated (thankfully)! That's great to hear. I'll give folks a bit longer to see if there's any other feedback. If I get any more confirmation that it seems to work, I'll probably just file a PR to put that in 1.17 for later this month.

claunia commented

@winni2k commented on GitHub (Jan 12, 2023):

I have the originally reported issue too.

@winni2k commented on GitHub (Jan 12, 2023): I have the originally reported issue too.

claunia commented

@trueuto commented on GitHub (Jan 12, 2023):

@winni2k you mean the same as @spootle reported? What about the original (focus) issue - did it get fixed for you?

@trueuto commented on GitHub (Jan 12, 2023): @winni2k you mean the same as @spootle reported? What about the original (focus) issue - did it get fixed for you?

claunia commented

@zadjii-msft commented on GitHub (Jan 12, 2023):

Yea, I'm gonna treat that as a +1 unless otherwise corrected. I'm also gonna go back and tidy up @spootle's earlier comment just so that we can hopefully drill in on the resolution here. Thanks all ☺️

@zadjii-msft commented on GitHub (Jan 12, 2023): Yea, I'm gonna treat that as a +1 unless otherwise corrected. I'm also gonna go back and tidy up @spootle's earlier comment just so that we can hopefully drill in on the resolution here. Thanks all ☺️

claunia commented

@winni2k commented on GitHub (Jan 12, 2023):

I tried to install the .msix file, but it is unsigned. I'll have to wait for others to do the testing, sorry.

@winni2k commented on GitHub (Jan 12, 2023): I tried to install the .msix file, but it is unsigned. I'll have to wait for others to do the testing, sorry.

claunia commented

@zadjii-msft commented on GitHub (Jan 12, 2023):

Oh derp that makes sense, I think I used the PR build pipeline instead of the Release build 😅 ~~I can kick one of those off.~~ Er, maybe I can't. Well, that's okay. We had a couple volunteers for the last unsigned one, so I'm gonna go with that for now.

@zadjii-msft commented on GitHub (Jan 12, 2023): Oh derp that makes sense, I think I used the PR build pipeline instead of the Release build 😅 ~I can kick one of those off.~ Er, maybe I can't. Well, that's okay. We had a couple volunteers for the last unsigned one, so I'm gonna go with that for now.

claunia commented

@ilyaradko commented on GitHub (Jan 13, 2023):

@zadjii-msft I am afraid a severe security threat has been introduced with this new update. Indeed, the focus is not lost anymore. However, the terminal now actively steals the focus from other applications ~30 seconds after the start if it is not active. To reproduce it: start a terminal, then switch to another app, and approximately 30 seconds after the terminal was launched it will pop up and get the focus.

Imagine a scenario where you type something in a notepad (pressing Enter occasionally) and not looking at the monitor. What can happen is that you might execute a command without being aware of that, which is very dangerous. I would rather prefer to lose the focus from terminal than terminal actively stealing the focus from other apps.

@ilyaradko commented on GitHub (Jan 13, 2023): @zadjii-msft I am afraid a severe security threat has been introduced with this new update. Indeed, the focus is not lost anymore. However, the terminal now actively steals the focus from other applications ~30 seconds after the start if it is not active. To reproduce it: start a terminal, then switch to another app, and approximately 30 seconds after the terminal was launched it will pop up and get the focus. Imagine a scenario where you type something in a notepad (pressing Enter occasionally) and not looking at the monitor. What can happen is that you might execute a command without being aware of that, which is very dangerous. I would rather prefer to lose the focus from terminal than terminal actively stealing the focus from other apps.

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2023):

Hmm. That does seem to corroborate earlier reports that the Terminal loses focus about 30s after launching the tab. The change in that build is intended to yeet focus from the hidden window backing each tab, to the main Terminal HWND whenever the hidden window gets activated. The fact that it's getting activated at all, let alone 30s after launching the tab, that's what we don't understand. It's an invisible window. It's got WS_EX_NOACTIVATE. It should never be activated in the first place.

Back to the drawing board.

@zadjii-msft commented on GitHub (Jan 13, 2023): Hmm. That does seem to corroborate earlier reports that the Terminal loses focus about 30s after launching the tab. The change in that build is intended to yeet focus from the hidden window backing each tab, to the main Terminal HWND whenever the hidden window gets activated. The fact that it's getting activated at all, let alone 30s after launching the tab, that's what we don't understand. It's an invisible window. It's got `WS_EX_NOACTIVATE`. It should never be activated in the first place. Back to the drawing board.

claunia commented

@spootle commented on GitHub (Jan 13, 2023):

Interestingly I can't replicate this stolen focus report, I've been using that latest dev build since installing it and it hasn't stolen focus once, it's behaved exactly as I would expect any other window to. In fact I'm even typing this slowly after freshly starting the terminal just to see if it steals any of this text, and it hasn't taken any of it.

For @winni2k, you can install the unsigned package by extracting the .msix to a folder and using Add-AppxPackage -Register .\AppxManifest.xml in powershell

@spootle commented on GitHub (Jan 13, 2023): Interestingly I can't replicate this stolen focus report, I've been using that latest dev build since installing it and it hasn't stolen focus once, it's behaved exactly as I would expect any other window to. In fact I'm even typing this slowly after freshly starting the terminal just to see if it steals any of this text, and it hasn't taken any of it. For @winni2k, you can install the unsigned package by extracting the .msix to a folder and using `Add-AppxPackage -Register .\AppxManifest.xml` in powershell

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2023):

Interestingly I can't replicate this stolen focus report

It's just the darndest thing. We're a tad worried that there's something installed / running that's affecting the timing here. Something like some accessibility tool, or antivirus, or autohotkey, I dunno those are just usual suspects.

My next theory is to yeet activation back at whoever just lost activation. Theoretically, that would toss it back to whoever is actually in the FG. Theoretically.

@zadjii-msft commented on GitHub (Jan 13, 2023): > Interestingly I can't replicate this stolen focus report It's just the darndest thing. We're a tad worried that there's something installed / running that's affecting the timing here. Something like some accessibility tool, or antivirus, or autohotkey, I dunno those are just usual suspects. My next theory is to yeet activation back at whoever just lost activation. Theoretically, that would toss it back to whoever is actually in the FG. Theoretically.

claunia commented

@DHowett commented on GitHub (Jan 13, 2023):

My next theory is to yeet activation back at whoever just lost activation.

This is a dangerous game to play, and I don't recommend we do that! Can the pseudoconsole window simply reject activation and let the system do what it would otherwise? Can the window be made nonactivatable?

@DHowett commented on GitHub (Jan 13, 2023): > My next theory is to yeet activation back at whoever just lost activation. This is a dangerous game to play, and I don't recommend we do that! Can the pseudoconsole window simply _reject_ activation and let the system do what it would otherwise? Can the window be made nonactivatable?

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2023):

Can the pseudoconsole window simply reject activation and let the system do what it would otherwise? Can the window be made nonactivatable?

By all accounts, setting our window as WS_EX_NOACTIVATE should have done that. I'm pretty sure there's no way to say "no thanks, I don't want to be activated" once we get that message.

@zadjii-msft commented on GitHub (Jan 13, 2023): > Can the pseudoconsole window simply _reject_ activation and let the system do what it would otherwise? Can the window be made nonactivatable? By all accounts, setting our window as `WS_EX_NOACTIVATE` _should have done that_. I'm pretty sure there's no way to say "no thanks, I don't want to be activated" once we get that message.

claunia commented

@rwasef1830 commented on GitHub (Jan 13, 2023):

Could this be related to Docker For Windows Desktop ? I see in procmon it spams launching a wsl shell every few seconds for stupid reasons which causes all kinds of trouble (Makes the task bar go up and down by itself, auto hide mode), and prevents my monitors from sleeping.

@rwasef1830 commented on GitHub (Jan 13, 2023): Could this be related to Docker For Windows Desktop ? I see in procmon it spams launching a wsl shell every few seconds for stupid reasons which causes all kinds of trouble (Makes the task bar go up and down by itself, auto hide mode), and prevents my monitors from sleeping.

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2023):

YES IT COULD BE

@zadjii-msft commented on GitHub (Jan 13, 2023): YES IT COULD BE

claunia commented

@spootle commented on GitHub (Jan 13, 2023):

I am deliberately running a much older version of Docker Desktop (4.2.0) due to other issues I have had in the past with upgrading it, if that helps narrow down why mine isn't stealing focus...

@spootle commented on GitHub (Jan 13, 2023): I am deliberately running a much older version of Docker Desktop (4.2.0) due to other issues I have had in the past with upgrading it, if that helps narrow down why mine isn't stealing focus...

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2023):

Alternatively, it could be because some CLI process it calling ActivateWindow(GetConsoleWindow()), though, that would probably be more obviously related to whatever's running in the console when the bug occurs.

I honestly have no idea if the Docker thing is necessarily related. I know there's been a lot of issues in the past with WSLg starting up and stealing focus. Docker does have some WSL distros that they use behind the scenes, so maybe that's complicating things.

That however wouldn't explain why our "manually focus the Terminal when our hidden hwnd gets WM_ACTIVATE'd" seems to steal focus after some time.

@zadjii-msft commented on GitHub (Jan 13, 2023): Alternatively, it could be because some CLI process it calling `ActivateWindow(GetConsoleWindow())`, though, that would probably be more obviously related to whatever's running in the console when the bug occurs. I honestly have no idea if the Docker thing is necessarily related. I know there's been a lot of issues in the past with WSLg starting up and stealing focus. Docker does have some WSL distros that they use behind the scenes, so maybe that's complicating things. That however wouldn't explain why our "manually focus the Terminal when our hidden hwnd gets WM_ACTIVATE'd" seems to steal focus after some time.

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2023):

Interesting late friday notes:


function steal-fg {
  $console = [Native]::GetConsoleWindow()
  Write-Host ("Console`t`t{0:x}`n" -f $console)
  Write-Host ("SAY GOODBYE TO YOUR FOCUS`n")
  [Native]::SetForegroundWindow($console);
}

function import-native()
{
  $NativeFunctions=@"
  using System;
  using System.Runtime.InteropServices;
  public class Native {
      [DllImport("kernel32.dll", SetLastError = true)]
      public static extern IntPtr GetConsoleWindow();
      [DllImport("user32.dll")]
      public static extern bool SetForegroundWindow(IntPtr hWnd);
  }
"@

  Add-Type -TypeDefinition $NativeFunctions
}

pwsh -command { import-native; steal-fg; } will then steal the focus. Presumably, in the same way. I don't think there's anything we can do about that, yikes.

@zadjii-msft commented on GitHub (Jan 13, 2023): Interesting late friday notes: ```pwsh function steal-fg { $console = [Native]::GetConsoleWindow() Write-Host ("Console`t`t{0:x}`n" -f $console) Write-Host ("SAY GOODBYE TO YOUR FOCUS`n") [Native]::SetForegroundWindow($console); } function import-native() { $NativeFunctions=@" using System; using System.Runtime.InteropServices; public class Native { [DllImport("kernel32.dll", SetLastError = true)] public static extern IntPtr GetConsoleWindow(); [DllImport("user32.dll")] public static extern bool SetForegroundWindow(IntPtr hWnd); } "@ Add-Type -TypeDefinition $NativeFunctions } ``` `pwsh -command { import-native; steal-fg; }` will then steal the focus. Presumably, in the same way. I don't think there's _anything_ we can do about that, yikes.

claunia commented

@zadjii-msft commented on GitHub (Jan 13, 2023):

Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg: Configuration setting for .wslconfig. Though, the notes there state that setting only works on Windows 11, and it seems like most folks are encountering this on Windows 10. I dunno for sure if that * is a lie or not.

I might start next week looking through here: https://github.com/docker/for-win/issues?q=is%3Aissue+console+window. That sure does feel like a dead end though.

That's all I've got for this weekend.

@zadjii-msft commented on GitHub (Jan 13, 2023): Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg: [Configuration setting for .wslconfig](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#configuration-setting-for-wslconfig). Though, the notes there state that setting only works on Windows 11, and it seems like most folks are encountering this on Windows 10. I dunno for sure if that \* is a lie or not. I might start next week looking through here: https://github.com/docker/for-win/issues?q=is%3Aissue+console+window. That sure does feel like a dead end though. That's all I've got for this weekend.

claunia commented

@mati865 commented on GitHub (Jan 13, 2023):

Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg

I had this issue on Windows 10 provided by my employer with old builtin WSL (no WSLg). I have been able to install WSL from the store just recently so I don't think WSLg is related at all.

@mati865 commented on GitHub (Jan 13, 2023): > Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg I had this issue on Windows 10 provided by my employer with old builtin WSL (no WSLg). I have been able to install WSL from the store just recently so I don't think WSLg is related at all.

claunia commented

@Anutrix commented on GitHub (Jan 14, 2023):

The issue only happens once on first usage after reboot for me. Once I face the loss of focus issue, it doesn't lose focus on any new terminal window till next reboot of my PC.

I noted this multiple times so I'm about 80% sure.

@Anutrix commented on GitHub (Jan 14, 2023): The issue only happens once on first usage after reboot for me. Once I face the loss of focus issue, it doesn't lose focus on any new terminal window till next reboot of my PC. I noted this multiple times so I'm about 80% sure.

claunia commented

@trueuto commented on GitHub (Jan 14, 2023):

I confirm this has been happening to me before I have installed WSL from the store. Also, it does not affect only WSL sessions; PowerShell or cmd are also affected. I do have autohotkey installed (as someone suggested earlier) - I will stop all running AHK scripts and check that again (although I think I have already checked that in the past...) The idea of some specific AV software may also be correct I'm afraid...

Anyway, it's good to see some traction here after a while!

@trueuto commented on GitHub (Jan 14, 2023): I confirm this has been happening to me before I have installed WSL from the store. Also, it does not affect only WSL sessions; PowerShell or cmd are also affected. I do have autohotkey installed (as someone suggested earlier) - I will stop all running AHK scripts and check that again (although I think I have already checked that in the past...) The idea of some specific AV software may also be correct I'm afraid... Anyway, it's good to see some traction here after a while!

claunia commented

@trueuto commented on GitHub (Jan 14, 2023):

With no AHK scripts running (and also with PowerToys stopped - it's Run component has a plugin for WT) - no luck.

@trueuto commented on GitHub (Jan 14, 2023): With no AHK scripts running (and also with PowerToys stopped - it's Run component has a plugin for WT) - no luck.

claunia commented

@trueuto commented on GitHub (Jan 17, 2023):

Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg: Configuration setting for .wslconfig. Though, the notes there state that setting only works on Windows 11, and it seems like most folks are encountering this on Windows 10. I dunno for sure if that * is a lie or not.

WSLg works for recent updates of Windows 10 as well. I have just disabled it but it did not help. Anyway, I regularly run WSLv1 distro only and v2 is rarely in use, but the focus issue is constantly present.

Why is it considered it has anything to do with WSL? I face this problem even if the only opened tabs in WT are PowerShell and newly started are e.g. CMD or PowerShell (with wsl completely stopped via wsl --shutdown)

@trueuto commented on GitHub (Jan 17, 2023): > Another thought - we might be able to rule out or finger WSLg this by temporarily disabling WSLg: [Configuration setting for .wslconfig](https://learn.microsoft.com/en-us/windows/wsl/wsl-config#configuration-setting-for-wslconfig). Though, the notes there state that setting only works on Windows 11, and it seems like most folks are encountering this on Windows 10. I dunno for sure if that * is a lie or not. WSLg works for recent updates of Windows 10 as well. I have just disabled it but it did not help. Anyway, I regularly run WSLv1 distro only and v2 is rarely in use, but the focus issue is constantly present. Why is it considered it has anything to do with WSL? I face this problem even if the only opened tabs in WT are PowerShell and newly started are e.g. CMD or PowerShell (with wsl completely stopped via `wsl --shutdown`)

claunia commented

@zadjii-msft commented on GitHub (Jan 17, 2023):

Why is it considered it has anything to do with WSL?

Eh, the Docker comment before had me drilled in on something that wasn't relevant. Docker leverages WSL distros in unusual ways to back some of its containers. I thought there was a chance there was a bug in the interaction between those distros and the WSLg bug that steals focus on boot.

Anywho, since folks are seeing this entirely without WSL, then that's a dead end.

Instead, we might want to drill in on whatever's trying to SetForegroundWindow the console window. That's obviously not gonna work. Though, it's like... if that's what some script was trying to do, then in conhost, you'd see the Console window pop up unexpectedly. I still wanna say this is something weird that the OS is doing with the pseudo window on launch. Maybe I just need to add gratuitous tracing to try and get a collection of window messages (and timing) for my User32 friends to take a look at.

ConsoleInputThreadProcWin32 calls VtIo::CreatePseudoWindow which calls PtySignalInputThread::CreatePseudoWindow to create the window, with the owner.
In ConptyConnection::Start, We call ConptyReparentPseudoConsole IMMEDIATELY AFTER _CreatePseudoConsoleAndPipes (which does the ConptyCreatePseudoConsole)
Theoretically though, conhost could get through ConsoleInputThreadProcWin32 before Terminal gets to ConptyReparentPseudoConsole. Theoretically.
In that case, the console is created not owned by the Terminal. Maybe that tricks the OS into focusing it weirdly?

That's at least an idea to start with. Pass the owner hwnd on the commandline. Dumb, but doable. At least to rule that out.

@zadjii-msft commented on GitHub (Jan 17, 2023): > Why is it considered it has anything to do with WSL? Eh, the Docker comment before had me drilled in on something that wasn't relevant. Docker leverages WSL distros in _unusual ways_ to back some of its containers. I thought there was a chance there was a bug in the interaction between those distros and the WSLg bug that steals focus on boot. Anywho, since folks are seeing this entirely without WSL, then that's a dead end. Instead, we might want to drill in on whatever's trying to `SetForegroundWindow` the console window. That's obviously not gonna work. Though, it's like... if that's what some script was trying to do, then _in conhost_, you'd see the Console window pop up unexpectedly. I still wanna say this is something weird that the OS is doing with the pseudo window on launch. Maybe I just need to add gratuitous tracing to try and get a collection of window messages (and timing) for my User32 friends to take a look at. <hr> * `ConsoleInputThreadProcWin32` calls `VtIo::CreatePseudoWindow` which calls `PtySignalInputThread::CreatePseudoWindow` to create the window, _with the owner_. * In `ConptyConnection::Start`, We call `ConptyReparentPseudoConsole` IMMEDIATELY AFTER `_CreatePseudoConsoleAndPipes` (which does the `ConptyCreatePseudoConsole`) * Theoretically though, conhost could get through `ConsoleInputThreadProcWin32` _before_ Terminal gets to `ConptyReparentPseudoConsole`. Theoretically. * In that case, the console is created _not owned_ by the Terminal. Maybe that tricks the OS into focusing it weirdly? That's at least an idea to start with. Pass the owner hwnd on the commandline. Dumb, but doable. At least to rule that out.

claunia commented

2026-01-31 05:54:43 +00:00

@trueuto commented on GitHub (Jan 17, 2023):

Instead, we might want to drill in on whatever's trying to SetForegroundWindow the console window.

Since some people here reported the problem on company's PCs - can it be that it is some antivirus or other anti-malware software trying to scan/analyse the console process with hidden window for potential threats? Is there any way to track it further down?

@trueuto commented on GitHub (Jan 17, 2023): > Instead, we might want to drill in on whatever's trying to `SetForegroundWindow` the console window. Since some people here reported the problem on company's PCs - can it be that it is some antivirus or other anti-malware software trying to scan/analyse the console process with hidden window for potential threats? Is there any way to track it further down?

claunia commented

@zadjii-msft commented on GitHub (Jan 17, 2023):

wake up babe, new random shot in the dark to try out just dropped. Could I have some folks who are still hitting this bug try the following build?

>> Get the .msix here <<

That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo. It might be unsigned - sorry about that! I don't think I know how to release-sign a dev build like this. You may need to enable Developer Mode to let the OS install unsigned packages.

Can folks try that out?

(this is commit 68d854011, which is "try to set the owner HWND immediately as the conpty is created")

@zadjii-msft commented on GitHub (Jan 17, 2023): wake up babe, new _random shot in the dark to try out_ just dropped. Could I have some folks who are still hitting this bug try the following build? \>\> **[Get the .msix here](https://microsoft-my.sharepoint-df.com/:f:/p/migrie/EiChJSfejY5Elu2tfG-Q_JIBmRjwfe683w7yJYzuUTSs1A?e=lW2T9c)** << That should have a CascadiaPackage .msix that will install a Dev build of the Terminal. You should be able to launch the dev version of the Terminal just like the stable version, but with a green DEV logo. It might be unsigned - sorry about that! I don't think I know how to release-sign a dev build like this. You may need to enable Developer Mode to let the OS install unsigned packages. Can folks try that out? (this is commit 68d854011, which is "try to set the owner HWND immediately as the conpty is created")

claunia commented

2026-01-31 05:54:43 +00:00

@spootle commented on GitHub (Jan 17, 2023):

@zadjii-msft unfortunately for me this build has reverted the focus behaviour back to the original issue, opening a new window or tab doesn't set focus to the terminal at all

@spootle commented on GitHub (Jan 17, 2023): @zadjii-msft unfortunately for me this build has reverted the focus behaviour back to the original issue, opening a new window or tab doesn't set focus to the terminal at all

claunia commented

2026-01-31 05:54:43 +00:00

@zadjii-msft commented on GitHub (Jan 17, 2023):

Welp, then we'll have to try Plan D. The D stands for "I Dunno what we're going to try next".

(thanks everyone for bearing with my ever increasing frustration with this one. I'm attempting to use humor as a defense mechanism)

@zadjii-msft commented on GitHub (Jan 17, 2023): Welp, then we'll have to try **Plan D**. The **D** stands for "I **D**unno what we're going to try next". (thanks everyone for bearing with my ever increasing frustration with this one. I'm attempting to use humor as a defense mechanism)

claunia commented

@trueuto commented on GitHub (Jan 18, 2023):

unfortunately for me this build has reverted the focus behaviour back to the original issue, opening a new window or tab doesn't set focus to the terminal at all

That at least was much less annoying as compared to the currently observed behaviour.

I know it may sound crazy, but is it worth trying - with this immediate focus loss - to forcefully set focus back to the terminal after a fraction of the second? Not a solution definitely, but maybe some workaround that may make it more usable and give more time to actually fix it.

The other option that comes on my mind is to try installing WT version older than 1.14.1451.0 (which is mentioned in this bug report in the initial post) and see if that behaves normally? This way we could rule out other things, theoretically...

I wish I could try that myself but with limited privileges I have on my PC I can only install what gets officially released via Store.

@trueuto commented on GitHub (Jan 18, 2023): > unfortunately for me this build has reverted the focus behaviour back to the original issue, opening a new window or tab doesn't set focus to the terminal at all That at least was much less annoying as compared to the currently observed behaviour. I know it may sound crazy, but is it worth trying - with this immediate focus loss - to forcefully set focus back to the terminal after a fraction of the second? Not a solution definitely, but maybe some workaround that may make it more usable and give more time to actually fix it. The other option that comes on my mind is to try installing WT version older than 1.14.1451.0 (which is mentioned in this bug report in the initial post) and see if that behaves normally? This way we could rule out other things, theoretically... I wish I could try that myself but with limited privileges I have on my PC I can only install what gets officially released via Store.

claunia commented

@zadjii-msft commented on GitHub (Jan 18, 2023):

I know it may sound crazy, but is it worth trying - with this immediate focus loss - to forcefully set focus back to the terminal after a fraction of the second? Not a solution definitely, but maybe some workaround that may make it more usable and give more time to actually fix it.

You'll note that's basically what I tried in https://github.com/microsoft/terminal/issues/13388#issuecomment-1379117011 (which was 7da382c948). Basically, whenever the pseudo window got activated, I'd re-activate the Terminal window.

The curious thing here is this mysterious 20-30s delay. That pseudo window should be created basically as soon as the tab starts. There shouldn't be any reason for that window to be activated by the system, unless it's being activated by some commandline script / exe.

Now, if the focus gets stolen after some delay, while the tab is just sitting idle (just sitting at a powershell / cmd prompt), then that makes me thing one of these things is happening:

The OS substantially delayed the creation of that pseudo window.
- I'm not even sure I trust this theory. Usually if an app creates a window, but that app isn't the FG window, then windows just blinks the taskbar icon at you. It doesn't typically pop that new window into the foreground AND activate it. That's nonsense. It'll only grant foreground to the new window if the thing creating the window currently had foreground.
Some other thing created a commandline process via the "default terminal" functionality, and that tab instantly closed, but not before the pseudo window had a chance to appear and try to activate.
- this would only apply to Windows 11, with a particular set of settings, and seems... unlikely. I suppose that could be diagnosed with a closeOnExit: never in the settings, but I'm doubting this
There's some other thing stealing focus
- this seems to be ruled out by https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961. That comment suggests the commandline app got focused, which makes sense - the system treats that psuedo window as the HWND of {your console application}.

It's seemingly none of those, so what is it

I think I'm gonna try a variation on attempt-001, but making sure the active window (which is losing activation) is in fact, the Terminal's window. That should mitigate https://github.com/microsoft/terminal/issues/13388#issuecomment-1382027489, where some other app is active when the pseudo hwnd gets activated, and we end up taking foreground from it.

@zadjii-msft commented on GitHub (Jan 18, 2023): > I know it may sound crazy, but is it worth trying - with this immediate focus loss - to forcefully set focus back to the terminal after a fraction of the second? Not a solution definitely, but maybe some workaround that may make it more usable and give more time to actually fix it. You'll note that's basically what I tried in https://github.com/microsoft/terminal/issues/13388#issuecomment-1379117011 (which was https://github.com/microsoft/terminal/commit/7da382c948265d64e600a75f9c7fd49bfe38141a). Basically, whenever the pseudo window got activated, I'd re-activate the Terminal window. The curious thing here is this mysterious 20-30s delay. That pseudo window should be created basically as soon as the tab starts. There _shouldn't_ be any reason for that window to be activated by the system, unless it's being activated by some commandline script / exe. Now, if the focus gets stolen after some delay, while the tab is just sitting idle (just sitting at a powershell / cmd prompt), then that makes me thing one of these things is happening: * The OS substantially delayed the creation of that pseudo window. * I'm not even sure I trust this theory. Usually if an app creates a window, but that app isn't the FG window, then windows just blinks the taskbar icon at you. It doesn't typically pop that new window into the foreground AND activate it. That's nonsense. It'll only grant foreground to the new window if the thing creating the window currently had foreground. * Some other thing created a commandline process via the "default terminal" functionality, and that tab instantly closed, but not before the pseudo window had a chance to appear and try to activate. * this would only apply to Windows 11, with a particular set of settings, and seems... unlikely. I suppose that could be diagnosed with a `closeOnExit: never` in the settings, but I'm doubting this * There's some other thing stealing focus * this seems to be ruled out by https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961. That comment suggests the commandline app got focused, which makes sense - the system treats that psuedo window as the HWND of {your console application}. It's seemingly none of those, so _what is it_ I think I'm gonna try a variation on `attempt-001`, but making sure the active window (which is losing activation) is in fact, the Terminal's window. That should mitigate https://github.com/microsoft/terminal/issues/13388#issuecomment-1382027489, where some _other_ app is active when the pseudo hwnd gets activated, and we end up taking foreground from it.

claunia commented

@trueuto commented on GitHub (Jan 18, 2023):

Thanks for explaining it!

Now, if the focus gets stolen after some delay, while the tab is just sitting idle (just sitting at a powershell / cmd prompt) [...]

Maybe it is just me misinterpreting what you wrote, but this happens not only if the tab is idle - if I am typing into the tab, the focus would be lost as well.

There is one more thing I have noticed and that is quite consistent (regardless of both tabs use the same shell or not):

Start new tab (let's call it A).
Right after it starts, start yet another one (this one is B).
Close tab B.
Focus will NOT be lost.

But when you close tab A instead of B in step 3 above, it would. So it seems this hidden window gets only activated for the most recently started tab/shell.

@trueuto commented on GitHub (Jan 18, 2023): Thanks for explaining it! > Now, if the focus gets stolen after some delay, while the tab is just sitting idle (just sitting at a powershell / cmd prompt) [...] Maybe it is just me misinterpreting what you wrote, but this happens not only if the tab is idle - if I am typing into the tab, the focus would be lost as well. There is one more thing I have noticed and that is quite consistent (regardless of both tabs use the same shell or not): 1. Start new tab (let's call it A). 2. Right after it starts, start yet another one (this one is B). 3. Close tab B. 4. Focus will NOT be lost. But when you close tab A instead of B in step 3 above, it would. So it seems this hidden window gets only activated for the most recently started tab/shell.

claunia commented

@Anutrix commented on GitHub (Jan 18, 2023):

Found the culprit I think:

C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\msrdc.exe

Tool used is https://github.com/JocysCom/FocusLogger.
Always reproducible after a fresh Windows reboot.

Apparently, there's already a ticket for it https://github.com/microsoft/wslg/issues/894.

UPDATE:
Got it to reproduce 100%.
After fresh windows boot,

Open Task Manager.
Go to processes section.
Sort by name and scroll into M section view.
Start WSL(I used an AHK shortcut to call a batch script) and wait few(5-30) seconds.
Notice losing focus when msrdc.exe is started.
Close terminal.
Now msrdc.exe will stay open for few seconds.
If you open WSL in new terminal before msrdc.exe closes, your terminal won't lose focus.
If you open WSL in new terminal after msrdc.exe closes, your terminal will lose focus in few seconds when msrdc.exe starts again.

@Anutrix commented on GitHub (Jan 18, 2023): Found the culprit I think: ``` C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\msrdc.exe ``` ![image](https://user-images.githubusercontent.com/11459028/213188217-ee20935b-3424-4833-be3b-e2c5ffab6bc3.png) Tool used is https://github.com/JocysCom/FocusLogger. Always reproducible after a fresh Windows reboot. Apparently, there's already a ticket for it https://github.com/microsoft/wslg/issues/894. **UPDATE:** Got it to reproduce 100%. After fresh windows boot, 1. Open Task Manager. 2. Go to processes section. 3. Sort by name and scroll into M section view. 4. Start WSL(I used an AHK shortcut to call a batch script) and wait few(5-30) seconds. 5. Notice losing focus when msrdc.exe is started. 6. Close terminal. Now msrdc.exe will stay open for few seconds. If you open WSL in new terminal before msrdc.exe closes, your terminal won't lose focus. If you open WSL in new terminal after msrdc.exe closes, your terminal will lose focus in few seconds when msrdc.exe starts again.

claunia commented

@trueuto commented on GitHub (Jan 18, 2023):

@Anutrix I think we have already ruled out WSLg. Also, this problem occurs even if there is no WSL running at all. And the application that "gets" the focus when it is stolen from Windows Terminal is the shell process of the most recently started Windows Terminal tab and not msrdc.exe

@trueuto commented on GitHub (Jan 18, 2023): @Anutrix I think we have already ruled out WSLg. Also, this problem occurs even if there is no WSL running at all. And the application that "gets" the focus when it is stolen from Windows Terminal is the shell process of the most recently started Windows Terminal tab and not msrdc.exe

claunia commented

@Anutrix commented on GitHub (Jan 18, 2023):

@Anutrix I think we have already ruled out WSLg. Also, this problem occurs even if there is no WSL running at all. And the application that "gets" the focus when it is stolen from Windows Terminal is the shell process of the most recently started Windows Terminal tab and not msrdc.exe

I have never lost focus when WSL wasn't running. So it might be a different rarer bug but I think it's a false positive.
And I have 100% of the times lost focus when WSL was started while msrdc.exe is not running background.

UPDATE:
Followed same steps and lost focus in Cmder.exe too so it's not WT specific.

@Anutrix commented on GitHub (Jan 18, 2023): > @Anutrix I think we have already ruled out WSLg. Also, this problem occurs even if there is no WSL running at all. And the application that "gets" the focus when it is stolen from Windows Terminal is the shell process of the most recently started Windows Terminal tab and not msrdc.exe I have never lost focus when WSL wasn't running. So it might be a different rarer bug but I think it's a false positive. And I have 100% of the times lost focus when WSL was started while msrdc.exe is not running background. **UPDATE:** Followed same steps and lost focus in Cmder.exe too so it's not WT specific.

claunia commented

@rwasef1830 commented on GitHub (Jan 18, 2023):

Could it be Discord ? I see it flashes the taskbar icon a lot and is focus-steal happy especially when trying to notify for new messages.

@rwasef1830 commented on GitHub (Jan 18, 2023): Could it be Discord ? I see it flashes the taskbar icon a lot and is focus-steal happy especially when trying to notify for new messages.

claunia commented

@Vaskinn commented on GitHub (Jan 18, 2023):

Could it be Discord ? I see it flashes the taskbar icon a lot and is focus-steal happy especially when trying to notify for new messages.

Unlikely. I have this problem on a machine without discord, and not on a machine with discord. (unless the guilty part is a component or something that discord is sharing with something I have installed)

@Vaskinn commented on GitHub (Jan 18, 2023): > Could it be Discord ? I see it flashes the taskbar icon a lot and is focus-steal happy especially when trying to notify for new messages. Unlikely. I have this problem on a machine without discord, and not on a machine with discord. (unless the guilty part is a component or something that discord is sharing with something I have installed)

claunia commented

@migue-pki commented on GitHub (Jan 18, 2023):

I just tried the focus monitoring tool shared by @Anutrix and these are my results:

Initially pwsh is getting the focus instead of WindowsTerminal, so it's not accepting any of my keypresses. After about 8 seconds pwsh grabs the focus, I press Alt-F4 (or click inside the window, the result is the same) and then WindowsTerminal is finally able to get the focus and I can start typing normally.

@migue-pki commented on GitHub (Jan 18, 2023): I just tried the focus monitoring tool shared by @Anutrix and these are my results: ![image](https://user-images.githubusercontent.com/12151058/213218959-11590eec-0cb7-47c4-a4a4-3dd88a8aafdd.png) Initially `pwsh` is getting the focus instead of `WindowsTerminal`, so it's not accepting any of my keypresses. After about 8 seconds pwsh grabs the focus, I press Alt-F4 (or click inside the window, the result is the same) and then WindowsTerminal is finally able to get the focus and I can start typing normally.

claunia commented

@zadjii-msft commented on GitHub (Jan 18, 2023):

Ah shoot. Okay, so now we've got some folks with this issue due to WSLg, and some without it. Shoot. That's gonna make reparsing this whole thread.... challenging. I might need to create a separate table with all the folks experiencing this, that have confirmed they don't have WSL installed. Like, at this point, I might need to be as nuclear as that to rule it out.

The MSCTFIME UI invokes are also... interesting to me. The IME totally could be something that does w e i r d things. Like, it's not here in that trace above, but.... maybe that's the thing trying to smuggle focus from the Terminal to the phwnd.

I'm gonna editorialize and compile reports from folks that have provided more specific details below. There's gotta be something I'm missing.

A collection of details reported by various users

Attempt 0: Just MA_NOACTIVATEANDEAT
Attempt 1: Yeet focus back to the Terminal whenever phwnd is activated
Attempt 2: Pass the owner HWND on the commandline to conpty

@spootle	If I open a powershell tab, run wsl --shutdown and open another powershell tab it still fails to get focus in the same way {Attmept 1} appears to have resolved it for me in initial testing ... (but it at least appears to resolve this actual issue from what I can see so far) I am deliberately running a much older version of Docker Desktop (4.2.0) due to other issues I have had in the past with upgrading it, if that helps narrow down why mine isn't stealing focus... Interestingly I can't replicate this stolen focus report, unfortunately for me {Attempt 2} has reverted the focus behaviour back to the original issue, opening a new window or tab doesn't set focus to the terminal at all
@trueuto	(re: Terminal 1.15.3456) I have the same issue as @JoeTeumer. initially terminal (new window and new tab) opens properly, i.e. with focus as it should be it happens only once for each newly opened window or tab it is not specific to any application (Edge, OneNote); it happens also when you do not switch to other app it takes ~30 seconds to occur in my case input is not directed into terminal when this happens. In fact it goes nowhere. Or maybe into this invisible window that we were dealing with earlier. it is not the terminal stealing focus, it seems it is this invisible window "showing up". If I just leave terminal active for ~30 seconds after opening new tab it gets "inactive" (this is well visible if you set unfocusedAppearance) if this happens when terminal was the active application, first alt-tab press simply goes to terminal and not to the next app on the list(!) but there is no entry on the window list for this "invisible" window. It seems that we're still facing the same issue but it is only delayed now... when focus switch occurs, the new window handle seems to belong to the shell process that was started in the new tab if I open a new tab, then open yet another new tab and close it, issue will not occur. I confirm this has been happening to me before I have installed WSL from the store. Also, it does not affect only WSL sessions; PowerShell or cmd are also affected. With no AHK scripts running (and also with PowerToys stopped - it's Run component has a plugin for WT) - no luck.
@migue-pki	1: Initially `pwsh` is getting the focus instead of `WindowsTerminal`, so it's not accepting any of my keypresses. After about 8 seconds pwsh grabs the focus, I press Alt-F4 (or click inside the window, the result is the same) and then WindowsTerminal is finally able to get the focus and I can start typing normally. I have WSL installed, but I was shut down for the tests I do use a English + Chinese IME, which was in English at the time of my tests ‼️‼️ WAS RUNNING "Privilege Guard Client" by Avecto ‼️‼️ - A whole bunch of people were all running this too, this might be our culprit.
@Anutrix	Found the culprit I think: `C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\msrdc.exe` So, this person's issue was definitely the WSL one
@mati865	I had this issue on Windows 10 provided by my employer with old builtin WSL (no WSLg). I have been able to install WSL from the store just recently so I don't think WSLg is related at all.
@ilyaradko	re: {Attmept 1} Indeed, the focus is not lost anymore. However, the terminal now actively steals the focus from other applications ~30 seconds after the start if it is not active. To reproduce it: start a terminal, then switch to another app, and approximately 30 seconds after the terminal was launched it will pop up and get the focus.

@zadjii-msft commented on GitHub (Jan 18, 2023): Ah shoot. Okay, so now we've got some folks with this issue due to WSLg, and some without it. Shoot. That's gonna make reparsing this whole thread.... challenging. I might need to create a separate table with all the folks experiencing this, that have confirmed they don't have WSL installed. Like, at this point, I might need to be as nuclear as that to rule it out. The MSCTFIME UI invokes are also... interesting to me. The IME totally could be something that does _w e i r d_ things. Like, it's not here in that trace above, but.... maybe that's the thing trying to smuggle focus from the Terminal to the phwnd. <hr> I'm gonna editorialize and compile reports from folks that have provided more specific details below. There's gotta be something I'm missing.  <summary>A collection of details reported by various users</summary> * Attempt 0: Just `MA_NOACTIVATEANDEAT` * Attempt 1: Yeet focus back to the Terminal whenever phwnd is activated * Attempt 2: Pass the owner HWND on the commandline to conpty <table> <tr> <td> @spootle </td> <td> If I open a powershell tab, run wsl --shutdown and open another powershell tab it still fails to get focus in the same way **{Attmept 1}** appears to have resolved it for me in initial testing ... (but it at least appears to resolve this actual issue from what I can see so far) I am deliberately running a much older version of Docker Desktop (4.2.0) due to other issues I have had in the past with upgrading it, if that helps narrow down why mine isn't stealing focus... Interestingly I can't replicate this stolen focus report, unfortunately for me **{Attempt 2}** has reverted the focus behaviour back to the original issue, opening a new window or tab doesn't set focus to the terminal at all </td> </tr> <tr> <td> @trueuto </td> <td> (re: Terminal 1.15.3456) I have the same issue as @JoeTeumer. - initially terminal (new window and new tab) opens properly, i.e. with focus as it should be - it happens only once for each newly opened window or tab - it is not specific to any application (Edge, OneNote); it happens also when you do not switch to other app - it takes ~30 seconds to occur - in my case input is **not** directed into terminal when this happens. In fact it goes nowhere. Or maybe into this invisible window that we were dealing with earlier. - it is not the terminal stealing focus, it seems it is this invisible window "showing up". If I just leave terminal active for ~30 seconds after opening new tab it gets "inactive" (this is well visible if you set unfocusedAppearance) - if this happens when terminal was the active application, first alt-tab press simply goes to terminal and not to the next app on the list(!) but there is no entry on the window list for this "invisible" window. It seems that we're still facing the same issue but it is only delayed now... * when focus switch occurs, the new window handle seems to belong to the shell process that was started in the new tab * if I open a new tab, then open yet another new tab and close it, issue will not occur. I confirm this has been happening to me before I have installed WSL from the store. Also, it does not affect only WSL sessions; PowerShell or cmd are also affected. With no AHK scripts running (and also with PowerToys stopped - it's Run component has a plugin for WT) - no luck. </td> </tr> <tr> <td> @migue-pki </td> <td> [1:](https://github.com/microsoft/terminal/issues/13388#issuecomment-1387289261) Initially `pwsh` is getting the focus instead of `WindowsTerminal`, so it's not accepting any of my keypresses. After about 8 seconds pwsh grabs the focus, I press Alt-F4 (or click inside the window, the result is the same) and then WindowsTerminal is finally able to get the focus and I can start typing normally. * I have WSL installed, but I was shut down for the tests * I do use a English + Chinese IME, which was in English at the time of my tests # ‼️‼️ WAS RUNNING "Privilege Guard Client" by Avecto ‼️‼️ - A whole bunch of people were all running this too, this might be our culprit. </td> </tr> <tr> <td> @Anutrix </td> <td> Found the culprit I think: `C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\msrdc.exe` **So, this person's issue was definitely the WSL one** </td> </tr> <tr> <td> @mati865 </td> <td> I had this issue on Windows 10 provided by my employer with old builtin WSL (no WSLg). I have been able to install WSL from the store just recently so **I don't think WSLg is related at all**. </td> </tr> <tr> <td> @ilyaradko </td> <td> re: **{Attmept 1}** Indeed, the focus is not lost anymore. However, the terminal now actively steals the focus from other applications ~30 seconds after the start if it is not active. To reproduce it: start a terminal, then switch to another app, and approximately 30 seconds after the terminal was launched it will pop up and get the focus. </td> </tr> </table> </details>

claunia commented

@migue-pki commented on GitHub (Jan 18, 2023):

To add a bit more info to my previous comment:

this is a company issued laptop with Microsoft Windows 10 Enterprise version 10.0.19044 N/A Build 19044
Terminal build is 1.15.3465.0 (because of ☝️ I cannot test your unsigned builds, sorry)
I have WSL installed, but I was shut down for the tests
I do use a English + Chinese IME, which was in English at the time of my tests

@migue-pki commented on GitHub (Jan 18, 2023): To add a bit more info to my previous comment: * this is a company issued laptop with Microsoft Windows 10 Enterprise version 10.0.19044 N/A Build 19044 * Terminal build is 1.15.3465.0 (because of ☝️ I cannot test your unsigned builds, sorry) * I have WSL installed, but I was shut down for the tests * I do use a English + Chinese IME, which was in English at the time of my tests

claunia commented

@zadjii-msft commented on GitHub (Jan 18, 2023):

I do use a English + Chinese IME

@migue-pki Just for my own notes, which one & version? Literally anything could be a lead at this point. This thread might be tracking 4 different root causes for all I know.

@zadjii-msft commented on GitHub (Jan 18, 2023): > I do use a English + Chinese IME @migue-pki Just for my own notes, which one & version? Literally anything could be a lead at this point. This thread might be tracking 4 different root causes for all I know.

claunia commented

@migue-pki commented on GitHub (Jan 18, 2023):

The IME is just the one that comes with Windows 10, no additional third-party packages as far as I know:

@migue-pki commented on GitHub (Jan 18, 2023): The IME is just the one that comes with Windows 10, no additional third-party packages as far as I know: ![image](https://user-images.githubusercontent.com/12151058/213241810-b627cece-8482-4742-95fc-b28f80752978.png)

claunia commented

@zadjii-msft commented on GitHub (Jan 20, 2023):

I'm gonna stash some quick notes before I hit the road for the weekend:

I basically have no leads left on this. I cannot get it to repro on my (real old) home Windows 10 PC, which provides no end of frustration.
My only remaining theory is that there's some third-party software that's causing the hidden window to get erroneously activated, but I have no good ideas for how to identify that.
- Theoretically, if folks filed feedback using the Feedback Hub (and share the aka.ms link here), I might get a list of your installed apps. I could possibly use that to find whatever the intersection is, and research those apps to find a repro.
Once 1.17 is out (soon^TM) I'm gonna whip up a compatibility switch for disabling this hidden window. It'll basically disable the fixes for #2988, so there'll be a lot of scenarios where apps were using GetConsoleWindow() that will break in the Terminal again. But I'm under the impression that the pain of this bug is a lot worse than the small population of apps that were using that API in the first place.
We're gonna leave this open, because we do want to get to the bottom of this. But at least for the time being, we're gonna lean on that opt-out.

Sorry, I wish it was better news.

@zadjii-msft commented on GitHub (Jan 20, 2023): I'm gonna stash some quick notes before I hit the road for the weekend: * I basically have no leads left on this. I cannot get it to repro on my (_real old_) home Windows 10 PC, which provides no end of frustration. * My only remaining theory is that there's some third-party software that's causing the hidden window to get erroneously activated, but I have no good ideas for how to identify that. * Theoretically, if folks **filed feedback** using the Feedback Hub (and share the aka.ms link here), I might get a list of your installed apps. I could possibly use that to find whatever the intersection is, and research those apps to find a repro. * Once 1.17 is out (soon<sup>TM</sup>) I'm gonna whip up a compatibility switch for disabling this hidden window. It'll basically disable the fixes for #2988, so there'll be a lot of scenarios where apps were using `GetConsoleWindow()` that will break in the Terminal again. But I'm under the impression that the pain of this bug is a lot worse than the small population of apps that were using that API in the first place. * We're gonna leave this open, because we do want to get to the bottom of this. But at least for the time being, we're gonna lean on that opt-out. Sorry, I wish it was better news.

claunia commented

@ChristophSonnleitner commented on GitHub (Jan 21, 2023):

I doubt this will help anyone, but in my case I was running a python-script I had scheduled to run before the terminal-launch with another script that launches it without showing a console window pop up.
That's what was stealing my focus (inconsistently), and as far as I can tell only on first launch of WT via shortcut [second window opened via shortcut is focused].

<#+2::
Run, C:\bat\NoScript.vbs python "C:\Users\chris\Pictures\Windows Terminal Background Pictures\python-script.py"
Run, C:\Users\chris\AppData\Local\Microsoft\WindowsApps\wt.exe -p "Ubuntu_new_Session"
return

removing NoScript.vbs fixed the issue for me.

NoScript.vbs:

    ReDim arr(WScript.Arguments.Count-1)
    For i = 0 To WScript.Arguments.Count-1
        Arg = WScript.Arguments(i)
        If InStr(Arg, " ") > 0 Then Arg = """" & Arg & """"
      arr(i) = Arg
    Next

    RunCmd = Join(arr)
    CreateObject("Wscript.Shell").Run RunCmd, 0, True
End If

P.S: The python script renames the image files in my folder from i.png to i+1.png (with a modulo by n), where i = [0..n]) and I choose 0.png as my background image in the wt settings so I have e new background every time I launch. Would be a cool feature if we could just select a folder for background image and WT selects the image randomly from there.

P.P.S. after revisiting this subject I realized that I can just run pythonw instead of python to achieve the same result [no window popup] facepalm

@ChristophSonnleitner commented on GitHub (Jan 21, 2023): I doubt this will help anyone, but in my case I was running a python-script I had scheduled to run before the terminal-launch with another script that launches it without showing a console window pop up. That's what was stealing my focus (inconsistently), and as far as I can tell only on first launch of WT via shortcut [second window opened via shortcut is focused]. ``` <#+2:: Run, C:\bat\NoScript.vbs python "C:\Users\chris\Pictures\Windows Terminal Background Pictures\python-script.py" Run, C:\Users\chris\AppData\Local\Microsoft\WindowsApps\wt.exe -p "Ubuntu_new_Session" return ``` removing NoScript.vbs fixed the issue for me. NoScript.vbs: ```If WScript.Arguments.Count >= 1 Then ReDim arr(WScript.Arguments.Count-1) For i = 0 To WScript.Arguments.Count-1 Arg = WScript.Arguments(i) If InStr(Arg, " ") > 0 Then Arg = """" & Arg & """" arr(i) = Arg Next RunCmd = Join(arr) CreateObject("Wscript.Shell").Run RunCmd, 0, True End If ``` P.S: The python script renames the image files in my folder from i.png to i+1.png (with a modulo by n), where i = [0..n]) and I choose 0.png as my background image in the wt settings so I have e new background every time I launch. Would be a cool feature if we could just select a folder for background image and WT selects the image randomly from there. P.P.S. after revisiting this subject I realized that I can just run pythonw instead of python to achieve the same result [no window popup] *facepalm*

claunia commented

@spootle commented on GitHub (Jan 26, 2023):

My only remaining theory is that there's some third-party software that's causing the hidden window to get erroneously activated, but I have no good ideas for how to identify that.

I still have zero focus stealing issues with attempt-1 (using as daily driver since), so I agree that others most likely have something installed that's doing this that I don't. Unfortunately my corporate group policy apparently blocks me from submitting feedback through feedback hub, is there any other way to manually get the list that would have generated?

@spootle commented on GitHub (Jan 26, 2023): > * My only remaining theory is that there's some third-party software that's causing the hidden window to get erroneously activated, but I have no good ideas for how to identify that. I still have zero focus stealing issues with attempt-1 (using as daily driver since), so I agree that others most likely have something installed that's doing this that I don't. Unfortunately my corporate group policy apparently blocks me from submitting feedback through feedback hub, is there any other way to manually get the list that would have generated?

claunia commented

2026-01-31 05:54:48 +00:00

@trueuto commented on GitHub (Jan 27, 2023):

I think it may be that all these attempt-n were never tested enough by this community here. And e.g. in my case it was because I am unable to install it if it does not come from the store (or is not signed, whatever).

@zadjii-msft - with the attempt-1 resulting in some positive feedback, would it be possible to include it in the next Terminal Preview release so that it can be easier deployed and tested?

@trueuto commented on GitHub (Jan 27, 2023): I think it may be that all these attempt-n were never tested enough by this community here. And e.g. in my case it was because I am unable to install it if it does not come from the store (or is not signed, whatever). @zadjii-msft - with the attempt-1 resulting in **some** positive feedback, would it be possible to include it in the next Terminal Preview release so that it can be easier deployed and tested?

claunia commented

@PennRobotics commented on GitHub (Feb 13, 2023):

I'm also seeing this (focus stolen after 5 or 10 seconds, only on the first WSL start from shutdown state) on a work computer (group policy, etc):

WSL version: 1.0.3.0
Kernel version: 5.15.79.1
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19043.2364

caused (like the others mentioned) by msrdc.exe.

Process Monitor shows a ton of activity: registry access, loading DLLs, opening files, starting new threads. The main thread created has Command line msrdc.exe /v:9740E94F-E8E4-425C-B405-17FC49E1DC02 /hvsocketserviceid:4275F880-FACB-11E6-BD58-64006A7986D3 /silent /wslg /plugin:WSLDVC_PACKAGE /wslgsharedmemorypath:WSL\9740E94F-E8E4-425C-B405-17FC49E1DC02\wslg "C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\wslg.rdp" ~~(although if I add the .wslconfig line for disabling wslg, I still have focus stolen)~~.

Only other notable details I can imagine: using AHK, proxy, a handful of network mounts, some Novell management software, running rkhunter in the background as part of my startup .rc (although that has been in-place for over a year while the focus stealing started a few weeks or months ago), and I just recently switched to the Store-based WSL. This does not happen with Powershell/cmd.exe---only with WSL (however, the focus stealing also happens in the classic conhost terminal)

I'm not sure what other detail to provide because the procmon capture of msrdc is pretty overwhelming (51,000+ events). Also, it seems this is WSL-related on my machine, so it probably belongs on microsoft/wsl rather than here, but as others mention Powershell is also affected, I can only share my own experience without a strong recommendation.

Edit: adding guiApplications=false in .wslconfig stopped the focus stealing. I thought it belonged in WSL's $HOME, but after reading other threads and putting this file in my Windows user directory, I can now open WSL and type without interruption.

I'm not sure what the fix would then be for Powershell as it never affected me... Sorry if this is somehow unrelated to the original issue!

@PennRobotics commented on GitHub (Feb 13, 2023): I'm also seeing this (focus stolen after 5 or 10 seconds, only on the first WSL start from shutdown state) on a work computer (group policy, etc): ``` WSL version: 1.0.3.0 Kernel version: 5.15.79.1 WSLg version: 1.0.47 MSRDC version: 1.2.3575 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19043.2364 ``` caused (like the others mentioned) by **msrdc.exe**. _Process Monitor_ shows a ton of activity: registry access, loading DLLs, opening files, starting new threads. The main thread created has Command line `msrdc.exe /v:9740E94F-E8E4-425C-B405-17FC49E1DC02 /hvsocketserviceid:4275F880-FACB-11E6-BD58-64006A7986D3 /silent /wslg /plugin:WSLDVC_PACKAGE /wslgsharedmemorypath:WSL\9740E94F-E8E4-425C-B405-17FC49E1DC02\wslg "C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux_1.0.3.0_x64__8wekyb3d8bbwe\wslg.rdp"` ~~(although if I add the **.wslconfig** line for disabling wslg, I still have focus stolen)~~. Only other notable details I can imagine: using AHK, proxy, a handful of network mounts, some Novell management software, running **rkhunter** in the background as part of my startup .rc (although that has been in-place for over a year while the focus stealing started a few weeks or months ago), and I just recently switched to the Store-based WSL. This does not happen with Powershell/**cmd.exe**---only with WSL (however, the focus stealing also happens in the classic **conhost** terminal) I'm not sure what other detail to provide because the **procmon** capture of **msrdc** is pretty overwhelming (51,000+ events). Also, it seems this is WSL-related on my machine, so it probably belongs on microsoft/wsl rather than here, but as others mention Powershell is also affected, I can only share my own experience without a strong recommendation. ---- Edit: adding `guiApplications=false` in **.wslconfig** stopped the focus stealing. I thought it belonged in WSL's $HOME, but after reading other threads and putting this file in my Windows user directory, I can now open WSL and type without interruption. I'm not sure what the fix would then be for Powershell as it never affected me... Sorry if this is somehow unrelated to the original issue!

claunia commented

2026-01-31 05:54:48 +00:00

@zadjii-msft commented on GitHub (Feb 14, 2023):

/idle thought: could it be some flavor of git? When I git commit, then save the file and exit it, focus doesn't return to the Terminal. Maybe it never did. Maybe they're manually activating the console HWND - they've done silly things with the HWND in the past...

@zadjii-msft commented on GitHub (Feb 14, 2023): /idle thought: could it be some flavor of git? When I `git commit`, then save the file and exit it, focus doesn't return to the Terminal. Maybe it never did. Maybe they're manually activating the console HWND - they've done silly things with the HWND in the past...

claunia commented

2026-01-31 05:54:48 +00:00

@trueuto commented on GitHub (Feb 15, 2023):

I don't think it has anything to do with Git. I have seen it recently on a PC with no Git installed. I am tempted to say it may be caused by some AV or other security application.

@trueuto commented on GitHub (Feb 15, 2023): I don't think it has anything to do with Git. I have seen it recently on a PC with no Git installed. I am tempted to say it may be caused by some AV or other security application.

claunia commented

2026-01-31 05:54:49 +00:00

@zoulja commented on GitHub (Feb 15, 2023):

Got the same issue (after opening session focus is on the Tab itself, not on the command line input, so have to click. Pressing Left/Right switches tabs)
But got it only in the recent Preview build and only with sessions in folders/groups.
The same session in the main list (outside of a folder) works well.
All my sessions are SSH ones: "commandline": "ssh somehost"

Any workaround, please?

@zoulja commented on GitHub (Feb 15, 2023): Got the same issue (after opening session focus is on the Tab itself, not on the command line input, so have to click. Pressing Left/Right switches tabs) But got it only in the recent Preview build and only with sessions in folders/groups. The same session in the main list (outside of a folder) works well. All my sessions are SSH ones: `"commandline": "ssh somehost"` Any workaround, please?

claunia commented

2026-01-31 05:54:49 +00:00

@y1rn commented on GitHub (Apr 14, 2023):

same issue on windows 10 for long time.

@y1rn commented on GitHub (Apr 14, 2023): same issue on windows 10 for long time.

claunia commented

2026-01-31 05:54:49 +00:00

@zadjii-msft commented on GitHub (Apr 14, 2023):

Wait so I had a totally random other thought about this.

Again, let's not involve WSL at all in this, because of the aforementioned issues with WSLg stealing focus as it boots up. So only test with Command Prompt or PowerShell tabs (and make sure WSL isn't in your profile.ps1)

Does this repro

on the first launch of the Terminal? OR
does it only repro after opening a new tab?
- and if it only happens when opening a new tab, HOW are you opening the tab?
  - The new tab dropdown?
  - the command palette?
  - the tab context menu?
  - A keybinding?

There's been bugs in the past about focus secretly moving somewhere else in the Terminal app itself. Most recently, #15049. That one's specific to nested dropdown entries (which are new in 1.17), but a helpful reminder that we've had these issues before. ESPECIALLY when opening tabs via the new tab dropdown.

I still haven't had any luck repro'ing this. Maybe for the folks who are seeing this, especially after some delay, can you try https://github.com/JocysCom/FocusLogger? That 3p tool looks like it's exactly what we need to root cause who's stealing the focus here.

Adding a flag to disable #2988 is... complicated, especially considering the way it's all plumbed together. Not impossible, but it'd be very much a "set the house on fire to kill a spider" kinda solution.

edit: Alternatively, if folks want a Small Program for testing this, you could try compiling 8db8bd3ec3/src/tools/scratch/main.cpp. That's a fairly simple program for just logging whatever's in the foreground. Just pop that into a SEPERATE console window, and go about your business until the bug repros.

Edit 2: OR as a powershell script: https://github.com/microsoft/terminal/blob/211f3160a/src/tools/scratch/focus-logger.ps1

@zadjii-msft commented on GitHub (Apr 14, 2023): Wait so I had a totally random other thought about this. Again, let's not involve WSL at all in this, because of the aforementioned issues with WSLg stealing focus as it boots up. So only test with Command Prompt or PowerShell tabs (and make sure WSL isn't in your `profile.ps1`) Does this repro * on the _first launch_ of the Terminal? OR * does it only repro after opening a new tab? * and if it only happens when opening a new tab, HOW are you opening the tab? * The new tab dropdown? * the command palette? * the tab context menu? * A keybinding? There's been bugs in the past about focus secretly moving somewhere else in the Terminal app itself. Most recently, #15049. That one's specific to nested dropdown entries (which are new in 1.17), but a helpful reminder that we've had these issues before. ESPECIALLY when opening tabs via the new tab dropdown. I still haven't had any luck repro'ing this. Maybe for the folks who are seeing this, especially after some delay, can you try **https://github.com/JocysCom/FocusLogger**? That 3p tool looks like it's exactly what we need to root cause who's stealing the focus here. Adding a flag to disable #2988 is... complicated, especially considering the way it's all plumbed together. Not impossible, but it'd be very much a "set the house on fire to kill a spider" kinda solution. edit: Alternatively, if folks want a Small Program for testing this, you could try compiling https://github.com/microsoft/terminal/blob/8db8bd3ec3b1377a265ece8905d5f36b0013ccf1/src/tools/scratch/main.cpp. That's a fairly simple program for just logging whatever's in the foreground. Just pop that into a SEPERATE console window, and go about your business until the bug repros. Edit 2: OR as a powershell script: https://github.com/microsoft/terminal/blob/211f3160a/src/tools/scratch/focus-logger.ps1

claunia commented

2026-01-31 05:54:50 +00:00

@trueuto commented on GitHub (Apr 17, 2023):

Hi @zadjii-msft,

I have used the powershell script referenced above (https://github.com/microsoft/terminal/blob/211f3160a/src/tools/scratch/focus-logger.ps1) for testing.

TL;DR:

I have executed 3 tests, in each case the issue has occurred the same way and in each case the process stealing focus was the shell process of the WT window/tab. This exactly matches to my previous comments on that using other script (https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961) to track focus.

Detailed info

Scenario 1:

Steps:

I have modified settings of my WT for default session to be PowerShell (pwsh). Saved and closed the WT app.
I have opened Windows PowerShell window (non-WT) and started the script.
I have started WT via the Start menu. Once started, I have switched to the VSCode app and stayed there until the issue occurred.
Once it has occurred (visually it was WT window appearing but with NO focus to it), I have clicked to activate the WT window. Then switched back to the PowetShell window to stop the script.

Result:

PS C:\Temp> .\focus-logger.ps1
Current process: powershell
Current process: C:\WINDOWS\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe
Current process: C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\StartMenuExperienceHost.exe
Current process: C:\WINDOWS\Explorer.EXE
Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Get-Process : Cannot bind argument to parameter 'Id' because it is null.
At C:\Temp\focus-logger.ps1:50 char:45
+             $processName = (Get-Process -Id $processId -FileVersionIn ...
+                                             ~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-Process], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand

Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Current process: C:\apps\vscode\Code.exe
Current process: C:\apps\pwsh\pwsh.exe
Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Get-Process : Cannot bind argument to parameter 'Id' because it is null.
At C:\Temp\focus-logger.ps1:50 char:45
+             $processName = (Get-Process -Id $processId -FileVersionIn ...
+                                             ~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-Process], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand

Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Current process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Scenario 2:

Steps:

I have kept the PowerShell (pwsh) as my default session and WT window opened from the previous test.
I have switched to the Windows PowerShell window to start the script.
Switched back to WT to open the new Tab (via Ctrl+T shortcut)
Switched back to VSCode.
Once issue occurred (same manifestation as in Scenario 1), clicked to activate it, switched to PS to stop the script.

Results:

PS C:\Temp> .\focus-logger.ps1
Current process: powershell
Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Get-Process : Cannot bind argument to parameter 'Id' because it is null.
At C:\Temp\focus-logger.ps1:50 char:45
+             $processName = (Get-Process -Id $processId -FileVersionIn ...
+                                             ~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-Process], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand

Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Current process: C:\apps\vscode\Code.exe
Current process: C:\apps\pwsh\pwsh.exe
Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Get-Process : Cannot bind argument to parameter 'Id' because it is null.
At C:\Temp\focus-logger.ps1:50 char:45
+             $processName = (Get-Process -Id $processId -FileVersionIn ...
+                                             ~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-Process], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand

Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Current process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Scenario 3:

Steps:

I have kept the PowerShell (pwsh) as my default session and WT window opened from the previous test.
I have switched to the Windows PowerShell window to start the script.
Started new tab via the drop-down menu.
Switched to VSCode, etc.
Same as above.

Results:

PS C:\Temp> .\focus-logger.ps1
Current process: powershell
Get-Process : Cannot bind argument to parameter 'Id' because it is null.
At C:\Temp\focus-logger.ps1:50 char:45
+             $processName = (Get-Process -Id $processId -FileVersionIn ...
+                                             ~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-Process], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand

Current process: powershell
Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Get-Process : Cannot bind argument to parameter 'Id' because it is null.
At C:\Temp\focus-logger.ps1:50 char:45
+             $processName = (Get-Process -Id $processId -FileVersionIn ...
+                                             ~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-Process], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand

Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Current process: C:\apps\vscode\Code.exe
Current process: C:\apps\pwsh\pwsh.exe
Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Get-Process : Cannot bind argument to parameter 'Id' because it is null.
At C:\Temp\focus-logger.ps1:50 char:45
+             $processName = (Get-Process -Id $processId -FileVersionIn ...
+                                             ~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Get-Process], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand

Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe
Current process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

@trueuto commented on GitHub (Apr 17, 2023): Hi @zadjii-msft, I have used the powershell script referenced above (https://github.com/microsoft/terminal/blob/211f3160a/src/tools/scratch/focus-logger.ps1) for testing. ## TL;DR: I have executed 3 tests, in each case the issue has occurred the same way and in each case the process stealing focus was the shell process of the WT window/tab. This exactly matches to my previous comments on that using other script (https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961) to track focus. ## Detailed info ### Scenario 1: #### Steps: 1. I have modified settings of my WT for default session to be PowerShell (pwsh). Saved and closed the WT app. 2. I have opened Windows PowerShell window (non-WT) and started the script. 3. I have started WT via the Start menu. Once started, I have switched to the VSCode app and stayed there until the issue occurred. 4. Once it has occurred (visually it was WT window appearing but with NO focus to it), I have clicked to activate the WT window. Then switched back to the PowetShell window to stop the script. #### Result: ``` PS C:\Temp> .\focus-logger.ps1 Current process: powershell Current process: C:\WINDOWS\SystemApps\Microsoft.Windows.Search_cw5n1h2txyewy\SearchApp.exe Current process: C:\Windows\SystemApps\Microsoft.Windows.StartMenuExperienceHost_cw5n1h2txyewy\StartMenuExperienceHost.exe Current process: C:\WINDOWS\Explorer.EXE Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Get-Process : Cannot bind argument to parameter 'Id' because it is null. At C:\Temp\focus-logger.ps1:50 char:45 + $processName = (Get-Process -Id $processId -FileVersionIn ... + ~~~~~~~~~~ + CategoryInfo : InvalidData: (:) [Get-Process], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Current process: C:\apps\vscode\Code.exe Current process: C:\apps\pwsh\pwsh.exe Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Get-Process : Cannot bind argument to parameter 'Id' because it is null. At C:\Temp\focus-logger.ps1:50 char:45 + $processName = (Get-Process -Id $processId -FileVersionIn ... + ~~~~~~~~~~ + CategoryInfo : InvalidData: (:) [Get-Process], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Current process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ``` ### Scenario 2: #### Steps: 1. I have kept the PowerShell (pwsh) as my default session and WT window opened from the previous test. 2. I have switched to the Windows PowerShell window to start the script. 3. Switched back to WT to open the new Tab (via Ctrl+T shortcut) 4. Switched back to VSCode. 5. Once issue occurred (same manifestation as in Scenario 1), clicked to activate it, switched to PS to stop the script. #### Results: ``` PS C:\Temp> .\focus-logger.ps1 Current process: powershell Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Get-Process : Cannot bind argument to parameter 'Id' because it is null. At C:\Temp\focus-logger.ps1:50 char:45 + $processName = (Get-Process -Id $processId -FileVersionIn ... + ~~~~~~~~~~ + CategoryInfo : InvalidData: (:) [Get-Process], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Current process: C:\apps\vscode\Code.exe Current process: C:\apps\pwsh\pwsh.exe Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Get-Process : Cannot bind argument to parameter 'Id' because it is null. At C:\Temp\focus-logger.ps1:50 char:45 + $processName = (Get-Process -Id $processId -FileVersionIn ... + ~~~~~~~~~~ + CategoryInfo : InvalidData: (:) [Get-Process], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Current process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ``` ### Scenario 3: #### Steps: 1. I have kept the PowerShell (pwsh) as my default session and WT window opened from the previous test. 2. I have switched to the Windows PowerShell window to start the script. 3. Started new tab via the drop-down menu. 4. Switched to VSCode, etc. 5. Same as above. #### Results: ``` PS C:\Temp> .\focus-logger.ps1 Current process: powershell Get-Process : Cannot bind argument to parameter 'Id' because it is null. At C:\Temp\focus-logger.ps1:50 char:45 + $processName = (Get-Process -Id $processId -FileVersionIn ... + ~~~~~~~~~~ + CategoryInfo : InvalidData: (:) [Get-Process], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand Current process: powershell Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Get-Process : Cannot bind argument to parameter 'Id' because it is null. At C:\Temp\focus-logger.ps1:50 char:45 + $processName = (Get-Process -Id $processId -FileVersionIn ... + ~~~~~~~~~~ + CategoryInfo : InvalidData: (:) [Get-Process], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Current process: C:\apps\vscode\Code.exe Current process: C:\apps\pwsh\pwsh.exe Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Get-Process : Cannot bind argument to parameter 'Id' because it is null. At C:\Temp\focus-logger.ps1:50 char:45 + $processName = (Get-Process -Id $processId -FileVersionIn ... + ~~~~~~~~~~ + CategoryInfo : InvalidData: (:) [Get-Process], ParameterBindingValidationException + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.GetProcessCommand Current process: C:\Program Files\WindowsApps\Microsoft.WindowsTerminalPreview_1.17.10234.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe Current process: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe ```

claunia commented

2026-01-31 05:54:50 +00:00

@tomvoss commented on GitHub (May 4, 2023):

I recently installed Windows Terminal Preview version 1.17.1023 from the Microsoft Store. I proceeded to add some new profiles. I created some where the command line is "%WINDIR%\\System32\\OpenSSH\\ssh.exe user@host". These new profiles launched in new tabs and immediately received focus.

Here's the interesting part: I copied the GUID of one of these profiles to the new newTabMenu section of the settings.json file and put it inside of a folder. When I launched the profile from within the folder the new tab did not receive focus. I reproduced this multiple times. As another test I pressed the tab key after launching the profile from within the folder and the plus sign and down arrow immediately to the right of this new tab became highlighted with a black border around them. This would seem to indicate that after launching a profile from within a folder, the tab title itself is where the focus is rather than within the tab's window/body.

I hope this information can be helpful to someone. I apologize that I did not have time to read through this entire issue to see if this has already been brought up by someone else or if there is another issue with similar information.

@tomvoss commented on GitHub (May 4, 2023): I recently installed Windows Terminal Preview version 1.17.1023 from the Microsoft Store. I proceeded to add some new profiles. I created some where the command line is `"%WINDIR%\\System32\\OpenSSH\\ssh.exe user@host"`. These new profiles launched in new tabs and immediately received focus. Here's the interesting part: I copied the GUID of one of these profiles to the new `newTabMenu` section of the settings.json file and put it inside of a folder. When I launched the profile from within the folder the new tab did not receive focus. I reproduced this multiple times. As another test I pressed the tab key after launching the profile from within the folder and the plus sign and down arrow immediately to the right of this new tab became highlighted with a black border around them. This would seem to indicate that after launching a profile from within a folder, the tab title itself is where the focus is rather than within the tab's window/body. I hope this information can be helpful to someone. I apologize that I did not have time to read through this entire issue to see if this has already been brought up by someone else or if there is another issue with similar information.

claunia commented

2026-01-31 05:54:50 +00:00

@cfbao commented on GitHub (May 25, 2023):

On my company laptop, I'm experiencing almost the exact issue @trueuto described here: https://github.com/microsoft/terminal/issues/13388#issuecomment-1354331077
i.e. New tab then focus switched to the shell process after ~30 seconds. No WSL running (though installed).

Some more details and possible culprit in my specific case:

I noticed that the focus switch is always accompanied by a "Thread Exit" operation as shown by procmon.exe.
This thread is created right when the new tab is created in Windows Terminal. (More specifically it's always after the "Process Create" event for OpenConsole.exe and before the "Process Create" event for the shell process (e.g. cmd.exe or pwsh.exe), but I don't know if this is deterministic)
While the suspect thread is running, I looked it up in procexp.exe - its start address is in C:\Program Files\Avecto\Privilege Guard Client\PGHook.dll and has stack like this

ntoskrnl.exe!KeSynchronizeExecution+0x6c56
ntoskrnl.exe!KeWaitForSingleObject+0x1460
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeWaitForSingleObject+0x233
ntoskrnl.exe!RtlFindClearBitsAndSetEx+0xc7d
ntoskrnl.exe!KiCheckForKernelApcDelivery+0x359
ntoskrnl.exe!KeWaitForSingleObject+0x1787
ntoskrnl.exe!KeWaitForSingleObject+0x98f
ntoskrnl.exe!KeDelayExecutionThread+0x122
ntoskrnl.exe!MmProbeAndLockProcessPages+0x245f
ntoskrnl.exe!setjmpex+0x82d5
ntdll.dll!NtDelayExecution+0x14
KERNELBASE.dll!SleepEx+0x9e
PGHook.dll!PGHookFunction+0x406c1
PGHook.dll!PGHookFunction+0x3a4c3
PGHook.dll!PGHookFunction+0x3ab0e
PGHook.dll!PGHookFunction+0x3aa42
PGHook.dll!PGHookFunction+0x73670
KERNEL32.DLL!BaseThreadInitThunk+0x14
ntdll.dll!RtlUserThreadStart+0x21

"Privilege Guard Client" is part of the BeyondTrust privilege management solution that our IT has deployed recently. It seems a very likely culprit at least in my case. Will talk to our IT for more details.

@cfbao commented on GitHub (May 25, 2023): On my company laptop, I'm experiencing almost the exact issue @trueuto described here: https://github.com/microsoft/terminal/issues/13388#issuecomment-1354331077 i.e. New tab then focus switched to the shell process after ~30 seconds. No WSL running (though installed). Some more details and possible culprit in my specific case: * I noticed that the focus switch is always accompanied by a "Thread Exit" operation as shown by procmon.exe. * This thread is created right when the new tab is created in Windows Terminal. (More specifically it's always after the "Process Create" event for OpenConsole.exe and before the "Process Create" event for the shell process (e.g. cmd.exe or pwsh.exe), but I don't know if this is deterministic) * While the suspect thread is running, I looked it up in procexp.exe - its start address is in `C:\Program Files\Avecto\Privilege Guard Client\PGHook.dll` and has stack like this ``` ntoskrnl.exe!KeSynchronizeExecution+0x6c56 ntoskrnl.exe!KeWaitForSingleObject+0x1460 ntoskrnl.exe!KeWaitForSingleObject+0x98f ntoskrnl.exe!KeWaitForSingleObject+0x233 ntoskrnl.exe!RtlFindClearBitsAndSetEx+0xc7d ntoskrnl.exe!KiCheckForKernelApcDelivery+0x359 ntoskrnl.exe!KeWaitForSingleObject+0x1787 ntoskrnl.exe!KeWaitForSingleObject+0x98f ntoskrnl.exe!KeDelayExecutionThread+0x122 ntoskrnl.exe!MmProbeAndLockProcessPages+0x245f ntoskrnl.exe!setjmpex+0x82d5 ntdll.dll!NtDelayExecution+0x14 KERNELBASE.dll!SleepEx+0x9e PGHook.dll!PGHookFunction+0x406c1 PGHook.dll!PGHookFunction+0x3a4c3 PGHook.dll!PGHookFunction+0x3ab0e PGHook.dll!PGHookFunction+0x3aa42 PGHook.dll!PGHookFunction+0x73670 KERNEL32.DLL!BaseThreadInitThunk+0x14 ntdll.dll!RtlUserThreadStart+0x21 ``` "Privilege Guard Client" is part of the BeyondTrust privilege management solution that our IT has deployed recently. It seems a very likely culprit at least in my case. Will talk to our IT for more details.

claunia commented

@zadjii-msft commented on GitHub (May 25, 2023):

WELL THAT LOOKS LIKE A CULPRIT.

^{I will be so unbelievably annoyed but also relieved if there really was a piece of 3p software that was hijacking this after all}

@zadjii-msft commented on GitHub (May 25, 2023): WELL THAT LOOKS LIKE A CULPRIT. <sup>I will be so unbelievably annoyed but also relieved if there really _was_ a piece of 3p software that was hijacking this after all

claunia commented

@LarsKaulen commented on GitHub (May 25, 2023):

"Privilege Guard Client" is part of the BeyondTrust privilege management solution that our IT has deployed recently. It seems a very likely culprit at least in my case. Will talk to our IT for more details.

I have the same issue and also have "Privilege Guard Client" by Avecto installed on my company laptop.

@LarsKaulen commented on GitHub (May 25, 2023): > "Privilege Guard Client" is part of the BeyondTrust privilege management solution that our IT has deployed recently. It seems a very likely culprit at least in my case. Will talk to our IT for more details. I have the same issue and also have "Privilege Guard Client" by Avecto installed on my company laptop.

claunia commented

Edit: https://support.citrix.com/article/CTX140974/virtual-delivery-agent-installation-with-avecto-privilege-guard

@PennRobotics commented on GitHub (May 25, 2023):

There's a registry value called "HookExclusions" under an "Avecto" key. I can't check personally; I reinstalled Windows on my work computer and the issue is now gone for me… no idea if I had Avecto on the old installation, but it's not on my PC currently.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avecto\Privilege Guard Client

@PennRobotics commented on GitHub (May 25, 2023): There's a registry value called "HookExclusions" under an "Avecto" key. I can't check personally; I reinstalled Windows on my work computer and the issue is now gone for me… no idea if I had Avecto on the old installation, but it's not on my PC currently. Edit: https://support.citrix.com/article/CTX140974/virtual-delivery-agent-installation-with-avecto-privilege-guard `HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Avecto\Privilege Guard Client`

claunia commented

2026-01-31 05:54:52 +00:00

@winni2k commented on GitHub (May 25, 2023):

I also run beyond trust on my machine and have this issue.

On May 25, 2023, "Maxime U. Garcia" @.***> wrote:

I think there's a registry value called "HookExclusions" under an
"Avecto" key. I can't check personally; I reinstalled Windows on my
work computer and the issue is now gone for me… no idea if I had
Avecto on the old installation.

—
Reply to this email directly, view it on GitHub
<https://github.com/microsoft/terminal/issues/13388#issuecomment-
1562983485>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AACKOPQ3IZZ5UIQQN4VJST3XH5SEDANCNFSM5Z6SZ2FQ>.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Sent with HEY https://hey.com/sent

@winni2k commented on GitHub (May 25, 2023): I also run beyond trust on my machine and have this issue. On May 25, 2023, "Maxime U. Garcia" ***@***.***> wrote: > I think there's a registry value called "HookExclusions" under an > "Avecto" key. I can't check personally; I reinstalled Windows on my > work computer and the issue is now gone for me… no idea if I had > Avecto on the old installation. > — Reply to this email directly, view it on GitHub <https://github.com/microsoft/terminal/issues/13388#issuecomment- 1562983485>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AACKOPQ3IZZ5UIQQN4VJST3XH5SEDANCNFSM5Z6SZ2FQ>. You are receiving this because you were mentioned.Message ID: ***@***.***> -- Sent with HEY <https://hey.com/sent>

claunia commented

@DennisGaida commented on GitHub (May 25, 2023):

Fixed in 1.18 for me - no third party Software was interfering, but I am using the new folders (whatever they are called) to start shells.

@DennisGaida commented on GitHub (May 25, 2023): Fixed in 1.18 for me - no third party Software was interfering, but I am using the new folders (whatever they are called) to start shells.

claunia commented

2026-01-31 05:54:52 +00:00

@migue-pki commented on GitHub (May 25, 2023):

I am still experiencing the issue, and I also have the luck of enjoying "Privilege Guard Client" by Avecto in my company laptop thanks to our IT. HookExclusions does not seem to be honored, and ManagedHookExclusions is read-only of course.

@migue-pki commented on GitHub (May 25, 2023): I am still experiencing the issue, and I also have the luck of enjoying "Privilege Guard Client" by Avecto in my company laptop thanks to our IT. `HookExclusions` does not seem to be honored, and `ManagedHookExclusions` is read-only of course.

claunia commented

2026-01-31 05:54:52 +00:00

@migue-pki commented on GitHub (May 25, 2023):

Funnily enough, if I copy WindowsTerminal.exe with a name in the whitelisted programs list stored in ManagedHookExclusions the focus issue no longer happens to that terminal 🤦

@migue-pki commented on GitHub (May 25, 2023): Funnily enough, if I copy `WindowsTerminal.exe` with a name in the whitelisted programs list stored in `ManagedHookExclusions` the focus issue no longer happens to that terminal 🤦

claunia commented

2026-01-31 05:54:53 +00:00

@y1rn commented on GitHub (May 26, 2023):

Funnily enough, if I copy WindowsTerminal.exe with a name in the whitelisted programs list stored in ManagedHookExclusions the focus issue no longer happens to that terminal 🤦

Same situation, I can not edit ManagedHookExclusions myself, Is there other solution?

@y1rn commented on GitHub (May 26, 2023): > Funnily enough, if I copy `WindowsTerminal.exe` with a name in the whitelisted programs list stored in `ManagedHookExclusions` the focus issue no longer happens to that terminal 🤦 Same situation, I can not edit `ManagedHookExclusions` myself, Is there other solution?

claunia commented

2026-01-31 05:54:53 +00:00

@ilyaradko commented on GitHub (May 26, 2023):

WELL THAT LOOKS LIKE A CULPRIT.

I will be so unbelievably annoyed but also relieved if there really was a piece of 3p software that was hijacking this after all

Unfortunately, I cannot confirm the observations. In my case, there is no any antivirus, nor any obvious nasty corporate software (like the abovementioned Avecto) running. In the Process Monitor, I see consistent two ThreadExit events from StartMenuExperienceHost.exe and five ThreadExit from Explorer.exe just before the focus gets stolen. So I believe, there is still something inherent to Windows that causes the issue rather than the 3p software, at least in my case.

@ilyaradko commented on GitHub (May 26, 2023): > WELL THAT LOOKS LIKE A CULPRIT. > > I will be so unbelievably annoyed but also relieved if there really _was_ a piece of 3p software that was hijacking this after all Unfortunately, I cannot confirm the observations. In my case, there is no any antivirus, nor any obvious nasty corporate software (like the abovementioned Avecto) running. In the Process Monitor, I see consistent two ThreadExit events from StartMenuExperienceHost.exe and five ThreadExit from Explorer.exe just before the focus gets stolen. So I believe, there is still something inherent to Windows that causes the issue rather than the 3p software, at least in my case.

claunia commented

2026-01-31 05:54:54 +00:00

@trueuto commented on GitHub (May 26, 2023):

@ilyaradko - what is the Windows version you run? Is it Win10 22H2 already?

It may be good to find out if Win version may be the common denominator here too.

@trueuto commented on GitHub (May 26, 2023): @ilyaradko - what is the Windows version you run? Is it Win10 22H2 already? It may be good to find out if Win version may be the common denominator here too.

claunia commented

2026-01-31 05:54:54 +00:00

@ilyaradko commented on GitHub (May 26, 2023):

@trueuto, yes, Win10 22H2, Terminal version 1.16.10261.0.

@ilyaradko commented on GitHub (May 26, 2023): @trueuto, yes, Win10 22H2, Terminal version 1.16.10261.0.

claunia commented

2026-01-31 05:54:55 +00:00

@lbise commented on GitHub (May 26, 2023):

I can confirm that my company also use BeyondTrust Privilege Management tool.

@lbise commented on GitHub (May 26, 2023): I can confirm that my company also use BeyondTrust Privilege Management tool.

claunia commented

2026-01-31 05:54:55 +00:00

@neilrees commented on GitHub (Jun 16, 2023):

Another report of repro'ing the issue and we also have Avecto BeyondTrust Privilege Management deployed.

@neilrees commented on GitHub (Jun 16, 2023): Another report of repro'ing the issue and we also have Avecto BeyondTrust Privilege Management deployed.

claunia commented

2026-01-31 05:54:55 +00:00

@joelnb commented on GitHub (Jun 16, 2023):

I also have BeyondTrust Privilege Management on the work laptop where I experience this. Plus I work at the same company as @praimmugen so it's very likely they had the same software installed at the time of opening the original issue.

@joelnb commented on GitHub (Jun 16, 2023): I also have BeyondTrust Privilege Management on the work laptop where I experience this. Plus I work at the same company as @praimmugen so it's very likely they had the same software installed at the time of opening the original issue.

claunia commented

@zoulja commented on GitHub (Jun 16, 2023):

I don't have BeyondTrust Privilege Management installed, but still affected by focus issue

@zoulja commented on GitHub (Jun 16, 2023): I don't have BeyondTrust Privilege Management installed, but still affected by focus issue

claunia commented

@saenzfco commented on GitHub (Jun 20, 2023):

@zoulja do you have another type of privilege management software on your computer? I don't have BeyondTrust, but I have CyberArk and I get the same behavior when creating new tabs.

@saenzfco commented on GitHub (Jun 20, 2023): @zoulja do you have another type of privilege management software on your computer? I don't have BeyondTrust, but I have CyberArk and I get the same behavior when creating new tabs.

claunia commented

@trueuto commented on GitHub (Jun 20, 2023):

With all signs of the issue being caused by BeyondTrust (but possibly by some other software too), @zadjii-msft - is there anything you could make to do things you do differently? I know it is not your "fault", but I hardly can imagine these companies making any exceptions or amendments to their software just to make WT users happy...

@trueuto commented on GitHub (Jun 20, 2023): With all signs of the issue being caused by BeyondTrust (but possibly by some other software too), @zadjii-msft - is there anything you could make to do things you do differently? I know it is not your "fault", but I hardly can imagine these companies making any exceptions or amendments to their software just to make WT users happy...

claunia commented

2026-01-31 05:54:57 +00:00

@zoulja commented on GitHub (Jun 20, 2023):

@zoulja do you have another type of privilege management software on your computer? I don't have BeyondTrust, but I have CyberArk and I get the same behavior when creating new tabs.

Nope, this is my home laptop, without any corporate software, just default Win11 setup @saenzfco

@zoulja commented on GitHub (Jun 20, 2023): > @zoulja do you have another type of privilege management software on your computer? I don't have BeyondTrust, but I have CyberArk and I get the same behavior when creating new tabs. Nope, this is my home laptop, without any corporate software, just default Win11 setup @saenzfco

claunia commented

@smanning commented on GitHub (Jun 20, 2023):

I have the issue on my corporate laptop that uses BeyondTrust.

@smanning commented on GitHub (Jun 20, 2023): I have the issue on my corporate laptop that uses BeyondTrust.

claunia commented

2026-01-31 05:54:57 +00:00

@MetaFight commented on GitHub (Jun 28, 2023):

It happens for me on my personal windows 10 laptop with no corporate sniffing/security software running.
It doesn't seem to happen with cmd.exe tabs, but it does happen with Ubuntu tabs AFTER I've issued wsl --shutdown elsewhere... So maybe it's a timing issue related to the slower startup when wsl needs to start up?

I can repro this consistently by running wsl --shutdown and then opening a new Ubuntu tab. The tab will open and then Terminal visibly loses focus when the bash prompt appears.

I'm running version 1.17.11461.0 in quake mode, if that helps.

@MetaFight commented on GitHub (Jun 28, 2023): It happens for me on my personal windows 10 laptop with no corporate sniffing/security software running. It doesn't seem to happen with cmd.exe tabs, but it does happen with Ubuntu tabs AFTER I've issued `wsl --shutdown` elsewhere... So maybe it's a timing issue related to the slower startup when wsl needs to start up? I can repro this consistently by running `wsl --shutdown` and then opening a new Ubuntu tab. The tab will open and then Terminal visibly loses focus when the bash prompt appears. I'm running version 1.17.11461.0 in quake mode, if that helps.

claunia commented

2026-01-31 05:54:58 +00:00

@ryanmda commented on GitHub (Aug 2, 2023):

Re-posting from my duplicate issue #15786

Okay, I did some version testing.

Version 1.13 works perfectly. Never loses focus to a hidden window
Version 1.14 loses focus once immediately on startup, but not with new tabs. This is the behaviour described at the start of #13388
Versions 1.15 through 1.18 preview all manifest the behaviour on #15786; every new tab loses focus to a hidden window after about 30 seconds

@ryanmda commented on GitHub (Aug 2, 2023): Re-posting from my duplicate issue #15786 Okay, I did some version testing. Version 1.13 works perfectly. Never loses focus to a hidden window Version 1.14 loses focus once immediately on startup, but not with new tabs. This is the behaviour described at the start of #13388 Versions 1.15 through 1.18 preview all manifest the behaviour on #15786; every new tab loses focus to a hidden window after about 30 seconds

claunia commented

2026-01-31 05:54:58 +00:00

@ilyaradko commented on GitHub (Aug 2, 2023):

I rolled back to version v1.13.1143 and can confirm that the issue is absent. Will stick to this version then. Thanks a lot, @ryanmda, for posting your test results!

@ilyaradko commented on GitHub (Aug 2, 2023): I rolled back to version [v1.13.1143](https://github.com/microsoft/terminal/releases/tag/v1.13.11431.0) and can confirm that the issue is absent. Will stick to this version then. Thanks a lot, @ryanmda, for posting your test results!

claunia commented

2026-01-31 05:54:58 +00:00

@Anutrix commented on GitHub (Aug 2, 2023):

After v1.13.11431.0 - Stable v1.13 comes:
v1.14.1432.0
v1.14.1451.0 - This ticket's OP.
v1.14.1861.0 - Stable v1.14.

v1.15.186
v1.15.200
v1.15.228
v1.15.252 - Stable v1.15.

Note: Skipped service releases.
Just a list for those who want to test the versions one by one.
If we can get exact versions where each of the issues started maybe we can bisect it to two commits. I don't see any other way forward for this year-old issue.

Personal Note: I have stopped seeing this issue since few weeks/months now so I can't debug it myself. Hence, the list for others. I am on 1.17.11461.0.

@Anutrix commented on GitHub (Aug 2, 2023): After [v1.13.11431.0](https://github.com/microsoft/terminal/releases/tag/v1.13.11431.0) - Stable v1.13 comes: [v1.14.1432.0](https://github.com/microsoft/terminal/releases/tag/v1.14.1432.0) [v1.14.1451.0](https://github.com/microsoft/terminal/releases/tag/v1.14.1451.0) - This ticket's OP. [v1.14.1861.0](https://github.com/microsoft/terminal/releases/tag/v1.14.1861.0) - Stable v1.14. [v1.15.186](https://github.com/microsoft/terminal/releases/tag/v1.15.1862.0) [v1.15.200](https://github.com/microsoft/terminal/releases/tag/v1.15.2002.0) [v1.15.228](https://github.com/microsoft/terminal/releases/tag/v1.15.2282.0) [v1.15.252](https://github.com/microsoft/terminal/releases/tag/v1.15.2524.0) - Stable v1.15. Note: Skipped service releases. Just a list for those who want to test the versions one by one. If we can get exact versions where each of the issues started maybe we can bisect it to two commits. I don't see any other way forward for this year-old issue. Personal Note: I have stopped seeing this issue since few weeks/months now so I can't debug it myself. Hence, the list for others. I am on 1.17.11461.0.

claunia commented

2026-01-31 05:54:59 +00:00

@zadjii-msft commented on GitHub (Aug 2, 2023):

I mean, I'm 100% certain it's one of the #2988 commits¹. Those are the ones that introduced the pseudo-hwnd (that's seemingly getting troubled here). Problem is, that's a pretty major compatibility feature that we definitely can't just revert. And there's not a simple opt-out, as I once thought there might be².

I don't have any ideas as to what we could do to mitigate this. I'd need to get someone to do a kernel trace with PGHook loaded to see exactly what they're calling. I wouldn't think that a 30s Sleep, even at the start of OpenConsole's launch, would affect the path I'm thinking of, but user32 is dark and full of terrors. I'd suspect that this wouldn't apply to "defterm" launches³. Though, if they're hooking OpenConsole.exe, then... wouldn't that just hang all defterm console launches by 30s? That seems... insane.

Those commits being:
- #12515, (the most likely culprit)
- #12526,
- #12799,
- #12899,
- Symbolic links created in additional panes/tabs don't work (#12900)
↩︎
I previously thought it'd be possible to just pass a flag to conpty to disable creating the pseudo-hwnd (and revert to the old behavior). There was some reason I thought that would end up being Hard to do, though I can't remember why now. ↩︎
where you launch cmd.exe and that boots into a Terminal window instead of a conhost one. That's available on Windows 11 and newer Windows 10 builds ↩︎

@zadjii-msft commented on GitHub (Aug 2, 2023): I mean, I'm 100% certain it's one of the #2988 commits[^1]. Those are the ones that introduced the pseudo-hwnd (that's seemingly getting troubled here). Problem is, that's a pretty major compatibility feature that we definitely can't just revert. And there's not a simple opt-out, as I once thought there might be[^2]. I don't have any ideas as to what we could do to mitigate this. I'd need to get someone to do a kernel trace _with_ PGHook loaded to see exactly what they're calling. I wouldn't think that a 30s `Sleep`, even at the start of `OpenConsole`'s launch, would affect the path I'm thinking of, but user32 is dark and full of terrors. I'd suspect that this wouldn't apply to "defterm" launches[^3]. Though, if they're hooking OpenConsole.exe, then... wouldn't that just hang all defterm console launches by 30s? That seems... insane. [^1]: Those commits being: * #12515, (the most likely culprit) * #12526, * #12799, * #12899, * #12900 [^2]: I previously thought it'd be possible to just pass a flag to conpty to disable creating the pseudo-hwnd (and revert to the old behavior). There was some reason I thought that would end up being **H**ard to do, though I can't remember why now. [^3]: where you launch `cmd.exe` and that boots into a Terminal window instead of a conhost one. That's available on Windows 11 and [newer Windows 10 builds](https://github.com/microsoft/terminal/discussions/15505)

claunia commented

2026-01-31 05:54:59 +00:00

@winni2k commented on GitHub (Aug 3, 2023):

I thought I'd post that this got fixed for me a few weeks back. I assume
it was a windows update of some kind. I tried to post at the time but
the comments seemed to have been disabled.

@winni2k commented on GitHub (Aug 3, 2023): I thought I'd post that this got fixed for me a few weeks back. I assume it was a windows update of some kind. I tried to post at the time but the comments seemed to have been disabled.

claunia commented

2026-01-31 05:54:59 +00:00

@trueuto commented on GitHub (Aug 17, 2023):

I mean, I'm 100% certain it's one of the #2988 commits1. Those are the ones that introduced the pseudo-hwnd (that's seemingly getting troubled here). Problem is, that's a pretty major compatibility feature that we definitely can't just revert. And there's not a simple opt-out, as I once thought there might be2.

I don't have any ideas as to what we could do to mitigate this. I'd need to get someone to do a kernel trace with PGHook loaded to see exactly what they're calling. I wouldn't think that a 30s Sleep, even at the start of OpenConsole's launch, would affect the path I'm thinking of, but user32 is dark and full of terrors. I'd suspect that this wouldn't apply to "defterm" launches3. Though, if they're hooking OpenConsole.exe, then... wouldn't that just hang all defterm console launches by 30s? That seems... insane.

That may be a dead-end, but at some point 1.16.3463.0 release has changed the behaviour: from instant focus loss to a delayed one, by approx. 30 seconds. It was about when I initially thought the issue was completely gone. So, even if 1.16.3463.0 did not fix it, there was some change that seems to have impact on the problem by introducing that delay...

@trueuto commented on GitHub (Aug 17, 2023): > I mean, I'm 100% certain it's one of the #2988 commits[1](#user-content-fn-1-3c35df30e5cea17508632d1c8cee1591). Those are the ones that introduced the pseudo-hwnd (that's seemingly getting troubled here). Problem is, that's a pretty major compatibility feature that we definitely can't just revert. And there's not a simple opt-out, as I once thought there might be[2](#user-content-fn-2-3c35df30e5cea17508632d1c8cee1591). > > I don't have any ideas as to what we could do to mitigate this. I'd need to get someone to do a kernel trace _with_ PGHook loaded to see exactly what they're calling. I wouldn't think that a 30s `Sleep`, even at the start of `OpenConsole`'s launch, would affect the path I'm thinking of, but user32 is dark and full of terrors. I'd suspect that this wouldn't apply to "defterm" launches[3](#user-content-fn-3-3c35df30e5cea17508632d1c8cee1591). Though, if they're hooking OpenConsole.exe, then... wouldn't that just hang all defterm console launches by 30s? That seems... insane. That may be a dead-end, but at some point 1.16.3463.0 release has changed the behaviour: from instant focus loss to a delayed one, by approx. 30 seconds. It was about when I initially thought the issue was completely gone. So, even if 1.16.3463.0 did not fix it, there was some change that seems to have impact on the problem by introducing that delay...

claunia commented

2026-01-31 05:55:00 +00:00

@winni2k commented on GitHub (Aug 17, 2023):

I also see a random focus loss every now and then. 30 seconds send about
right.

On August 17, 2023, "Maxime U. Garcia" @.***> wrote:

I mean, I'm 100% certain it's one of the #2988
https://github.com/microsoft/terminal/issues/2988 commits1 <#user-
content-fn-1-3c35df30e5cea17508632d1c8cee1591>. Those are the ones
that introduced the pseudo-hwnd (that's seemingly getting troubled
here). Problem is, that's a pretty major compatibility feature that
we definitely can't just revert. And there's not a simple opt-out,
as I once thought there might be2 <#user-content-fn-2-
3c35df30e5cea17508632d1c8cee1591>.

I don't have any ideas as to what we could do to mitigate this. I'd
need to get someone to do a kernel trace with PGHook loaded to see
exactly what they're calling. I wouldn't think that a 30s Sleep,
even at the start of OpenConsole's launch, would affect the path I'm
thinking of, but user32 is dark and full of terrors. I'd suspect
that this wouldn't apply to "defterm" launches3 <#user-content-fn-3-
3c35df30e5cea17508632d1c8cee1591>. Though, if they're hooking
OpenConsole.exe, then... wouldn't that just hang all defterm console
launches by 30s? That seems... insane.

That may be a dead-end, but at some point 1.16.3463.0 release has
changed the behaviour: from instant focus loss to a delayed one, by
approx. 30 seconds. It was about when I initially thought the issue
was completely gone. So, even if 1.16.3463.0 did not fix it, there was
some change that seems to have impact on the problem by introducing
that delay...

—
Reply to this email directly, view it on GitHub
<https://github.com/microsoft/terminal/issues/13388#issuecomment-
1681817862>, or unsubscribe
<https://github.com/notifications/unsubscribe-
auth/AACKOPQGRPHWPLMRV3GYDI3XVXFMPANCNFSM5Z6SZ2FQ>.
You are receiving this because you were mentioned.Message ID:
@.***>

--
Sent with HEY https://hey.com/sent

@winni2k commented on GitHub (Aug 17, 2023): I also see a random focus loss every now and then. 30 seconds send about right. On August 17, 2023, "Maxime U. Garcia" ***@***.***> wrote: > > I mean, I'm 100% certain it's one of the #2988 > > <https://github.com/microsoft/terminal/issues/2988> commits1 <#user- > > content-fn-1-3c35df30e5cea17508632d1c8cee1591>. Those are the ones > > that introduced the pseudo-hwnd (that's seemingly getting troubled > > here). Problem is, that's a pretty major compatibility feature that > > we definitely can't just revert. And there's not a simple opt-out, > > as I once thought there might be2 <#user-content-fn-2- > > 3c35df30e5cea17508632d1c8cee1591>. > > > > I don't have any ideas as to what we could do to mitigate this. I'd > > need to get someone to do a kernel trace with PGHook loaded to see > > exactly what they're calling. I wouldn't think that a 30s Sleep, > > even at the start of OpenConsole's launch, would affect the path I'm > > thinking of, but user32 is dark and full of terrors. I'd suspect > > that this wouldn't apply to "defterm" launches3 <#user-content-fn-3- > > 3c35df30e5cea17508632d1c8cee1591>. Though, if they're hooking > > OpenConsole.exe, then... wouldn't that just hang all defterm console > > launches by 30s? That seems... insane. > > > > That may be a dead-end, but at some point 1.16.3463.0 release has > changed the behaviour: from instant focus loss to a delayed one, by > approx. 30 seconds. It was about when I initially thought the issue > was completely gone. So, even if 1.16.3463.0 did not fix it, there was > some change that seems to have impact on the problem by introducing > that delay... > — Reply to this email directly, view it on GitHub <https://github.com/microsoft/terminal/issues/13388#issuecomment- 1681817862>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AACKOPQGRPHWPLMRV3GYDI3XVXFMPANCNFSM5Z6SZ2FQ>. You are receiving this because you were mentioned.Message ID: ***@***.***> -- Sent with HEY <https://hey.com/sent>

claunia commented

2026-01-31 05:55:00 +00:00

@trueuto commented on GitHub (Aug 17, 2023):

I also see a random focus loss every now and then. 30 seconds send about right.

To be precise: in my case focus is only lost once per each new WT tab/window. In other words, if I start a new tab, focus gets stolen after 30 seconds, but then it does not re-occur until new WT tab/window is started.

@trueuto commented on GitHub (Aug 17, 2023): > I also see a random focus loss every now and then. 30 seconds send about right. To be precise: in my case focus is only lost once per each new WT tab/window. In other words, if I start a new tab, focus gets stolen after 30 seconds, but then it does not re-occur until new WT tab/window is started.

claunia commented

2026-01-31 05:55:00 +00:00

@tomhallertech commented on GitHub (Sep 25, 2023):

I also lose focus in WSL constantlly. I have RSI and depend on using keyboard rather than mouse, and I can't even alt-tab to get the focus back - I have to actually click in the window, otherwise it's completely inaccessible. This is incredibly annoying. I would be using Linux on bare metal, not Windows at all, but my client thinks it's more secure to require all access to their systems to be via buggy vulnerable crappy software that just gets in the way of productivity. Please fix!

@tomhallertech commented on GitHub (Sep 25, 2023): I also lose focus in WSL constantlly. I have RSI and depend on using keyboard rather than mouse, and I can't even alt-tab to get the focus back - I have to actually click in the window, otherwise it's completely inaccessible. This is incredibly annoying. I would be using Linux on bare metal, not Windows at all, but my client thinks it's more secure to require all access to their systems to be via buggy vulnerable crappy software that just gets in the way of productivity. Please fix!

claunia commented

2026-01-31 05:55:01 +00:00

@prlcutting commented on GitHub (Sep 25, 2023):

I'm running 1.17.11461.0, and also regularly experiencing a loss of focus in the window. It's quite frustrating. My company also uses Beyond Trust.

@prlcutting commented on GitHub (Sep 25, 2023): I'm running `1.17.11461.0`, and also regularly experiencing a loss of focus in the window. It's quite frustrating. My company also uses Beyond Trust.

claunia commented

2026-01-31 05:55:01 +00:00

@tomhallertech commented on GitHub (Sep 26, 2023):

I'm also running Windows Terminal 1.17.11461.0, and have Beyond Trust, on Windows 10 Enterprise 22H2 Build 19045.3448. 30 seconds after I open a WSL tab, focus is lost. Other application windows are unaffected, I can alt-tab to them and type. But pressing tab or alt-tab does not regain focus in the WSL tab, only a mouse click will do. The same thing happens when I open a Powershell or Command Prompt tab. It also happens if I close all WSL tabs, execute "wsl --shutdown" in a command prompt, then open a Command Prompt or Powershell tab in Windows Terminal - focus is lost after 30 seconds and only a mouse click can restore. So problem seems to be with Windows Terminal, not WSL.

It's unclear from above comments whether this is necessarily to do with Beyond Trust. I can say however that I only experience this with Windows Terminal, no other application is similarly affected. In my normal workflow I open and close many WSL tabs, and I avoid using the mouse due to RSI, so this is both a usability and accessibility issue.

@tomhallertech commented on GitHub (Sep 26, 2023): I'm also running Windows Terminal 1.17.11461.0, and have Beyond Trust, on Windows 10 Enterprise 22H2 Build 19045.3448. 30 seconds after I open a WSL tab, focus is lost. Other application windows are unaffected, I can alt-tab to them and type. But pressing tab or alt-tab does not regain focus in the WSL tab, only a mouse click will do. The same thing happens when I open a Powershell or Command Prompt tab. It also happens if I close all WSL tabs, execute "wsl --shutdown" in a command prompt, then open a Command Prompt or Powershell tab in Windows Terminal - focus is lost after 30 seconds and only a mouse click can restore. So problem seems to be with Windows Terminal, not WSL. It's unclear from above comments whether this is necessarily to do with Beyond Trust. I can say however that I only experience this with Windows Terminal, no other application is similarly affected. In my normal workflow I open and close many WSL tabs, and I avoid using the mouse due to RSI, so this is both a usability and accessibility issue.

claunia commented

2026-01-31 05:55:01 +00:00

@ashpika40 commented on GitHub (Oct 3, 2023):

Yeah, I have been having this problem for a while as well. I've just updated to version 1.18.2681.0, but still see this problem. I do have BeyondTrust installed. For people who don't want to use a mouse to regain focus, you can do an ALT+F4 when it loses focus. This way you can close the invisible box and the focus automatically regains on to the most recent terminal you are working on.

@ashpika40 commented on GitHub (Oct 3, 2023): Yeah, I have been having this problem for a while as well. I've just updated to version 1.18.2681.0, but still see this problem. I do have BeyondTrust installed. For people who don't want to use a mouse to regain focus, you can do an ALT+F4 when it loses focus. This way you can close the invisible box and the focus automatically regains on to the most recent terminal you are working on.

claunia commented

2026-01-31 05:55:02 +00:00

@zoulja commented on GitHub (Oct 4, 2023):

Dear Windows Terminal developers, this is really really really annoying bug, and it's actually so surprisingly that MS releases applications with such seriuos and obvious issues (I hope it's not some single person pet project), so please please please fix it 🙏

@zoulja commented on GitHub (Oct 4, 2023): Dear Windows Terminal developers, this is really really really annoying bug, and it's actually so surprisingly that MS releases applications with such seriuos and obvious issues (I hope it's not some single person pet project), so please please please fix it 🙏

claunia commented

@tomhallertech commented on GitHub (Oct 5, 2023):

Thank you, ashpika40, the ALT-F4 trick is brilliant!
My solution now is to open one instance of WT with WSL running in one tab, start tmux and use that for running multiple sessions, splitting windows into panes, etc. For a keyboard-centric user like me this works much better, and you can use the same skills outside of Windows, in pure Linux, ssh sessions, etc etc. I could even do the same thing in cmd.exe, but colors and fonts are nicer in WT.

@tomhallertech commented on GitHub (Oct 5, 2023): Thank you, ashpika40, the ALT-F4 trick is brilliant! My solution now is to open one instance of WT with WSL running in one tab, start tmux and use that for running multiple sessions, splitting windows into panes, etc. For a keyboard-centric user like me this works much better, and you can use the same skills outside of Windows, in pure Linux, ssh sessions, etc etc. I could even do the same thing in cmd.exe, but colors and fonts are nicer in WT.

claunia commented

@MrStrik3 commented on GitHub (Oct 5, 2023):

I would also like to add : if I open a new Windows Terminal tab or window, and quickly put the focus on a different application like Firefox, after a few seconds the application will lose its focus. The focus is brought to some kind of invisible tab in Windows Terminal

(I also have BeyondTrust, it might be related or a coincidence)

Thanks for looking into this problem, it's very appreciated!

@MrStrik3 commented on GitHub (Oct 5, 2023): I would also like to add : if I open a new Windows Terminal tab or window, and quickly put the focus on a different application like Firefox, after a few seconds the application will lose its focus. The focus is brought to some kind of invisible tab in Windows Terminal (I also have BeyondTrust, it might be related or a coincidence) Thanks for looking into this problem, it's very appreciated!

claunia commented

@NinoDLC commented on GitHub (Nov 25, 2023):

Same problem here, also when commiting with Git.

I commit with Git from the terminal : git commit
It launches Sublim Text (because of some Git config), I type my commit message, save and close the Sublim Text window
Terminal is focused but my tab isn't, I can't type anything until I clicked inside the tab

@NinoDLC commented on GitHub (Nov 25, 2023): Same problem here, also when commiting with Git. - I commit with Git from the terminal : `git commit` - It launches Sublim Text (because of some Git config), I type my commit message, save and close the Sublim Text window - Terminal is focused but my tab isn't, I can't type anything until I clicked inside the tab

claunia commented

2026-01-31 05:55:04 +00:00

@zoulja commented on GitHub (Dec 11, 2023):

Any update on this, dear sirs?

@zoulja commented on GitHub (Dec 11, 2023): Any update on this, dear sirs?

claunia commented

@ilyaradko commented on GitHub (Dec 11, 2023):

@zoulja Yes. Someone should open a bug ticket at BeyondTrust :) They are actually aware that their Privilege Manager does not behave good with some software and constantly fixing it. Unless someone opens a bug ticket, they will not be aware of this misbehavior with WT.

@ilyaradko commented on GitHub (Dec 11, 2023): @zoulja Yes. Someone should open a bug ticket at BeyondTrust :) They are actually aware that their Privilege Manager does not behave good with some software and constantly fixing it. Unless someone opens a bug ticket, they will not be aware of this misbehavior with WT.

claunia commented

2026-01-31 05:55:04 +00:00

@gsmalleus commented on GitHub (Dec 11, 2023):

I too am experiencing this behavior, but we do not utilize BeyondTrust.

If launched via a pinned Task Bar icon, the window opens but does not have focus for input without clicking.
If I launch it via the Start Menu, the window opens behind other open applications.

@gsmalleus commented on GitHub (Dec 11, 2023): I too am experiencing this behavior, but we do not utilize BeyondTrust. If launched via a pinned Task Bar icon, the window opens but does not have focus for input without clicking. If I launch it via the Start Menu, the window opens behind other open applications.

claunia commented

2026-01-31 05:55:05 +00:00

@zoulja commented on GitHub (Dec 12, 2023):

@zoulja Yes. Someone should open a bug ticket at BeyondTrust :)

@ilyaradko I'm facing this bug on my home laptop and I don't have BeyondTrust installed, so actually no need to wait for someone to make it fixed. It's obviously a regression which was introduced a few versions ago

@zoulja commented on GitHub (Dec 12, 2023): > @zoulja Yes. Someone should open a bug ticket at BeyondTrust :) @ilyaradko I'm facing this bug on my home laptop and I don't have BeyondTrust installed, so actually no need to wait for someone to make it fixed. It's obviously a regression which was introduced a few versions ago

claunia commented

2026-01-31 05:55:05 +00:00

@rwasef1830 commented on GitHub (Dec 12, 2023):

I am facing this since few weeks ago, I am not using BeyondTrust, but I am using other software that perform injection techniques such as StartAllBack and Proxifier. I am on Windows 11.

Is there any low-level "who's asking for focus" tool to run so I can collect useful logs to add here ?

@rwasef1830 commented on GitHub (Dec 12, 2023): I am facing this since few weeks ago, I am not using BeyondTrust, but I am using other software that perform injection techniques such as StartAllBack and Proxifier. I am on Windows 11. Is there any low-level "who's asking for focus" tool to run so I can collect useful logs to add here ?

claunia commented

2026-01-31 05:55:05 +00:00

@trueuto commented on GitHub (Dec 12, 2023):

@rwasef1830 there were a couple possibilities mentioned earlier. You may want to refer to the following posts:

https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961
https://github.com/microsoft/terminal/issues/13388#issuecomment-1387106227
https://github.com/microsoft/terminal/issues/13388#issuecomment-1508701817
https://github.com/microsoft/terminal/issues/13388#issuecomment-1510915244

@trueuto commented on GitHub (Dec 12, 2023): @rwasef1830 there were a couple possibilities mentioned earlier. You may want to refer to the following posts: https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961 https://github.com/microsoft/terminal/issues/13388#issuecomment-1387106227 https://github.com/microsoft/terminal/issues/13388#issuecomment-1508701817 https://github.com/microsoft/terminal/issues/13388#issuecomment-1510915244

claunia commented

2026-01-31 05:55:06 +00:00

@zoulja commented on GitHub (Feb 27, 2024):

Still suffering of it in 1.20 Preview

@zoulja commented on GitHub (Feb 27, 2024): Still suffering of it in 1.20 Preview

claunia commented

2026-01-31 05:55:06 +00:00

@inglepriyanka148867 commented on GitHub (Apr 16, 2024):

To fix the issue where you can't type in new panes or tabs until manually clicking, check terminal emulator settings, tmux configuration, and shell settings for any conflicts or misconfigurations. Test with default settings, debug, and submit a fix if necessary.

@inglepriyanka148867 commented on GitHub (Apr 16, 2024): To fix the issue where you can't type in new panes or tabs until manually clicking, check terminal emulator settings, tmux configuration, and shell settings for any conflicts or misconfigurations. Test with default settings, debug, and submit a fix if necessary.

claunia commented

2026-01-31 05:55:06 +00:00

@inglepriyanka148867 commented on GitHub (Apr 16, 2024):

Check Keyboard Focus Settings:
Sometimes, this issue can occur due to keyboard focus settings or accessibility settings. Make sure your keyboard settings are configured correctly.
Restart Windows Terminal:
Close Windows Terminal completely and reopen it. Sometimes, restarting the application can resolve temporary issues like this.
Check for Updates: Ensure that you're using the latest version of Windows Terminal. Older versions may have bugs or issues that have been fixed in newer releases.
Reset Windows Terminal Settings: If the issue persists, you can try resetting Windows Terminal settings to their defaults. This can often resolve configuration-related issues.
Check for Conflicting Software: Sometimes, conflicts with other software can cause issues with keyboard input. Make sure there are no conflicting applications or background processes interfering with Windows Terminal.

If none of these steps resolve the issue, you may need to further investigate or seek assistance from Microsoft support or community forums for Windows Terminal users.

@inglepriyanka148867 commented on GitHub (Apr 16, 2024): 1. Check Keyboard Focus Settings: Sometimes, this issue can occur due to keyboard focus settings or accessibility settings. Make sure your keyboard settings are configured correctly. 2. Restart Windows Terminal: Close Windows Terminal completely and reopen it. Sometimes, restarting the application can resolve temporary issues like this. 3. Check for Updates: Ensure that you're using the latest version of Windows Terminal. Older versions may have bugs or issues that have been fixed in newer releases. 4. Reset Windows Terminal Settings: If the issue persists, you can try resetting Windows Terminal settings to their defaults. This can often resolve configuration-related issues. 5. Check for Conflicting Software: Sometimes, conflicts with other software can cause issues with keyboard input. Make sure there are no conflicting applications or background processes interfering with Windows Terminal. If none of these steps resolve the issue, you may need to further investigate or seek assistance from Microsoft support or community forums for Windows Terminal users.

claunia commented

2026-01-31 05:55:07 +00:00

@Delphier commented on GitHub (May 6, 2024):

1.19.11213, Windows 11 this issue still exists.

@Delphier commented on GitHub (May 6, 2024): 1.19.11213, Windows 11 this issue still exists.

claunia commented

2026-01-31 05:55:07 +00:00

@MichaelMcCoyTech commented on GitHub (May 9, 2024):

Is anyone ever going to fix this issue. It is infuriating.

@MichaelMcCoyTech commented on GitHub (May 9, 2024): Is anyone ever going to fix this issue. It is infuriating.

claunia commented

2026-01-31 05:55:07 +00:00

@wiz0u commented on GitHub (May 9, 2024):

Yeah, Terminal is basically unusable with Visual Studio console programs unless this is fixed. You don't want to need a mouse click when you run/debug your program with F5, before typing things in the console.

@wiz0u commented on GitHub (May 9, 2024): Yeah, Terminal is basically unusable with Visual Studio console programs unless this is fixed. You don't want to need a mouse click when you run/debug your program with F5, before typing things in the console.

claunia commented

2026-01-31 05:55:08 +00:00

@asineth0 commented on GitHub (May 15, 2024):

I'm not sure why #13640 was closed since it is still an issue that happens on the latest version. This isn't the same issue either, but it was closed as a duplicate anyway by someone who's GH account has been deleted.

TL;DR: can we re-open #13640?

@asineth0 commented on GitHub (May 15, 2024): I'm not sure why #13640 was closed since it is still an issue that happens on the latest version. This isn't the same issue either, but it was closed as a duplicate anyway by someone who's GH account has been deleted. TL;DR: can we re-open #13640?

claunia commented

2026-01-31 05:55:08 +00:00

@trueuto commented on GitHub (Jun 27, 2024):

🎂 With a 2nd anniversary of this bug I wish everyone a quick breakthrough! It's been a pain in the neck for all users as well as developers as they are trying to fix something caused by the 3rd party apps in fact.

These words are primarily aimed at you, @zadjii-msft - I hope this will be solved soon and you can forget about that once and for all and focus on some other, most likely much more interesting work!

And thanks for all the efforts to have it sorted out!

@trueuto commented on GitHub (Jun 27, 2024): 🎂 With a 2nd anniversary of this bug I wish everyone a quick breakthrough! It's been a pain in the neck for all users as well as developers as they are trying to fix something caused by the 3rd party apps in fact. These words are primarily aimed at you, @zadjii-msft - I hope this will be solved soon and you can forget about that once and for all and focus on some other, most likely much more interesting work! And thanks for all the efforts to have it sorted out!

claunia commented

2026-01-31 05:55:08 +00:00

@george-tsiros commented on GitHub (Jul 7, 2024):

Visual studio, start debugging console prog.
Terminal is configured to not use tabbed documents.
If another Terminal window is already open, new window is created unfocused.
If new window is the only Terminal window, it is focused.

@george-tsiros commented on GitHub (Jul 7, 2024): Visual studio, start debugging console prog. Terminal is configured to _not_ use tabbed documents. If another Terminal window is _already open_, new window is created unfocused. If new window is the _only_ Terminal window, it is focused.

claunia commented

2026-01-31 05:55:09 +00:00

@MichaelMcCoyTech commented on GitHub (Jul 7, 2024):

Please fix this. It is infuriating and causes me lots of failed logins etc. As you can never rely on terminal retaining focus as you are typing.

@MichaelMcCoyTech commented on GitHub (Jul 7, 2024): Please fix this. It is infuriating and causes me lots of failed logins etc. As you can never rely on terminal retaining focus as you are typing.

claunia commented

2026-01-31 05:55:09 +00:00

@Lionela26 commented on GitHub (Jul 12, 2024):

Windows Terminal version

1.14.1451.0

Windows build number

10.0.19042.0

Other Software

No response

Steps to reproduce

Create new pane/new tab

Expected Behavior

It is possible to type in the newly opened terminal

Actual Behavior

Unable to type until I click on the new terminal.

Note that enabling the option "Automatically focus pane on mouse hover" partially prevents the issue from happening.

It seems like focus is removed from all terminal tabs/panes whenever a new one is created.

@Lionela26 commented on GitHub (Jul 12, 2024): > ### Windows Terminal version > > 1.14.1451.0 > > ### Windows build number > > 10.0.19042.0 > > ### Other Software > > _No response_ > > ### Steps to reproduce > > Create new pane/new tab > > ### Expected Behavior > > It is possible to type in the newly opened terminal > > ### Actual Behavior > > Unable to type until I click on the new terminal. > > Note that enabling the option "Automatically focus pane on mouse hover" partially prevents the issue from happening. > > It seems like focus is removed from all terminal tabs/panes whenever a new one is created.

claunia commented

2026-01-31 05:55:09 +00:00

@justineakehurst commented on GitHub (Aug 1, 2024):

At it appears this is an interaction between Windows Terminal (reproducible with 1.20.11781.0) and BeyondTrust (reproducible with BeyondTrust Client version 23.9.225.0, PMC adapter 23.9.578) on Windows 11 Enterprise (10.0.22621 Build 22621), is it possible that the Terminal team can assemble an equivalent environment to get a repro, and work with BeyondTrust dev team to determine what might be going on here and find a solution?

@justineakehurst commented on GitHub (Aug 1, 2024): At it appears this is an interaction between Windows Terminal (reproducible with 1.20.11781.0) and BeyondTrust (reproducible with BeyondTrust Client version 23.9.225.0, PMC adapter 23.9.578) on Windows 11 Enterprise (10.0.22621 Build 22621), is it possible that the Terminal team can assemble an equivalent environment to get a repro, and work with BeyondTrust dev team to determine what might be going on here and find a solution?

claunia commented

@NinoDLC commented on GitHub (Aug 1, 2024):

I don't have BeyondTrust, I don't have any shitty bloatware installed, I even reformatted my computer since I had this issue, and it's still there, on a fresh windows 11 install. The only "exotic" stuff I have installed is WSL 2.0

@NinoDLC commented on GitHub (Aug 1, 2024): I don't have BeyondTrust, I don't have any shitty bloatware installed, I even reformatted my computer since I had this issue, and it's still there, on a fresh windows 11 install. The only "exotic" stuff I have installed is WSL 2.0

claunia commented

@zoulja commented on GitHub (Aug 27, 2024):

Still not fixed in the latest Preview build ☹️
Now it's clear this app is cursed

@zoulja commented on GitHub (Aug 27, 2024): Still not fixed in the latest Preview build ☹️ Now it's clear this app is cursed

claunia commented

@zadjii-msft commented on GitHub (Aug 29, 2024):

@NinoDLC FWIW there's a known issue in WSLg that causes the wslg interop to steal focus from the terminal whenever WSL starts up. This thread is specifically for the mysterious sources of focus being lost that don't involve WSL spawning.
Go see:
https://github.com/microsoft/wslg/issues/998
(et al)

@zadjii-msft commented on GitHub (Aug 29, 2024): @NinoDLC FWIW there's a known issue in WSLg that causes the wslg interop to steal focus from the terminal whenever WSL starts up. This thread is specifically for the mysterious sources of focus being lost that _don't_ involve WSL spawning. Go see: https://github.com/microsoft/wslg/issues/998 (et al)

claunia commented

2026-01-31 05:55:11 +00:00

@zadjii-msft commented on GitHub (Aug 29, 2024):

We merged in a fix that we think is tangential to this problem over in #17828 just today. It should be in this evening's Canary build. Tomorrow, could someone who was seeing the non-WSL focus lost issue test out Canary with a version greater than 1.23.2391.0? That might help us see if this fixed it or not.

You can grab terminal canary from https://aka.ms/terminal-canary-installer

(we'll all be out for the long weekend, so I won't actually know the next canary's build number till like Tuesday)

@zadjii-msft commented on GitHub (Aug 29, 2024): We merged in a fix that we think is tangential to this problem over in #17828 just today. It should be in this evening's Canary build. Tomorrow, could someone who was seeing the **_non_-WSL** focus lost issue test out Canary with a version greater than `1.23.2391.0`? That might help us see if this fixed it or not. You can grab terminal canary from https://aka.ms/terminal-canary-installer (we'll all be out for the long weekend, so I won't actually know the next canary's build number till like Tuesday)

claunia commented

@ashpika40 commented on GitHub (Aug 29, 2024):

I'd be happy to. Will do it tomorrow.

@ashpika40 commented on GitHub (Aug 29, 2024): I'd be happy to. Will do it tomorrow.

claunia commented

2026-01-31 05:55:11 +00:00

@trueuto commented on GitHub (Aug 30, 2024):

I have just tested the Canary version (1.23.2421.0) and it looks very good! 🎉

There STILL IS some focus loss, but it is very short (blink of an eye, literally) and focus immediately returns back to the WT. If that temporary focus loss is long enough to interfere with input - this I cannot tell. But definitely there is a great step forward! 💪

The temporary focus loss is manifested by the mouse cursor re-appearing on the screen (after it has disappeared on keyboard input) and if you use e.g. a red window background for inactive WT window - you can see it blink. This happens ~30 seconds after WT launch/new tab opened too.

@trueuto commented on GitHub (Aug 30, 2024): I have just tested the Canary version (1.23.2421.0) **and it looks very good!** 🎉 There **STILL IS** some focus loss, but it is very short (blink of an eye, literally) and focus immediately returns back to the WT. If that temporary focus loss is long enough to interfere with input - this I cannot tell. But definitely there is a great step forward! 💪 The temporary focus loss is manifested by the mouse cursor re-appearing on the screen (after it has disappeared on keyboard input) and if you use e.g. a red window background for inactive WT window - you can see it blink. This happens ~30 seconds after WT launch/new tab opened too.

claunia commented

2026-01-31 05:55:11 +00:00

@zadjii-msft commented on GitHub (Aug 30, 2024):

I'm super glad to hear it!

There STILL IS some focus loss, but it is very short ...

The temporary focus loss is manifested by the mouse cursor re-appearing on the screen (after it has disappeared on keyboard input) and if you use e.g. a red window background for inactive WT window - you can see it blink. This happens ~30 seconds after WT launch/new tab opened too.

That sounds telltale like some other application is opening for an imperceivable amount of time, then immediately closing. We basically found a slower version of this that involved a git MSAL authentication prompt. That was a clearer example to trace of "another window appears briefly, then closes itself". I doubt whatever is spawning on your machine is an MSAL prompt, but I bet the side effects are similar.

We probably won't be able to do anything about that <1s gap where another window opens into the FG and steals focus, but this at least feels like it'll no longer be blocking for folks.

@zadjii-msft commented on GitHub (Aug 30, 2024): I'm super glad to hear it! > There **STILL IS** some focus loss, but it is very short ... > > The temporary focus loss is manifested by the mouse cursor re-appearing on the screen (after it has disappeared on keyboard input) and if you use e.g. a red window background for inactive WT window - you can see it blink. This happens ~30 seconds after WT launch/new tab opened too. That sounds telltale like some other application is opening for an imperceivable amount of time, then immediately closing. We basically found a slower version of this that involved a git MSAL authentication prompt. That was a clearer example to trace of "another window appears briefly, then closes itself". I doubt whatever is spawning on your machine is an MSAL prompt, but I bet the side effects are similar. We probably won't be able to do anything about that <1s gap where another window opens into the FG and steals focus, but this at least feels like it'll no longer be blocking for folks.

claunia commented

@trueuto commented on GitHub (Aug 30, 2024):

I will check it again with the script to detect focus-thief used in the past and let you know.

@trueuto commented on GitHub (Aug 30, 2024): I will check it again with the script to detect focus-thief used in the past and let you know.

claunia commented

@trueuto commented on GitHub (Aug 30, 2024):

Tested with script from https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961

[08/30/2024 13:53:48] Starting WT...
[08/30/2024 13:53:48] ...done
[08/30/2024 13:53:48] Current WT handle: 1118350
[08/30/2024 13:53:48] Current WT process: 8828 / 29892
[08/30/2024 13:53:48] Wating for focus issue to occur.
[08/30/2024 13:53:48] Got new window handle (3409258) after 00:00:00.5859006 - New process: PID: 12252 / TID: 16208 / Name: WindowsTerminal
[08/30/2024 13:54:21] Got new window handle (462284) after 00:00:32.8106372 - New process: PID: 18348 / TID: 13912 / Name: pwsh
[08/30/2024 13:54:21] Got new window handle (3409258) after 00:00:00.0176991 - New process: PID: 12252 / TID: 16208 / Name: WindowsTerminal

It seems it is the same story, where the focus is lost for the shell process that was started in the WT (pwsh in this case), but that happens for much <1s as can be seen above and focus goes immediately back to the WT itself.

@trueuto commented on GitHub (Aug 30, 2024): Tested with script from https://github.com/microsoft/terminal/issues/13388#issuecomment-1357415961 ``` [08/30/2024 13:53:48] Starting WT... [08/30/2024 13:53:48] ...done [08/30/2024 13:53:48] Current WT handle: 1118350 [08/30/2024 13:53:48] Current WT process: 8828 / 29892 [08/30/2024 13:53:48] Wating for focus issue to occur. [08/30/2024 13:53:48] Got new window handle (3409258) after 00:00:00.5859006 - New process: PID: 12252 / TID: 16208 / Name: WindowsTerminal [08/30/2024 13:54:21] Got new window handle (462284) after 00:00:32.8106372 - New process: PID: 18348 / TID: 13912 / Name: pwsh [08/30/2024 13:54:21] Got new window handle (3409258) after 00:00:00.0176991 - New process: PID: 12252 / TID: 16208 / Name: WindowsTerminal ``` It seems it is the same story, where the focus is lost for the shell process that was started in the WT (pwsh in this case), but that happens for much <1s as can be seen above and focus goes immediately back to the WT itself.

claunia commented

@lhecker commented on GitHub (Aug 30, 2024):

That back-and-forth focus tossing is exactly what I was hoping to address with #17829. We'll probably merge that next week and see if that fixes the remaining issues.

@lhecker commented on GitHub (Aug 30, 2024): That back-and-forth focus tossing is exactly what I was hoping to address with #17829. We'll probably merge that next week and see if that fixes the remaining issues.

claunia commented

2026-01-31 05:55:13 +00:00

@japurcell commented on GitHub (Aug 30, 2024):

In my case, Terminal works just fine until I open the Outlook Office 365 Client. I can navigate panes using keyboard shortcuts like Alt + Up / Down but can't select with mouse. Toolbar buttons are also disabled. When I close Outlook, it works just fine again. I also tried the Canary release mentioned above with the same results. I'm using the Outlook web client as a workaround.

OS Name:                   Microsoft Windows 11 Enterprise
OS Version:                10.0.22631 N/A Build 22631

@japurcell commented on GitHub (Aug 30, 2024): In my case, Terminal works just fine until I open the Outlook Office 365 Client. I can navigate panes using keyboard shortcuts like `Alt + Up / Down` but can't select with mouse. Toolbar buttons are also disabled. When I close Outlook, it works just fine again. I also tried the Canary release mentioned above with the same results. I'm using the Outlook web client as a workaround. ``` OS Name: Microsoft Windows 11 Enterprise OS Version: 10.0.22631 N/A Build 22631 ```

claunia commented

@jgilles commented on GitHub (Aug 30, 2024):

I just tested the canary build and it is certainly a large improvement.
Focus does appear to be lost still (the mouse cursor becomes suddenly
visible), but it returns automatically now where before it would not return
without clicking on the terminal. Ideally focus wouldn't be lost at
all...but this is better -- continuing to type hides the mouse cursor again
and no clicking is needed.

Some noteworthy info:

I am in a corporate environment, running Windows 11 Enterprise 22H2
BeyondTrust Privilege Management is installed
In both Terminal builds (canary and 1.20.11781.0) focus is lost
approximately 35 seconds after opening a new tab
I can type characters one at a time, approximately one second apart and
focus is always lost after 35 seconds or so.
I was not using WSL at the time, just launching a new tab running git bash.

Thank you for working on this issue, it is maddening!

On Fri, Aug 30, 2024 at 8:01 AM Adam Purcell @.***>
wrote:

In my case, Terminal works just fine until I open the Outlook Office 365
Client. I can navigate panes using keyboard shortcuts like Alt + Up / Down
but can't select with mouse. Toolbar buttons are also disabled. When I
close Outlook, it works just fine again. I also tried the Canary release
mentioned above with the same results. I'm using the Outlook web client as
a workaround.

OS Name: Microsoft Windows 11 Enterprise
OS Version: 10.0.22631 N/A Build 22631

—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/13388#issuecomment-2321179155,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEVIQPEHMTTUT6VW77N2GDZUBUKRAVCNFSM5Z6SZ2F2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZSGEYTOOJRGU2Q
.
You are receiving this because you are subscribed to this thread.Message
ID: @.***>

@jgilles commented on GitHub (Aug 30, 2024): I just tested the canary build and it is certainly a large improvement. Focus does appear to be lost still (the mouse cursor becomes suddenly visible), but it returns automatically now where before it would not return without clicking on the terminal. Ideally focus wouldn't be lost at all...but this is better -- continuing to type hides the mouse cursor again and no clicking is needed. Some noteworthy info: I am in a corporate environment, running Windows 11 Enterprise 22H2 BeyondTrust Privilege Management is installed In both Terminal builds (canary and 1.20.11781.0) focus is lost approximately 35 seconds after opening a new tab I can type characters one at a time, approximately one second apart and focus is always lost after 35 seconds or so. I was not using WSL at the time, just launching a new tab running git bash. Thank you for working on this issue, it is maddening! On Fri, Aug 30, 2024 at 8:01 AM Adam Purcell ***@***.***> wrote: > In my case, Terminal works just fine until I open the Outlook Office 365 > Client. I can navigate panes using keyboard shortcuts like Alt + Up / Down > but can't select with mouse. Toolbar buttons are also disabled. When I > close Outlook, it works just fine again. I also tried the Canary release > mentioned above with the same results. I'm using the Outlook web client as > a workaround. > > OS Name: Microsoft Windows 11 Enterprise > OS Version: 10.0.22631 N/A Build 22631 > > — > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/13388#issuecomment-2321179155>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAEVIQPEHMTTUT6VW77N2GDZUBUKRAVCNFSM5Z6SZ2F2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZSGEYTOOJRGU2Q> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.***> >

claunia commented

2026-01-31 05:55:13 +00:00

@ashpika40 commented on GitHub (Aug 30, 2024):

It works. It still loses focus for a split second and comes back. If you keep typing when this happens you might loose a character, Other than that, excellent job. Finally, I will shift to Terminal completely . Tested on win 10 enterprise 22H2 with beyondTrust and using gitbash for testing

@ashpika40 commented on GitHub (Aug 30, 2024): It works. It still loses focus for a split second and comes back. If you keep typing when this happens you might loose a character, Other than that, excellent job. Finally, I will shift to Terminal completely . Tested on win 10 enterprise 22H2 with beyondTrust and using gitbash for testing

claunia commented

2026-01-31 05:55:13 +00:00

@trueuto commented on GitHub (Oct 1, 2024):

We were happy a bit too soon - there's another scenario we did not test: start Windows Terminal (or a new tab), switch to some other application and wait. This time WT steals focus and all the input goes to the WT console. Which is dangerous (e.g. when typing password, or the "rm -rf /foo/bar" command in the other window or app).

See the output from the PowerShell script (already used in the previous comments) below. Test steps taken - with the script started in the stand-alone Windows PowerShell window, i.e.: not in WT:

Launched script which spawns new WT tab/windows/process.
At 09:34:01 I have manually switched the application focus to Firefox (with a mouse-click directly on the Firefox window)
At 09:34:29 WindowsTerminal steals the focus completely.
At 09:34:34 I have manually switched the application focus back to Firefox.

[10/01/2024 09:33:55] Starting WT...
[10/01/2024 09:33:55] ...done
[10/01/2024 09:33:55] Current WT handle: xxxx
[10/01/2024 09:33:55] Current WT process: xxxx / xxxx
[10/01/2024 09:33:55] Wating for focus issue to occur.
[10/01/2024 09:34:01] Got new window handle (0) after 00:00:05.7594232 - New process: PID: 0 / TID: 0 / Name: Idle
[10/01/2024 09:34:01] Got new window handle (396212) after 00:00:00.0368753 - New process: PID: 13056 / TID: 22520 / Name: firefox
[10/01/2024 09:34:29] Got new window handle (593880) after 00:00:28.3067264 - New process: PID: 25360 / TID: 26136 / Name: WindowsTerminal
[10/01/2024 09:34:34] Got new window handle (0) after 00:00:05.2914857 - New process: PID: 0 / TID: 0 / Name: Idle
[10/01/2024 09:34:34] Got new window handle (396212) after 00:00:00.0331324 - New process: PID: 13056 / TID: 22520 / Name: firefox

Unfortunately this new behaviour is even more annoying (and dangerous) than the old one...

EDIT: The initial WT handle and process provided above do not refer to WT; they were for the standalone PowerShell window. I have removed (xxxx) them not to cause confusion.

@trueuto commented on GitHub (Oct 1, 2024): We were happy a bit too soon - there's another scenario we did not test: start Windows Terminal (or a new tab), switch to some other application and wait. This time WT **steals focus** and all the input goes to the WT console. Which is dangerous (e.g. when typing password, or the "rm -rf /foo/bar" command in the other window or app). See the output from the PowerShell script (already used in the previous comments) below. Test steps taken - with the script started in the stand-alone Windows PowerShell window, i.e.: not in WT: 1. Launched script which spawns new WT tab/windows/process. 2. At 09:34:01 I have manually switched the application focus to Firefox (with a mouse-click directly on the Firefox window) 3. At 09:34:29 WindowsTerminal steals the focus completely. 4. At 09:34:34 I have manually switched the application focus back to Firefox. ``` [10/01/2024 09:33:55] Starting WT... [10/01/2024 09:33:55] ...done [10/01/2024 09:33:55] Current WT handle: xxxx [10/01/2024 09:33:55] Current WT process: xxxx / xxxx [10/01/2024 09:33:55] Wating for focus issue to occur. [10/01/2024 09:34:01] Got new window handle (0) after 00:00:05.7594232 - New process: PID: 0 / TID: 0 / Name: Idle [10/01/2024 09:34:01] Got new window handle (396212) after 00:00:00.0368753 - New process: PID: 13056 / TID: 22520 / Name: firefox [10/01/2024 09:34:29] Got new window handle (593880) after 00:00:28.3067264 - New process: PID: 25360 / TID: 26136 / Name: WindowsTerminal [10/01/2024 09:34:34] Got new window handle (0) after 00:00:05.2914857 - New process: PID: 0 / TID: 0 / Name: Idle [10/01/2024 09:34:34] Got new window handle (396212) after 00:00:00.0331324 - New process: PID: 13056 / TID: 22520 / Name: firefox ``` Unfortunately this new behaviour is even more annoying (and dangerous) than the old one... **EDIT:** The initial WT handle and process provided above do **not** refer to WT; they were for the standalone PowerShell window. I have removed (xxxx) them not to cause confusion.

claunia commented

@P300pl commented on GitHub (Nov 1, 2024):

Windows Terminal version

1.14.1451.0

Windows build number

10.0.19042.0

Other Software

No response

Steps to reproduce

Create new pane/new tab

Expected Behavior

It is possible to type in the newly opened terminal

Actual Behavior

Unable to type until I click on the new terminal.

Note that enabling the option "Automatically focus pane on mouse hover" partially prevents the issue from happening.

It seems like focus is removed from all terminal tabs/panes whenever a new one is created.

@P300pl commented on GitHub (Nov 1, 2024): > ### Windows Terminal version > 1.14.1451.0 > > ### Windows build number > 10.0.19042.0 > > ### Other Software > _No response_ > > ### Steps to reproduce > Create new pane/new tab > > ### Expected Behavior > It is possible to type in the newly opened terminal > > ### Actual Behavior > Unable to type until I click on the new terminal. > > Note that enabling the option "Automatically focus pane on mouse hover" partially prevents the issue from happening. > > It seems like focus is removed from all terminal tabs/panes whenever a new one is created.

claunia commented

@trueuto commented on GitHub (Nov 16, 2024):

On Windows 11 I can still observe the focus theft with the latest WT (~~1.21.2911.0~~ 1.21.3231)

@trueuto commented on GitHub (Nov 16, 2024): On Windows 11 I can still observe the focus theft with the latest WT (~~1.21.2911.0~~ 1.21.3231)

claunia commented

@trueuto commented on GitHub (Nov 21, 2024):

@zadjii-msft - shall the previous behaviour of focus loss be ~~reverted~~ restored for the sake of security? The current one of focus theft seems really bad, far worse than the previous one. And IMHO more annoying too.

@trueuto commented on GitHub (Nov 21, 2024): @zadjii-msft - shall the previous behaviour of focus loss be ~~reverted~~ restored for the sake of security? The current one of focus theft seems really bad, far worse than the previous one. And IMHO more annoying too.

claunia commented