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

Allow for custom profiles when running as admin vs user #5086

New Issue
Open
opened 2026-01-31 00:04:42 +00:00 by claunia · 10 comments
claunia commented 2026-01-31 00:04:42 +00:00
Owner
Copy Link

Originally created by @tmmuessig on GitHub (Nov 20, 2019).

Description of the new feature/enhancement

Having the ability to create different profiles, can be a great visual clue as to what you are doing, or where you are doing it at, e.g dev vs production. The same can be said about running as an administrator vs a regular user. As an admin I can potentially make damaging changes to a system, while as a normal user, I would not have the permissions. Having the ability to not only customize a profile, but have a separate profile that would load when it is detected that I launched the terminal as administrator would be a handy visual clue that I can do something potentially destructive. A red background for admin, or a green background as a user for example.

Proposed technical implementation details (optional)

Add the ability to create a different profile section for running the terminal when I right click and select "Run As Administrator" vs just normally launching the Terminal as a normal user.

Originally created by @tmmuessig on GitHub (Nov 20, 2019). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 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 Having the ability to create different profiles, can be a great visual clue as to what you are doing, or where you are doing it at, e.g dev vs production. The same can be said about running as an administrator vs a regular user. As an admin I can potentially make damaging changes to a system, while as a normal user, I would not have the permissions. Having the ability to not only customize a profile, but have a separate profile that would load when it is detected that I launched the terminal as administrator would be a handy visual clue that I can do something potentially destructive. A red background for admin, or a green background as a user for example. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> # Proposed technical implementation details (optional) Add the ability to create a different profile section for running the terminal when I right click and select "Run As Administrator" vs just normally launching the Terminal as a normal user. <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-FeatureArea-SettingsProduct-Terminal labels 2026-01-31 00:04:42 +00:00
claunia commented 2026-01-31 00:04:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 20, 2019):

This I shockingly don't hate.

We'd need some way to convey that this profile is only visible when elevated (or only visible when un-elevated). Further, this setting would need to be clear that it's not running the profile as admin, just that it's only visible when the Terminal is elevated.

I know Sublime Text has the notion of context for keybindings, where you can define some arbitrary queries for when keybindings apply. Maybe a similar style could be applied? Though that does seem like overkill for a feature that really only has three states.

Related: #632 (but not a dupe)

@zadjii-msft commented on GitHub (Nov 20, 2019): This I shockingly don't hate. We'd need some way to convey that this profile is only visible when elevated (or only visible when un-elevated). Further, this setting would need to be clear that it's not running the profile as admin, just that it's only visible when the Terminal is elevated. I know Sublime Text has the notion of `context` for keybindings, where you can define some arbitrary queries for when keybindings apply. Maybe a similar style could be applied? Though that does seem like overkill for a feature that really only has three states. Related: #632 (but _not_ a dupe)
claunia commented 2026-01-31 00:04:43 +00:00
Author
Owner
Copy Link

@evankanderson commented on GitHub (Oct 13, 2020):

(I was just looking for this today, wanted to add a +1)

@evankanderson commented on GitHub (Oct 13, 2020): (I was just looking for this today, wanted to add a +1)
claunia commented 2026-01-31 00:04:44 +00:00
Author
Owner
Copy Link

@tmmuessig commented on GitHub (Dec 21, 2020):

@zadjii-msft - Has there been any update (thought, consideration, testing) to this?

@tmmuessig commented on GitHub (Dec 21, 2020): @zadjii-msft - Has there been any update (thought, consideration, testing) to this?
claunia commented 2026-01-31 00:04:44 +00:00
Author
Owner
Copy Link

@ianabrown commented on GitHub (Apr 2, 2021):

If we're trying to gather requirements for this that feel like they'd fit within the existing setup, I'd request:

  • in addition to the existing "defaultProfile" setting, we introduce an "defaultProfileWhenElevated" (optional and terminal will use defaultProfile if this not specified?)
  • in addition to the "defaults" in "profiles" that apply to all profiles, also have a "defaultsWhenElevated"

Somewhat selfishly, these two would satisfy what I'd want from this feature - in my case, I'd go for a red tab color and a default profile of Powershell when elevated, but command prompt and normal tab color when not - but it also seems like it might address the requirements of the OP too?

