&#34;Attach to the most recently used window&#34; not working in preview #23537

@vefatica commented on GitHub (Sep 30, 2025):

What about this? I upgraded to 1.23.2681.0 and 1.24.2682.0 yesterday. Still -w 0 works in an elevated release version and not in an elevated preview version.

@vefatica commented on GitHub (Sep 30, 2025): What about this? I upgraded to 1.23.2681.0 and 1.24.2682.0 yesterday. Still `-w 0` works in an elevated release version and not in an elevated preview version.

claunia commented

@vefatica commented on GitHub (Oct 5, 2025):

I know more about this and I have a workaround for my original problem. But I don't fully understand what's happening. Further comments will be welcomed.

Reminders: I have these.

TCC 35.00.21 x64 (d:\tc35\tcc.exe)
Microsoft Windows 10 Pro for Workstations
10.0.19045.6332 (2009, 22H2)
WindowsTerminal 1.23.2509.25001 (1.23.2681.0)
WindowsTerminal 1.24.2509.25002 (preview) (1.24.2682.0)

And I have a SHELLEX.EXE, a wrapper for ShellExecuteEx. It's used below in its simplest form, with the default verb and the name of an executable.

I usually start WTP with an AutoHotKey key alias which runs c:\windows\system32\schtasks.exe /run /tn wtelevated.

The wtelevated task is on-demand with highest privileges and has the action d:\wtp\windowsterminal.exe. This avoids the UAC prompt. Run this way, neither wtp -w 0 sp nor d:\wtp\windowsterminal.exe -w 0 sp works later; they cause a new instance/window.

Edit: When those -w 0 commands fail, they are issued to an elevated shell in an elavated WTP.

If I change the action of the task to u:\shellex.exe d:\wtp\windowsterminal.exe, both of those -w 0 commands work later.

This is different from the behavior when, instead of a scheduled task, I start wtp from the Run dialog (Win+R), elevated (Ctrl+Shift+Enter), specifying d:\wtp\windowsterminal.exe and dismissing the UAC prompt; neither -w 0 command works later. That difference (task vs. Run dialog) surprises me.

WT (non-preview) behaves the same.

As I said, I don't fully understand what's happening. A (wild) guess is that it has something to do with message filtering. When the -w 0 commands work, the 0 instance receives WM_USER messages; when the -w 0 commands don't work, it doesn't receive those messages.

Edit: Those failing -w 0 commands are issued in an elevated shell in an elevated WTP.

@vefatica commented on GitHub (Oct 5, 2025): I know more about this and I have a workaround for my original problem. But I don't fully understand what's happening. Further comments will be welcomed. Reminders: I have these. ``` TCC 35.00.21 x64 (d:\tc35\tcc.exe) Microsoft Windows 10 Pro for Workstations 10.0.19045.6332 (2009, 22H2) WindowsTerminal 1.23.2509.25001 (1.23.2681.0) WindowsTerminal 1.24.2509.25002 (preview) (1.24.2682.0) ``` And I have a SHELLEX.EXE, a wrapper for ShellExecuteEx. It's used below in its simplest form, with the default verb and the name of an executable. I usually start WTP with an AutoHotKey key alias which runs `c:\windows\system32\schtasks.exe /run /tn wtelevated`. The wtelevated task is on-demand with highest privileges and has the action `d:\wtp\windowsterminal.exe`. This avoids the UAC prompt. Run this way, neither `wtp -w 0 sp` nor `d:\wtp\windowsterminal.exe -w 0 sp` works later; they cause a new instance/window. Edit: When those `-w 0` commands fail, they are issued to an elevated shell in an elavated WTP. If I change the action of the task to `u:\shellex.exe d:\wtp\windowsterminal.exe`, both of those `-w 0` commands work later. This is different from the behavior when, instead of a scheduled task, I start wtp from the Run dialog (Win+R), elevated (Ctrl+Shift+Enter), specifying `d:\wtp\windowsterminal.exe` and dismissing the UAC prompt; neither `-w 0` command works later. That difference (task vs. Run dialog) surprises me. WT (non-preview) behaves the same. As I said, I don't fully understand what's happening. A (wild) guess is that it has something to do with message filtering. When the `-w 0` commands work, the 0 instance receives WM_USER messages; when the `-w 0` commands don't work, it doesn't receive those messages. Edit: Those failing `-w 0` commands are issued in an elevated shell in an elevated WTP.

