starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

"Attach to the most recently used window on this desktop" continues to open in instance on other desktop #22989

New Issue
Closed
opened 2026-01-31 08:29:17 +00:00 by claunia · 18 comments
claunia commented 2026-01-31 08:29:17 +00:00
Owner
Copy Link

Originally created by @rkhoury on GitHub (Mar 5, 2025).

Windows Terminal version

1.24.250228001-llm

Windows build number

10.0.26100

Other Software

No response

Steps to reproduce

  1. Modify the Startup setting New instance behavior and set the value to Attach to the most recently used window on this desktop
  2. Create a new Terminal (or Terminal Preview) instance on Desktop 1.
  3. Create a new Terminal instance on Desktop 2 - for me this changes desktops and launches the instance on Desktop 1.

Note (implied): my Terminal desktop settings are not set to "Show windows from this app on all desktops" so I can attempt to keep terminal instances aligned with particular work streams.

Reproduces in release build 1.23.10353.0 or canary build version 1.24.250228001-llm

Expected Behavior

When on a new desktop I expect a new instance of Terminal (or Terminal Preview) to create a new window and attach to that.

Actual Behavior

Assuming an instance of Terminal is already running on another desktop to the one I'm currently on, creating a new Terminal instance moves me to the other desktop.

Originally created by @rkhoury on GitHub (Mar 5, 2025). ### Windows Terminal version 1.24.250228001-llm ### Windows build number 10.0.26100 ### Other Software _No response_ ### Steps to reproduce 1. Modify the Startup setting `New instance behavior` and set the value to `Attach to the most recently used window on this desktop` 2. Create a new Terminal (or Terminal Preview) instance on Desktop 1. 3. Create a new Terminal instance on Desktop 2 - for me this changes desktops and launches the instance on Desktop 1. Note (implied): my Terminal desktop settings are _not_ set to "Show windows from this app on all desktops" so I can attempt to keep terminal instances aligned with particular work streams. Reproduces in release build 1.23.10353.0 or canary build version 1.24.250228001-llm ### Expected Behavior When on a new desktop I expect a new instance of Terminal (or Terminal Preview) to create a new window and attach to that. ### Actual Behavior Assuming an instance of Terminal is already running on another desktop to the one I'm currently on, creating a new Terminal instance moves me to the other desktop.
claunia added the Issue-BugNeeds-Tag-FixProduct-TerminalPriority-2Area-Windowing labels 2026-01-31 08:29:17 +00:00
claunia commented 2026-01-31 08:29:19 +00:00
Author
Owner
Copy Link

@similar-issues-ai[bot] commented on GitHub (Mar 5, 2025):

We've found some similar issues:

  • #14130 , similarity score: 82%

If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.

Note: You can give me feedback by 👍 or 👎 this comment.

@similar-issues-ai[bot] commented on GitHub (Mar 5, 2025): We've found some similar issues: - #14130 , similarity score: 82% If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue. > Note: You can give me feedback by 👍 or 👎 this comment.
claunia commented 2026-01-31 08:29:19 +00:00
Author
Owner
Copy Link

@rkhoury commented on GitHub (Mar 5, 2025):

We've found some similar issues:

If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.

Note: You can give me feedback by 👍 or 👎 this comment.

The other issue looks similar but appears to be related to other monitors rather than virtual desktops - at least from what I could see. I'm not sure if responding with 👎 was the right thing to do?

@rkhoury commented on GitHub (Mar 5, 2025): > We've found some similar issues: > > * [New instance behavior doesn't work as expected with multiple monitors #14130](https://github.com/microsoft/terminal/issues/14130) , similarity score: 82% > > If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue. > > > Note: You can give me feedback by 👍 or 👎 this comment. The other issue looks similar but appears to be related to other monitors rather than virtual desktops - at least from what I could see. I'm not sure if responding with 👎 was the right thing to do?
claunia commented 2026-01-31 08:29:19 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Mar 26, 2025):

It was! Thanks!

We may have broken this in the small big medium-sized windowing refactoring we did in #18215.

@DHowett commented on GitHub (Mar 26, 2025): It was! Thanks! We may have broken this in the ~~small~~ ~~big~~ medium-sized windowing refactoring we did in #18215.
claunia commented 2026-01-31 08:29:19 +00:00
Author
Owner
Copy Link

@starfishpatkhoo commented on GitHub (Sep 14, 2025):

I can confirm this is still happening on Terminal Preview 1.24.2372.0 on Windows 10.0.26100.6584 ....

I depend on separating different workflows onto different desktops, and this confuses the heck out of me when it auto-switches... T_T

Hope it gets addressed soon...