@ianabrown commented on GitHub (Apr 2, 2021): If we're trying to gather requirements for this that feel like they'd fit within the existing setup, I'd request: - in addition to the existing "defaultProfile" setting, we introduce an "defaultProfileWhenElevated" (optional and terminal will use defaultProfile if this not specified?) - in addition to the "defaults" in "profiles" that apply to all profiles, also have a "defaultsWhenElevated" Somewhat selfishly, these two would satisfy what I'd want from this feature - in my case, I'd go for a red tab color and a default profile of Powershell when elevated, but command prompt and normal tab color when not - but it also seems like it might address the requirements of the OP too?
claunia commented 2026-01-31 00:04:44 +00:00
Author
Owner
Copy Link

@tmmuessig commented on GitHub (Apr 2, 2021):

@ianabrown - This absolutely would fit my requirements, and I love the idea of the defaultsWhenElevated "section" of the configuration. That way I can keep 99% of my settings (tab color, background, fonts, etc.), but only change those settings if 1. I am running as Admin, and 2, only if the defaultsWhenElevated are configured.

The way I see it is as follows:

Launch Terminal as Admin

  • Tab color is set to green (defaultProfile)
  • Background image is set to custom wallpaper (defaultProfile
  • Terminal detects that I am running as admin and checks for a defaultProfileWhenElevated
    • If that exists
    • Change Tab color to red (defaultProfileWhenElevated)
    • Change background wallpaper to admin customized wallpaper (defaultProfileWhenElevated)
        "defaults": {
            // Put settings here that you want to apply to all profiles
            "fontFace": "Cascadia Code PL",
            "fontSize": 10,
            "padding": "8, 8, 8, 8",
            "cursorShape": "bar",
            "backgroundImage": "ms-appdata:///Local/NonAdminWallpaper.jpg",
        },
        "defaultsWhenElevated": {
            // Put settings here that you want to apply while running as admin. Settings here will override any defaults defined
            "backgroundImage": "ms-appdata:///Local/AdminWallpaper.jpg",
            "tabColor":"Red"
        },
@tmmuessig commented on GitHub (Apr 2, 2021): @ianabrown - This absolutely would fit my requirements, and I love the idea of the defaultsWhenElevated "section" of the configuration. That way I can keep 99% of my settings (tab color, background, fonts, etc.), but only change those settings if 1. I am running as Admin, and 2, only if the defaultsWhenElevated are configured. The way I see it is as follows: Launch Terminal as Admin - Tab color is set to green (defaultProfile) - Background image is set to custom wallpaper (defaultProfile - Terminal detects that I am running as admin and checks for a defaultProfileWhenElevated - If that exists - Change Tab color to red (defaultProfileWhenElevated) - Change background wallpaper to admin customized wallpaper (defaultProfileWhenElevated) ``` "defaults": { // Put settings here that you want to apply to all profiles "fontFace": "Cascadia Code PL", "fontSize": 10, "padding": "8, 8, 8, 8", "cursorShape": "bar", "backgroundImage": "ms-appdata:///Local/NonAdminWallpaper.jpg", }, "defaultsWhenElevated": { // Put settings here that you want to apply while running as admin. Settings here will override any defaults defined "backgroundImage": "ms-appdata:///Local/AdminWallpaper.jpg", "tabColor":"Red" }, ```
claunia commented 2026-01-31 00:04:45 +00:00
Author
Owner
Copy Link

@0xabu commented on GitHub (Jan 26, 2022):

IMO this is more important now that Win11's Win+X A launches Windows Terminal in admin mode and not PowerShell/CMD. At a minimum, maybe we could just have a different defaultProfile when elevated?

(My default profile is a WSL shell, but for elevation I almost always want something native.)

@0xabu commented on GitHub (Jan 26, 2022): IMO this is more important now that Win11's `Win+X A` launches Windows Terminal in admin mode and not PowerShell/CMD. At a minimum, maybe we could just have a different `defaultProfile` when elevated? (My default profile is a WSL shell, but for elevation I almost always want something native.)
claunia commented 2026-01-31 00:04:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 27, 2022):

That's actually a really good point. Here's my showerthought spec for this, which I'm thinking is the most minimal way we could do this

<pseudo-spec>

Two settings changes:

  • elevatedDefaultProfile: The default profile when running as admin. This falls back to defaultProfile.
  • profile.hidden: changed to accept flags: ["none", "unelevated", "elevated", "all"], where true is none and false is all. So, you could hide profiles from one instance or the other.

I reopened #8311 for tracking scheme and other settings changes to existing profiles, since that wasn't really addressed in #8455. I may type these bits up as an addendum to that spec.

What I'd be "afraid" of is the same problem from #8345 where there's a combinatorial explosion of flags, but that's actually mitigated a bit by these just being flags, and not "keys that are basically sets of flags"

Warning


Yea we rejected that spec. It wasn't comprehensive enough.

@zadjii-msft commented on GitHub (Jan 27, 2022): That's actually a really good point. Here's my showerthought spec for this, which I'm thinking is the most minimal way we could do this \<pseudo-spec> Two settings changes: * `elevatedDefaultProfile`: The default profile when running as admin. This falls back to `defaultProfile`. * `profile.hidden`: changed to accept flags: `["none", "unelevated", "elevated", "all"]`, where `true` is `none` and `false` is `all`. So, you could hide profiles from one instance or the other. I reopened #8311 for tracking scheme and other settings changes to existing profiles, since that wasn't really addressed in #8455. I may type these bits up as an addendum to that spec. What I'd be "afraid" of is the same problem from #8345 where there's a combinatorial explosion of flags, but that's actually mitigated a bit by these just being flags, and not "keys that are basically sets of flags" > **Warning** > Yea we rejected that spec. It wasn't comprehensive enough.
claunia commented 2026-01-31 00:04:45 +00:00
Author
Owner
Copy Link

@tmmuessig commented on GitHub (Jan 25, 2023):

@zadjii-msft - Just wondering if there has been any more consideration for implementing this?

@tmmuessig commented on GitHub (Jan 25, 2023): @zadjii-msft - Just wondering if there has been any more consideration for implementing this?
claunia commented 2026-01-31 00:04:45 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 25, 2023):

