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

No keyboard input in Windows Terminal running with "runas /netonly user:<username>" flags from elevated shell #13651

New Issue
Open
opened 2026-01-31 03:48:28 +00:00 by claunia · 9 comments
claunia commented 2026-01-31 03:48:28 +00:00
Owner
Copy Link

Originally created by @fmj9 on GitHub (Apr 28, 2021).

Windows Terminal version (or Windows build number)

10.0.19042.0, 1.7.1091.0

Other Software

Guest OS Windows 10 20H2 (10.0.19042.0) inside Oracle VM VirtualBox (6.1.20 r143896). Not in domain
Host Ubuntu 20.04
Windows Terminal 1.7.1091.0

Steps to reproduce

  1. Run cmd (or Windows Terminal) as administrator
  2. Run "runas /netonly /user:%username% wt.exe"
    *wt.exe linking to Windows Terminal executable
  3. Windows Terminal windows opens, but keyboard input is not working

Expected Behavior

Expecting keyboard to work in Windows Terminal's command promt.
When running not elevated cmd (or Windows Terminal) and launching Windows Terminal via "runas..." (from non elevated shell) everything works fine.

Actual Behavior

No keyboard input in Windows Terminal launched from elevated shell via "runas...". Mouse selecting and clicking (copy/paste) works fine.

Originally created by @fmj9 on GitHub (Apr 28, 2021). ### Windows Terminal version (or Windows build number) 10.0.19042.0, 1.7.1091.0 ### Other Software Guest OS Windows 10 20H2 (10.0.19042.0) inside Oracle VM VirtualBox (6.1.20 r143896). Not in domain Host Ubuntu 20.04 Windows Terminal 1.7.1091.0 ### Steps to reproduce 1. Run cmd (or Windows Terminal) as administrator 2. Run "runas /netonly /user:%username% wt.exe" *wt.exe linking to Windows Terminal executable 3. Windows Terminal windows opens, but keyboard input is not working ### Expected Behavior Expecting keyboard to work in Windows Terminal's command promt. When running not elevated cmd (or Windows Terminal) and launching Windows Terminal via "runas..." (from non elevated shell) everything works fine. ### Actual Behavior No keyboard input in Windows Terminal launched from elevated shell via "runas...". Mouse selecting and clicking (copy/paste) works fine.
claunia added the Issue-BugArea-InputTracking-External labels 2026-01-31 03:48:28 +00:00
claunia commented 2026-01-31 03:48:29 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 29, 2021):

Huh, this is weird. This is kinda like #8045, #4448, but different in that input works fine while unelevated. @ebadger, do you have any ideas as to what might be going on here?

@zadjii-msft commented on GitHub (Apr 29, 2021): Huh, this is weird. This is kinda like #8045, #4448, but different in that input works fine while unelevated. @ebadger, do you have any ideas as to what might be going on here?
claunia commented 2026-01-31 03:48:29 +00:00
Author
Owner
Copy Link

@ebadger commented on GitHub (Apr 29, 2021):

@fmj9 Curious to know if input into notepad works if you launch it in the repo way.

for example:
Run cmd (or Windows Terminal) as administrator
Run "runas /netonly /user:%username% notepad.exe"

Does typing into notepad work?

@ebadger commented on GitHub (Apr 29, 2021): @fmj9 Curious to know if input into notepad works if you launch it in the repo way. for example: Run cmd (or Windows Terminal) as administrator Run "runas /netonly /user:%username% notepad.exe" Does typing into notepad work?
claunia commented 2026-01-31 03:48:29 +00:00
Author
Owner
Copy Link

@fmj9 commented on GitHub (Apr 30, 2021):

Yes, when I launch notepad via runas typing into notepad works fine.
Same when I launch cmd or powershell. The problem only occurs when I'm starting Windows Terminal this way

@fmj9 commented on GitHub (Apr 30, 2021): Yes, when I launch notepad via runas typing into notepad works fine. Same when I launch cmd or powershell. The problem only occurs when I'm starting Windows Terminal this way
claunia commented 2026-01-31 03:48:29 +00:00
Author
Owner
Copy Link

@mitchellrj commented on GitHub (Jul 1, 2022):

I also experience this issue. I can paste by right-clicking, but no keyboard input works except for the window chrome (e.g. CTRL+SPACE). If I open the settings panel, then no keyboard input works there either.

Version: 1.13.11431.0

@mitchellrj commented on GitHub (Jul 1, 2022): I also experience this issue. I can paste by right-clicking, but no keyboard input works except for the window chrome (e.g. CTRL+SPACE). If I open the settings panel, then no keyboard input works there either. Version: 1.13.11431.0
claunia commented 2026-01-31 03:48:29 +00:00
Author
Owner
Copy Link

@ebadger commented on GitHub (Jul 1, 2022):