@starfishpatkhoo commented on GitHub (Sep 14, 2025): I can confirm this is still happening on Terminal Preview 1.24.2372.0 on Windows 10.0.26100.6584 .... I depend on separating different workflows onto different desktops, and this confuses the heck out of me when it auto-switches... T_T Hope it gets addressed soon...
claunia commented 2026-01-31 08:29:20 +00:00
Author
Owner
Copy Link

@ravindUwU commented on GitHub (Oct 15, 2025):

Just noticed this on 1.23.12811.0 installed via the Windows Store on Windows 11 24H2 26100.6584. It's highly disruptive 😫. I typically work across several projects with 1 virtual desktop each so that all windows (and terminals & tabs) on a specific desktop are relevant to the corresponding project for quicker context switching. So: I switch projects (virtual desktops) with Win+←/→ and press Win+2 (via the taskbar) to open a project-specific terminal/tab only to end up with a terminal for a different project on a different virtual desktop 🤦.

Could this issue please be prioritised higher?

The Windows Store doesn't seem to allow downgrading versions, so I will uninstall it shortly, and try to re-install via GitHub release bundles.

@ravindUwU commented on GitHub (Oct 15, 2025): Just noticed this on `1.23.12811.0` installed via the Windows Store on Windows 11 24H2 `26100.6584`. It's highly disruptive 😫. I typically work across several projects with 1 virtual desktop each so that all windows (and terminals & tabs) on a specific desktop are relevant to the corresponding project for quicker context switching. So: I switch projects (virtual desktops) with <kbd>Win</kbd>+<kbd>←</kbd>/<kbd>→</kbd> and press <kbd>Win</kbd>+<kbd>2</kbd> (via the taskbar) to open a project-specific terminal/tab only to end up with a terminal for a different project on a different virtual desktop 🤦. Could this issue _please_ be prioritised higher? The Windows Store doesn't seem to allow downgrading versions, so I will uninstall it shortly, and try to re-install via [GitHub release bundles](https://github.com/microsoft/terminal/releases).
claunia commented 2026-01-31 08:29:20 +00:00
Author
Owner
Copy Link

@starfishpatkhoo commented on GitHub (Oct 15, 2025):

Just noticed this on 1.23.12811.0 installed via the Windows Store on Windows 11 24H2 26100.6584. It's highly disuptive 😫. I typically work across several projects with 1 virtual desktop each so that all windows (and terminals & tabs) on a specific desktop are relevant to the corresponding project for quicker context switching. So: I switch projects (virtual desktops) with Win+←/→ and press Win+2 (via the taskbar) to open a project-specific terminal/tab only to end up with a terminal for a different project on a different virtual desktop 🤦.

Could this issue please be prioritised higher?

The Windows Store doesn't seem to allow downgrading versions, so I will uninstall it shortly, and try to re-install via GitHub release bundles.

Regretfully, this issue is still present in version 1.23.12811.0 from GitHub...

So yeah, I also hope it gets resolved soon..

@starfishpatkhoo commented on GitHub (Oct 15, 2025): > Just noticed this on `1.23.12811.0` installed via the Windows Store on Windows 11 24H2 `26100.6584`. It's highly disuptive 😫. I typically work across several projects with 1 virtual desktop each so that all windows (and terminals & tabs) on a specific desktop are relevant to the corresponding project for quicker context switching. So: I switch projects (virtual desktops) with Win+←/→ and press Win+2 (via the taskbar) to open a project-specific terminal/tab only to end up with a terminal for a different project on a different virtual desktop 🤦. > > Could this issue _please_ be prioritised higher? > > The Windows Store doesn't seem to allow downgrading versions, so I will uninstall it shortly, and try to re-install via [GitHub release bundles](https://github.com/microsoft/terminal/releases). Regretfully, this issue is still present in version 1.23.12811.0 from GitHub... So yeah, I also hope it gets resolved soon..
claunia commented 2026-01-31 08:29:20 +00:00
Author
Owner
Copy Link

@ravindUwU commented on GitHub (Oct 15, 2025):

This issue seems present in all (non-pre-release) 1.23.x versions published so far, the latest being v1.23.12811.0. Downgraded to v1.22.12111.0 installed via the .msixbundle file list on the GitHub release, until this issue is resolved.

@ravindUwU commented on GitHub (Oct 15, 2025): This issue seems present in all (non-pre-release) `1.23.x` versions published so far, the latest being [v1.23.12811.0](https://github.com/microsoft/terminal/releases/tag/v1.23.12811.0). Downgraded to [v1.22.12111.0](https://github.com/microsoft/terminal/releases/tag/v1.22.12111.0) installed via the `.msixbundle` file list on the GitHub release, until this issue is resolved.
claunia commented 2026-01-31 08:29:20 +00:00
Author
Owner
Copy Link

@rkhoury commented on GitHub (Oct 15, 2025):

It looks like https://github.com/microsoft/terminal/milestone/58 is still very much active development, so if this feature is super important to you then @ravindUwU 's suggestion of downgrading to that v1.22 release seems like the best option until v1.24 is officially released or they've closed this ticket off.

@rkhoury commented on GitHub (Oct 15, 2025): It looks like https://github.com/microsoft/terminal/milestone/58 is still very much active development, so if this feature is super important to you then @ravindUwU 's suggestion of downgrading to that v1.22 release seems like the best option until v1.24 is officially released or they've closed this ticket off.
claunia commented 2026-01-31 08:29:21 +00:00
Author
Owner
Copy Link

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

Ack, sorry. We'll get the fix in a servicing release ASAP.

@DHowett commented on GitHub (Oct 15, 2025): Ack, sorry. We'll get the fix in a servicing release ASAP.
claunia commented 2026-01-31 08:29:21 +00:00
Author
Owner
Copy Link

@rkhoury commented on GitHub (Oct 15, 2025):

Thanks so much @DHowett and @lhecker .

@rkhoury commented on GitHub (Oct 15, 2025): Thanks so much @DHowett and @lhecker .
claunia commented 2026-01-31 08:29:21 +00:00
Author
Owner
Copy Link

@ravindUwU commented on GitHub (Oct 17, 2025):

Hmm 🤔. I'm somehow on 1.23 again, today, despite having installed a 1.22 version in https://github.com/microsoft/terminal/issues/18652#issuecomment-3404261290. Does installing an older version of Terminal via the .msixbundle still enable updates via the Windows Store? Is there no way to prevent auto updates (until this issue is resolved, but also in general for these bundles)?

In which case, I think I might have to reinstall the bundle every day 🤦.

@ravindUwU commented on GitHub (Oct 17, 2025): Hmm 🤔. I'm somehow on `1.23` again, today, despite having installed a `1.22` version in https://github.com/microsoft/terminal/issues/18652#issuecomment-3404261290. Does installing an older version of Terminal via the `.msixbundle` still enable updates via the Windows Store? Is there no way to prevent auto updates (until this issue is resolved, but also in general for these bundles)? In which case, I think I might have to reinstall the bundle every day 🤦. <img width="250" src="https://github.com/user-attachments/assets/1a112c83-e6e4-47af-9dd8-c8b556cb9f8d" />
claunia commented 2026-01-31 08:29:21 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Oct 20, 2025):

Does installing an older version of Terminal via the .msixbundle still enable updates via the Windows Store?

Yes

Is there no way to prevent auto updates

In the Microsoft Store settings page:

Image

(until this issue is resolved, but also in general for these bundles)?

You can install the canary release in the meantime.

@lhecker commented on GitHub (Oct 20, 2025): > Does installing an older version of Terminal via the .msixbundle still enable updates via the Windows Store? Yes > Is there no way to prevent auto updates In the Microsoft Store settings page: <img width="1264" height="750" alt="Image" src="https://github.com/user-attachments/assets/5207b0b3-924f-421a-80a9-40c72a60451b" /> > (until this issue is resolved, but also in general for these bundles)? You can install the canary release in the meantime.
claunia commented 2026-01-31 08:29:22 +00:00
Author
Owner
Copy Link

@kipusoep commented on GitHub (Nov 6, 2025):

In which version will this be included?

@kipusoep commented on GitHub (Nov 6, 2025): In which version will this be included?
claunia commented 2026-01-31 08:29:22 +00:00
Author
Owner
Copy Link

@ravindUwU commented on GitHub (Nov 27, 2025):

Is there no way to prevent auto updates

In the Microsoft Store settings page: [Screenshot of Microsoft Store "App Updates" setting]

This pauses updates for all apps instead of just Terminal, so using it is not an option. Aside: There really should be either 1) an option to pause updates by specific app on the store page; or 2) an option to install with updates paused when an app is installed via its .msixbundle instead of via the Store page; but this is a Microsoft Store issue and not a Windows Terminal issue.