claunia commented

@DHowett commented on GitHub (Oct 6, 2025):

I can't believe we didn't think of this! When we weren't able to reproduce your issue, we should have assumed that when you said "elevated" you meant "launched as admin in possibly the most cracked way possible¹." 🙂

Anyway.

It looks like task scheduler starts the original instance of Terminal inside a job object. I am not certain we can support that.

Just like the time you were setting environment variables by injecting a DLL into Explorer rather than writing them to the registry like a normal person... ↩︎

@DHowett commented on GitHub (Oct 6, 2025): I can't believe we didn't think of this! When we weren't able to reproduce your issue, we should have assumed that when you said "elevated" you meant "launched as admin in possibly the most cracked way possible[^1]." 🙂 Anyway. It looks like task scheduler starts the original instance of Terminal inside a job object. I am not certain we can support that. [^1]: Just like the time you were setting environment variables by injecting a DLL into Explorer rather than writing them to the registry like a normal person...

claunia commented

@vefatica commented on GitHub (Oct 6, 2025):

... and the new instance can't communicate with the 0 instance because the 0 instance is inside the job object but if my SHELLEX.EXE (in a job object) starts WT, that new WT (not in a job object???) can communicate with the 0 instance?

I don't fully understand but my immediate problem is solved.

Is it a message filtering issue?

@vefatica commented on GitHub (Oct 6, 2025): ... and the new instance can't communicate with the 0 instance because the 0 instance is inside the job object but if my SHELLEX.EXE (in a job object) starts WT, that new WT (not in a job object???) can communicate with the 0 instance? I don't fully understand but my immediate problem is solved. Is it a message filtering issue?

claunia commented

@DHowett commented on GitHub (Oct 6, 2025):

I don't know why the one in the job can't receive WM_COPYDATA from the one outside it.

Yes, ShellExecute works around this issue by making the shell launch Terminal in whatever way the shell usually launches applications. It breaks away from the job by asking somebody else to do the heavy lifting. :)

@DHowett commented on GitHub (Oct 6, 2025): I don't know why the one in the job can't receive `WM_COPYDATA` from the one outside it. Yes, `ShellExecute` works around this issue by making the shell launch Terminal in whatever way the shell usually launches applications. It breaks away from the job by asking somebody else to do the heavy lifting. :)

claunia commented

@DHowett commented on GitHub (Oct 6, 2025):

Oh, you know what? The issue is much dumber and much simpler than that.

We use the module handle filename to make sure our "portable" mode instances are unique, so we don't try to send nt or other commands to versions of Terminal running out of other folders.

Task Scheduler uses the canonicalized path to your application.

We don't.

You can launch "N" different instances of Terminal that cannot talk to eachother simply by varying the capitalization with which you refer to them, or the directories they're in.

e.g. C:\Programs\terminal-1.23\WindowsTerminal.exe will be considered distinct from C:\PrOgRaMs\terminal-1.23\WindowsTerminal.exe.

We should probably be better about that.

@DHowett commented on GitHub (Oct 6, 2025): Oh, you know what? The issue is much dumber and much simpler than that. We use the module handle filename to make sure our "portable" mode instances are unique, so we don't try to send `nt` or other commands to versions of Terminal running out of other folders. Task Scheduler uses the canonicalized path to your application. We don't. You can launch "N" different instances of Terminal that cannot talk to eachother simply by varying the capitalization with which you refer to them, or the directories they're in. _e.g._ `C:\Programs\terminal-1.23\WindowsTerminal.exe` will be considered distinct from `C:\PrOgRaMs\terminal-1.23\WindowsTerminal.exe`. We should probably be better about that.

claunia commented

@vefatica commented on GitHub (Oct 6, 2025):

As I said more than once, I don't understand. After lots of testing I still don't have a good idea of when -w 0 will work if the 0 instance is elevated. It's not just tasks and the Run dialog. If I start WT elevated from an Explorer window (context menu, Run as administrator) then -w 0 sp elevated from the Run dialog doesn't work.

To your last post, I thought I was consistently using the same WT. Are you saying these are different?