can you check your tasklist to see if ctfmon.exe is running?

@ebadger commented on GitHub (Jul 1, 2022): can you check your tasklist to see if ctfmon.exe is running?
claunia commented 2026-01-31 03:48:29 +00:00
Author
Owner
Copy Link

@mitchellrj commented on GitHub (Jul 1, 2022):

Yes, ctfmon.exe is running.

@mitchellrj commented on GitHub (Jul 1, 2022): Yes, ctfmon.exe is running.
claunia commented 2026-01-31 03:48:30 +00:00
Author
Owner
Copy Link

@carlos-zamora commented on GitHub (Nov 2, 2022):

@ebadger any ideas? Could this be an issue with multiple user accounts?

@carlos-zamora commented on GitHub (Nov 2, 2022): @ebadger any ideas? Could this be an issue with multiple user accounts?
claunia commented 2026-01-31 03:48:30 +00:00
Author
Owner
Copy Link

@Phorin commented on GitHub (Feb 23, 2023):

I'm unsure if this is related, but I suspect it is...

On my work laptop image we use BeyondTrust/PowerBroker to elevate processes. When I use BeyondTrust to elevate wt.exe, no keyboard input is received, but only to that window. And yes, ctfmon.exe is running.

Global shortcuts like Alt+Space do work, and you can close the Alt+Space popup with the ESC key too. (Obviously since this all runs from dwm, I'm guessing.) Absolutely nothing else works, including tab, function keys, etc. The behavior is not as if there's a secondary key being held down like Alt (e.g. pressing Tab does not result in an Alt+Tab popup).

There are no messages in the Application or System events in Event Viewer pertaining to any of this that I can find. I also was not able to quickly (in under 10 minutes) find a way to enable additional logging for Windows Terminal itself, so I cannot provide logs.

Running cmd.exe using BeyondTrust allows keyboard input, but then when I execute the Windows Terminal wt.exe executable from that elevated cmd.exe window, the input again does not work for the WT window. (cmd.exe [elevated] -> wt.exe [elevated] -> no keyboard input)

Now for the interesting part... when I run wt.exe from an ELEVATED cmd.exe using:

runas /trustlevel:0x20000

The WT input still does not work, despite the WT instance being run with non-elevated permissions (tab in WT does not show "Administrator: " in front of it). (cmd.exe [elevated] -> Run as [de-escalated] wt.exe -> no keyboard input)

It's like it's some kind of process isolation issue almost given how utterly stubborn it is being to any kind of user input in that window. We do also use the following McAfee products:

Data Exchange Layer
Drive Encryption Agent
DLP Endpoint
Application Control
Endpoint Security

As well as FireEye endpoint security.

@Phorin commented on GitHub (Feb 23, 2023): I'm unsure if this is related, but I suspect it is... On my work laptop image we use BeyondTrust/PowerBroker to elevate processes. When I use BeyondTrust to elevate `wt.exe`, no keyboard input is received, but only to that window. And yes, `ctfmon.exe` **is** running. Global shortcuts like `Alt+Space` **do** work, and you can close the `Alt+Space` popup with the `ESC` key too. (Obviously since this all runs from dwm, I'm guessing.) Absolutely nothing else works, including tab, function keys, etc. The behavior is **not** as if there's a secondary key being held down like `Alt` (e.g. pressing `Tab` does not result in an `Alt+Tab` popup). There are no messages in the Application or System events in Event Viewer pertaining to any of this that I can find. I also was not able to quickly (in under 10 minutes) find a way to enable additional logging for Windows Terminal itself, so I cannot provide logs. Running `cmd.exe` using BeyondTrust allows keyboard input, but then when I execute the Windows Terminal `wt.exe` executable from that elevated `cmd.exe` window, the input again does not work for the WT window. (`cmd.exe [elevated] -> wt.exe [elevated] -> no keyboard input`) Now for the interesting part... when I run wt.exe from an ELEVATED `cmd.exe` using: `runas /trustlevel:0x20000` The WT input **still** does **not** work, despite the WT instance being run with non-elevated permissions (tab in WT does **not** show "Administrator: " in front of it). (`cmd.exe [elevated] -> Run as [de-escalated] wt.exe -> no keyboard input`) It's like it's some kind of process isolation issue almost given how utterly stubborn it is being to any kind of user input in that window. We do also use the following McAfee products: Data Exchange Layer Drive Encryption Agent DLP Endpoint Application Control Endpoint Security As well as FireEye endpoint security.
claunia commented 2026-01-31 03:48:30 +00:00
Author
Owner
Copy Link

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

MSFT:43611188 for internal tracking purposes, we'll see what the input folks have to say

@zadjii-msft commented on GitHub (Mar 2, 2023): MSFT:43611188 for internal tracking purposes, we'll see what the input folks have to say
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-Input Issue-Bug Tracking-External
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#13651
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?