Anyway, what I do to pause Windows Terminal updates because I use project-specific virtual desktops (https://github.com/microsoft/terminal/issues/18652#issuecomment-3404195501) is,

  1. After signing in to Windows, check the installed Windows Terminal version using (Get-AppxPackage 'Microsoft.WindowsTerminal').Version, then install the 1.22 .msixbundle in my Downloads folder if it has silently updated to 1.23 in between sessions.
  2. Open a Terminal on my first virtual desktop which is the "general", non-project-specific desktop and forget about it. It'll stay open in the background, and Windows doesn't seem to update Terminal as long as it's open. Continue work on other project-specific desktops.
  3. Repeat on the next reboot/sign in 🤦.
@ravindUwU commented on GitHub (Nov 27, 2025): > > Is there no way to prevent auto updates > > In the Microsoft Store settings page: [Screenshot of Microsoft Store "App Updates" setting] This pauses updates for _all apps_ instead of just Terminal, so using it is not an option. Aside: There really should be either 1) an option to pause updates by specific app on the store page; or 2) an option to install with updates paused when an app is installed via its `.msixbundle` instead of via the Store page; _but this is a Microsoft Store issue and not a Windows Terminal issue_. Anyway, what I do to pause Windows Terminal updates because I use project-specific virtual desktops (https://github.com/microsoft/terminal/issues/18652#issuecomment-3404195501) is, 1. After signing in to Windows, check the installed Windows Terminal version using `(Get-AppxPackage 'Microsoft.WindowsTerminal').Version`, then install the `1.22` `.msixbundle` in my Downloads folder if it has silently updated to `1.23` in between sessions. 2. Open a Terminal on my first virtual desktop which is the "general", non-project-specific desktop and forget about it. It'll stay open in the background, and Windows doesn't seem to update Terminal as long as it's open. Continue work on other project-specific desktops. 3. Repeat on the next reboot/sign in 🤦.
claunia commented 2026-01-31 08:29:22 +00:00
Author
Owner
Copy Link

@starfishpatkhoo commented on GitHub (Nov 27, 2025):

Ha ha.. What's really needed is for this fix to be released soon, not to finagle with MS Store and update policies ^_^

I see this item listed in the 1.24 servicing pipeline, but neither 1.24 nor 1.25 seems to be coming out anytime soon. I hope this is released sooner rather than later.

After all, while not a security-related matter, this issue is a regression, not a new feature request...

@starfishpatkhoo commented on GitHub (Nov 27, 2025): Ha ha.. What's really needed is for this fix to be released soon, not to finagle with MS Store and update policies ^_^ I see this item listed in the 1.24 servicing pipeline, but neither 1.24 nor 1.25 seems to be coming out anytime soon. I hope this is released sooner rather than later. After all, while not a security-related matter, this issue is a regression, not a new feature request...
claunia commented 2026-01-31 08:29:22 +00:00
Author
Owner
Copy Link

@ravindUwU commented on GitHub (Dec 3, 2025):

@DHowett, @lhecker, any idea why the .msixbundle installation fails sometimes with an error that says WT is already running, when all instances/windows are closed and Get-Process lists no relevant (?) processes? 🤔 Are there any other process names I should be looking for?

The installation proceeds after signing out and back in to Windows.

@ravindUwU commented on GitHub (Dec 3, 2025): @DHowett, @lhecker, any idea why the `.msixbundle` installation fails sometimes with an error that says WT is already running, when all instances/windows are closed and `Get-Process` lists no relevant (?) processes? 🤔 Are there any other process names I should be looking for? ![](https://github.com/user-attachments/assets/e17bbb1d-a6c1-430b-9c51-5b01e9297562) The installation proceeds after signing out and back in to Windows.
claunia commented 2026-01-31 08:29:22 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Dec 3, 2025):

When you have set Windows Terminal as your default terminal, and launch a CLI app from outside of it, it'll open inside Windows Terminal (which we call "handoff"). We use COM for this and so that'll spawn a RuntimeBroker.exe instance with our auto-generated COM stub proxy/broker, since we're a packaged app. We don't spawn the broker ourselves (the OS does) and so won't kill it either when we exit (I believe it'll exit on its own at some point). MSIX / the OS could probably kill it when it tries to update an app... It's also not listed as a child process because the broker gets spawned by the BrokerInfrastructure service under svchost.exe.