Not really. It's still just kinda parked on the backlog - we'd definitely accept it as a community contribution. Alas, I don't think we're about to get to this any time soon.

I'll tag it up for discussion to see if the rest of the team is cool with the pseudo-spec I posted above. If there's consensus, I can write up a walkthrough of what I'd do to implement this.

May want to xref #13929 when we have that discussion.

Note

: for discussion
We add the above two settings.
At least the profile.hidden changes seems easier. The elevatedDefaultProfile one is still suspect to the combinatorial problem. For example: #13284. That's another variable.

Discussion conclusion: the tiny little spec there was definitely not sufficient. We'll come up with something more wholistic through #11111

@zadjii-msft commented on GitHub (Jan 25, 2023): Not really. It's still just kinda parked on the backlog - we'd definitely accept it as a community contribution. Alas, I don't think we're about to get to this any time soon. I'll tag it up for discussion to see if the rest of the team is cool with the pseudo-spec I posted above. If there's consensus, I can write up a walkthrough of what I'd do to implement this. May want to xref #13929 when we have that discussion. > **Note**: for discussion > We add the above two settings. > At least the `profile.hidden` changes seems easier. The `elevatedDefaultProfile` one is still suspect to the combinatorial problem. For example: #13284. That's another variable. Discussion conclusion: the tiny little spec there was definitely not sufficient. We'll come up with something more wholistic through #11111
claunia commented 2026-01-31 00:04:45 +00:00
Author
Owner
Copy Link

@michael-hawker commented on GitHub (Jun 27, 2024):

I liked @carlos-zamora idea mentioned in #11111 where there's just a completely separate config json file for admin mode. Maybe there could just be another setting toggle to enable that behavior?

Then there's just two independent settings files, one used for non-admin and one for admin. Then users can just customize all their settings when Terminal is elevated? They'll basically just work in isolation. Maybe there's some infobar if the setting it turned on that reminds them when terminal is elevated that the settings are for elevated only?

@michael-hawker commented on GitHub (Jun 27, 2024): I liked @carlos-zamora [idea mentioned in #11111](https://github.com/microsoft/terminal/issues/11111#issuecomment-1414194513) where there's just a completely separate config json file for admin mode. Maybe there could just be another setting toggle to enable that behavior? Then there's just two independent settings files, one used for non-admin and one for admin. Then users can just customize all their settings when Terminal is elevated? They'll basically just work in isolation. Maybe there's some infobar if the setting it turned on that reminds them when terminal is elevated that the settings are for elevated only?
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-Settings Issue-Feature 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#5086
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?