starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

CLI apps don't start in Windows Terminal when started minimized #20470

New Issue
Closed
opened 2026-01-31 07:14:45 +00:00 by claunia · 2 comments
claunia commented 2026-01-31 07:14:45 +00:00
Owner
Copy Link

Originally created by @dapetcu21 on GitHub (Sep 13, 2023).

Description of the new feature/enhancement

I have Windows Terminal set as my Default terminal application and New instance behavior set to "Attach to the most recently used window". We have a tool that starts many console processes at the same time. It does so using System.Diagnostics.Process.Start(). We'd like for these processes to be started in the background as to not steal the focus from the foreground window. I noticed that if I start the processes with ProcessStartInfo.WindowsStyle == ProcessWindowStyle.Minimized, the console windows will start minimized, but they won't attach as a tab to Windows Terminal. They will just start as windows of their own. Can we have Windows Terminal handle this situation too?

Originally created by @dapetcu21 on GitHub (Sep 13, 2023). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement I have Windows Terminal set as my Default terminal application and New instance behavior set to "Attach to the most recently used window". We have a tool that starts many console processes at the same time. It does so using `System.Diagnostics.Process.Start()`. We'd like for these processes to be started in the background as to not steal the focus from the foreground window. I noticed that if I start the processes with `ProcessStartInfo.WindowsStyle == ProcessWindowStyle.Minimized`, the console windows will start minimized, but they won't attach as a tab to Windows Terminal. They will just start as windows of their own. Can we have Windows Terminal handle this situation too?
claunia added the Issue-FeatureNeeds-TriageProduct-TerminalArea-DefApp labels 2026-01-31 07:14:46 +00:00
claunia commented 2026-01-31 07:14:47 +00:00
Author
Owner
Copy Link

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

You know, this was always by design. There's a bunch of heuristics built in to the Default Terminal handoff to try and ID a console app that "didn't wand a console window" - minimized is one of those things.

Maybe now, in the post-1.18 world where we have tear-out, we can allow for minimized defterm windows. We could just always pop the minimized defterm connection into a new window that's minimized. If someone wants to re-attach it, they always could restore it then re-attach it later.

xlinking a note from #13838

This doesn't do the same for defterm-initiated connections. This is because we don't need to! Defterm very explicitly rejects handoff for minimized console apps. This is probably for the best! I put an attempt in 66f8b25ec before I forgot that it was filtered long before the Terminal. NOT doing this for /min saves us all sorts of "what happens if start /min cmd tries to glom?" or "what if someone does start /min cmd && start /max cmd and they glom together?".

@zadjii-msft commented on GitHub (Sep 18, 2023): You know, this was always by design. There's a bunch of heuristics built in to the Default Terminal handoff to try and ID a console app that "didn't wand a console window" - minimized is one of those things. Maybe now, in the post-1.18 world where we have tear-out, we can allow for minimized defterm windows. We could just always pop the minimized defterm connection into a new window that's minimized. If someone wants to re-attach it, they always could restore it then re-attach it later. xlinking a note from #13838 > This doesn't do the same for defterm-initiated connections. This is because we don't need to! Defterm very explicitly rejects handoff for minimized console apps. This is probably for the best! I put an attempt in 66f8b25ec before I forgot that it was filtered long before the Terminal. NOT doing this for /min saves us all sorts of "what happens if `start /min cmd` tries to glom?" or "what if someone does `start /min cmd && start /max cmd` and they glom together?".
claunia commented 2026-01-31 07:14:48 +00:00
Author
Owner
Copy Link

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

Alrighty, so we ended up talking this over as a team. There's definitely something that theoretically could be done here. We could change the OS-side defterm handoff to still attempt the handoff even for applications that requested they be run minimized. This would require an OS-side code change1 (since that logic happens in the inbox conhost, before the delegation console is ever invoked). We'd then also change the Terminal to be able to determine if it wants to accept a minimized handoff or not. By rev'ing the defterm interface, we could probably make sure that older terminal versions running on newer Windows builds didn't do this accidentally.

We however decided ultimately that we probably shouldn't do this. The defterm handoff itself is kinda expensive on the CPU side. The process of looking up the COM object that's registered for the handoff, and doing that handoff, is non-trivial. We've already seen some perf measures be impacted by defterm when they're trying to launch consoles that aren't hidden/minimized. This would basically then also extend that perf hit even to the minimized console sessions. And that's just not something we're gonna feel comfortable with right now 😕

Perhaps in a future Windows release, we'll further rev the defterm interface more than this. It does feel a little peculiar at this time that the OS launches a conhost, just for that conhost to hand off to a second "conhost", who then hands off to the Terminal. That aforementioned perf hit is something we do really want to address, but it isn't something immediately in the cards for now. We'll probably revisit this (defterm for minimized consoles) in the future.

In the meantime, if you (or other future readers) have some solid business justification we can use to help prioritize this scenario, feel free to share it in the comments below. We can always reopen things for shifting priorities.

Thanks!

  1. I believe this also means we can't do it in a Moment, we have to wait for a whole OS swap. Those are less frequent. ↩︎

@zadjii-msft commented on GitHub (Oct 18, 2023): Alrighty, so we ended up talking this over as a team. There's definitely something that theoretically _could_ be done here. We _could_ change the OS-side defterm handoff to still attempt the handoff even for applications that requested they be run minimized. This would require an OS-side code change[^1] (since that logic happens in the inbox conhost, before the delegation console is ever invoked). We'd then also change the Terminal to be able to determine if it wants to accept a minimized handoff or not. By rev'ing the defterm interface, we could probably make sure that older terminal versions running on newer Windows builds didn't do this accidentally. We however decided ultimately that we probably _shouldn't_ do this. The defterm handoff itself is kinda expensive on the CPU side. The process of looking up the COM object that's registered for the handoff, and doing that handoff, is non-trivial. We've already seen some perf measures be impacted by defterm when they're trying to launch consoles that aren't hidden/minimized. This would basically then also extend that perf hit even to the minimized console sessions. And that's just not something we're gonna feel comfortable with right now 😕 Perhaps in a future Windows release, we'll further rev the defterm interface more than this. It does feel a little peculiar at this time that the OS launches a conhost, just for that conhost to hand off to a _second_ "conhost", who then hands off to the Terminal. That aforementioned perf hit is something we do really want to address, but it isn't something immediately in the cards for now. We'll probably revisit this (defterm for minimized consoles) in the future. In the meantime, if you (or other future readers) have some solid business justification we can use to help prioritize this scenario, feel free to share it in the comments below. We can always reopen things for shifting priorities. Thanks! [^1]: I believe this also means we can't do it in a Moment, we have to wait for a whole OS swap. Those are less frequent.
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-DefApp Issue-Feature Needs-Triage 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#20470
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?