In any case, if you were to use System Informer, it would find that process:

Image
@lhecker commented on GitHub (Dec 3, 2025): When you have set Windows Terminal as your default terminal, and launch a CLI app from outside of it, it'll open inside Windows Terminal (which we call "handoff"). We use COM for this and so that'll spawn a `RuntimeBroker.exe` instance with our auto-generated COM stub proxy/broker, since we're a packaged app. We don't spawn the broker ourselves (the OS does) and so won't kill it either when we exit (I believe it'll exit on its own at some point). MSIX / the OS could probably kill it when it tries to update an app... It's also not listed as a child process because the broker gets spawned by the `BrokerInfrastructure` service under svchost.exe. In any case, if you were to use System Informer, it would find that process: <img width="1314" height="459" alt="Image" src="https://github.com/user-attachments/assets/52894c96-e5f4-402d-9854-64d1f45d1a25" />
claunia commented 2026-01-31 08:29:23 +00:00
Author
Owner
Copy Link

@starfishpatkhoo commented on GitHub (Dec 18, 2025):

Thank you for the 1.23 update ... It seems to be working great now! My virtual desktop thanks you guys!

@starfishpatkhoo commented on GitHub (Dec 18, 2025): Thank you for the 1.23 update ... It seems to be working great now! My virtual desktop thanks you guys!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-Windowing Issue-Bug Needs-Tag-Fix Priority-2 Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#22989
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?