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

Windows Terminal window shows up when running a task via schtasks.exe when WT is set as default terminal #20416

New Issue
Closed
opened 2026-01-31 07:13:08 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 07:13:08 +00:00
Owner
Copy Link

Originally created by @supra107 on GitHub (Aug 28, 2023).

Windows Terminal version

1.17.11461.0

Windows build number

10.0.19045.3324

Other Software

schtasks.exe
Windows Task Scheduler

Steps to reproduce

Run a Task Scheduler task via "schtasks /run /tn" command while Windows Terminal is set as the default terminal. In this case it's a simple task that runs a file manager .exe in elevated mode.

Expected Behavior

The program opens up instantly without any terminal windows showing up as is the default behavior when Windows decides on the default terminal program. No additional delay appears between executing the task and the program opening.

Actual Behavior

For a brief moment Windows Terminal shows up causing a slight delay between the task being ran and the program opening caused by Windows Terminal unnecessarily loading when the task is executed.

This is noticeable as in my case I'm using a macro to quickly switch between an elevated and unelevated instance of a program by running a task in Task Scheduler that opens the program in elevated mode without a UAC prompt. However the Windows Terminal window also shows up when the task runs without elevation.

By swapping the default terminal back to Windows default the elevated and unelevated version opens up in the same time, while with the default terminal set as Windows Terminal, it briefly opens up when the Task Scheduler task is executed, leading to the elevated process opening slower than the unelevated version which is ran directly from the executable.

This is unexpected behavior as I am not executing a Batch script via Task Scheduler, but an exectuable file directly, and it's not an issue when Windows Terminal is not the default terminal. Windows Terminal shouldn't be invoked when running tasks from Task Scheduler that don't explicitly invoke the terminal.

I've verified that the issue is within the schtasks command, the AutoHotkey macro behaves the exact same as a desktop shortcut.

Originally created by @supra107 on GitHub (Aug 28, 2023). ### Windows Terminal version 1.17.11461.0 ### Windows build number 10.0.19045.3324 ### Other Software schtasks.exe Windows Task Scheduler ### Steps to reproduce Run a Task Scheduler task via "schtasks /run /tn" command while Windows Terminal is set as the default terminal. In this case it's a simple task that runs a file manager .exe in elevated mode. ### Expected Behavior The program opens up instantly without any terminal windows showing up as is the default behavior when Windows decides on the default terminal program. No additional delay appears between executing the task and the program opening. ### Actual Behavior For a brief moment Windows Terminal shows up causing a slight delay between the task being ran and the program opening caused by Windows Terminal unnecessarily loading when the task is executed. This is noticeable as in my case I'm using a macro to quickly switch between an elevated and unelevated instance of a program by running a task in Task Scheduler that opens the program in elevated mode without a UAC prompt. However the Windows Terminal window also shows up when the task runs without elevation. By swapping the default terminal back to Windows default the elevated and unelevated version opens up in the same time, while with the default terminal set as Windows Terminal, it briefly opens up when the Task Scheduler task is executed, leading to the elevated process opening slower than the unelevated version which is ran directly from the executable. This is unexpected behavior as I am not executing a Batch script via Task Scheduler, but an exectuable file directly, and it's not an issue when Windows Terminal is not the default terminal. Windows Terminal shouldn't be invoked when running tasks from Task Scheduler that don't explicitly invoke the terminal. I've verified that the issue is within the schtasks command, the AutoHotkey macro behaves the exact same as a desktop shortcut.
claunia commented 2026-01-31 07:13:10 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 29, 2023):

Thanks for filing!

This is because schtasks is a "console subsystem" executable. Unfortunately, by contract on Windows all executable files with the console subsystem flag in their headers will be given a console window.

The selection of Windows Terminal as the default console host does not change this behavior. It does, however, make it more obvious (as Terminal takes a little longer to start up.) When you have the default set to "Windows Console Host", it is creating a window almost too quickly to be seen. It is still creating a window.

We try pretty hard to not launch Terminal for any console session that is not destined for interactive use. To that end, if any one of the following is true we will not launch your configured terminal emuylator:

  • The process is started with a windowing mode other than SHOWDEFAULT, SHOW or MAXIMIZE
  • The process is a GUI subsystem application calling AllocateConsole
  • The process is running in a non-interactive user session or with a non-default window station
  • The process was started with the CREATE_NO_WINDOW process creation flag

If you have control over any of those with the task scheduler, I'd recommend trying one of them.

@DHowett commented on GitHub (Aug 29, 2023): Thanks for filing! This is because `schtasks` is a "console subsystem" executable. Unfortunately, by contract on Windows _all_ executable files with the console subsystem flag in their headers will be given a console window. The selection of Windows Terminal as the default console host does not change this behavior. It does, however, make it more obvious (as Terminal takes a little longer to start up.) When you have the default set to "Windows Console Host", it is creating a window almost too quickly to be seen. It is still creating a window. We try pretty hard to not launch Terminal for any console session that is not destined for interactive use. To that end, if any one of the following is true we will not launch your configured terminal emuylator: - The process is started with a windowing mode other than `SHOWDEFAULT`, `SHOW` or `MAXIMIZE` - The process is a GUI subsystem application calling `AllocateConsole` - The process is running in a non-interactive user session or with a non-default window station - The process was started with the `CREATE_NO_WINDOW` process creation flag If you have control over any of those with the task scheduler, I'd recommend trying one of them.
claunia commented 2026-01-31 07:13:10 +00:00
Author
Owner
Copy Link

@supra107 commented on GitHub (Aug 30, 2023):

Thank you so much for the helpful response.

After editing my script so that the Run command in AutoHotkey that executes schtasks has a Hide attribute, Windows Terminal no longer tries to hook up to the schtasks process while being set as the default terminal. Now I know to keep that in mind if I encounter this issue again.

@supra107 commented on GitHub (Aug 30, 2023): Thank you so much for the helpful response. After editing my script so that the `Run` command in AutoHotkey that executes `schtasks` has a `Hide` attribute, Windows Terminal no longer tries to hook up to the `schtasks` process while being set as the default terminal. Now I know to keep that in mind if I encounter this issue again.
claunia commented 2026-01-31 07:13:10 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 30, 2023):

Thanks @supra107 for following up!

@DHowett commented on GitHub (Aug 30, 2023): Thanks @supra107 for following up!
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 Issue-Question Needs-Tag-Fix Resolution-Answered Resolution-By-Design
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#20416
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?