v:\> dir /k /m /f d:\wtp\wi*.exe
D:\wtp\WindowsTerminal.exe

v:\> which wtp
wtp is an external (App Path HKLM): d:\wtp\windowsterminal.exe

@vefatica commented on GitHub (Oct 6, 2025): As I said more than once, I don't understand. After lots of testing I still don't have a good idea of when -w 0 will work if the 0 instance is elevated. It's not just tasks and the Run dialog. If I start WT elevated from an Explorer window (context menu, Run as administrator) then `-w 0 sp` elevated from the Run dialog doesn't work. To your last post, I thought I was consistently using the same WT. Are you saying these are different? ``` v:\> dir /k /m /f d:\wtp\wi*.exe D:\wtp\WindowsTerminal.exe v:\> which wtp wtp is an external (App Path HKLM): d:\wtp\windowsterminal.exe ```

claunia commented

@DHowett commented on GitHub (Oct 6, 2025):

Yes, I am saying they are different. Look at the casing. Then re-read the part of my message about "varying the capitalization."

@DHowett commented on GitHub (Oct 6, 2025): Yes, I am saying they are different. Look at the casing. Then re-read the part of my message about "varying the capitalization."

claunia commented

@vefatica commented on GitHub (Oct 6, 2025):

Yes, I see. These do different things. Does that have anything to do with WSL compatibility?

v:\> d:\wtp\windowsterminal.exe -w 0 sp

v:\> d:\WTP\windowsterminal.exe -w 0 sp

@vefatica commented on GitHub (Oct 6, 2025): Yes, I see. These do different things. Does that have anything to do with WSL compatibility? ``` v:\> d:\wtp\windowsterminal.exe -w 0 sp v:\> d:\WTP\windowsterminal.exe -w 0 sp ```

claunia commented

@DHowett commented on GitHub (Oct 6, 2025):

Nope. Just a bug.

When you use Windows Terminal via the MSIX installation method, Windows makes sure that (1) there is only one and (2) it has a durable identity.

When you use Terminal portable or unpackaged, we can't make either of those guarantees.

The reason we need these guarantees is to prevent two different versions from talking to eachother. So that they can have different "namespaces", and wt nt works on every individual installed copy of Terminal.

To give portable and unpackaged versions single-instancing and "identity," we use the path to the currently-running WindowsTerminal.exe as reported by Windows (from inside the process, by calling GetModuleFilenameW).

It turns out that this function returns the literal capitalization used to spawn the process. Not exactly because of case sensitivity, mind you... probably just because it was easiest to store that in the Process Environment Block. :)

@DHowett commented on GitHub (Oct 6, 2025): Nope. Just a bug. When you use Windows Terminal via the MSIX installation method, Windows makes sure that (1) there is only one and (2) it has a durable identity. When you use Terminal portable or unpackaged, we can't make _either_ of those guarantees. The reason we need these guarantees is to prevent two different versions from talking to eachother. So that they can have different "namespaces", and `wt nt` works on every individual installed copy of Terminal. To give portable and unpackaged versions single-instancing and "identity," we use the path to the currently-running WindowsTerminal.exe _as reported by Windows_ (from inside the process, by calling `GetModuleFilenameW`). It turns out that this function returns the literal capitalization used to spawn the process. Not exactly because of case sensitivity, mind you... probably just because it was easiest to store that in the Process Environment Block. :)

claunia commented

@DHowett commented on GitHub (Oct 6, 2025):

Out for review in #19415. The day after it merges, you should be able to test it out in the Canary channel. Thanks for the report!

@DHowett commented on GitHub (Oct 6, 2025): Out for review in #19415. The day after it merges, you should be able to test it out in the Canary channel. Thanks for the report!

claunia commented

@vefatica commented on GitHub (Oct 6, 2025):

I have never used the canary channel. If it's as easy as unzipping to where I want it, I'll try it. Please get me started on using the canary channel; I have no clue what or where it is.

Never mind. I figured it out.

@vefatica commented on GitHub (Oct 6, 2025): I have never used the canary channel. If it's as easy as unzipping to where I want it, I'll try it. Please get me started on using the canary channel; I have no clue what or where it is. Never mind. I figured it out.

claunia commented