Provide option to add "Open in Windows Terminal (Admin)" to Explorer context menu

[TheAndyMac]

Description of the new feature/enhancement

As well as having the option to Open in Windows Terminal as a right-click in Explorer (which should be configurable as discussed in #9902 and #6113 ) it would be really helpful to have a configurable option to ALSO have an "Open in Windows Terminal (Admin)" option to quickly open up Windows Terminal with Admin rights to be able to access those commands which need it.

Proposed technical implementation details (optional)

Add an option in the configuration to enable/disable an "Open in Windows Terminal (Admin)" context menu option.

[zadjii-msft]

Yea, we'll make sure to include this in the configuration options. This is technically different than #6111 so I'll leave it open

[Dhyfer1]

It has been 19 months since the creation of this issue and I also need Windows Terminal to be able to run as admin from the context menu. Why is there still no progress on this? or this isn't a priority for the developers behind Windows Terminal?

[zadjii-msft]

Indeed, this isn't an immediate priority for us. You'll note that across the repo, there are plenty of older issues, with more upvotes, which are currently a higher priority for us.

If you'd like to help, we'd be happy to help point you in the right direction! This is unfortunately kinda a tricky problem, because we need to solve two problems:

• We need to add support for the shell context menu code to load our settings model. I don't know if we can do that easily currently.
• We need to find a way to add settings to configure what our context menu settings should be. What shape do we want these settings to be? contextMenu.showElevatedEntry & contextMenu.showProfilePicker? contextMenu.showElevatedProfilePicker? We need some sort of design for that.
• Putting nested entries in the menu is non-trivial, https://github.com/microsoft/terminal/issues/6111#issuecomment-1252946834 has some notes. At least I'm not enough of a shell32 guru to know.

Figuring out the first bullet point is probably the hardest part. If you can get our settings loaded in the context menu code, then it's easy[^1] to add settings to control this.

---

EDIT from "dumb idea central", some time after 5pm local time:

the shell extension has to be fast. there's that boolean for "you can do slow stuff," but we don't want to use it because win11 already fucked us over

i think parsing appdata, loading json etc is gonna put us over budget

that is, to figure out how to build the shell ext menu from user settings

because we're packaged, we get our own registry. why shouldn't we cache this stuff in our isolated registry? it's way way faster than opening a file on disk, and has near 0 parsing

so if you set contextMenu.showElevatedThing, we set a single DWORD

and we don't need to do the shell(reg.exe) hack, it's all literally just local state

the only real downside is, you gotta launch terminal once after editing settings.json to push the real values in

none of this, "edit settings.json, then right click"

but also, we could store the names/GUIDs/icons of profiles in there too if we really wanted to. Show this profile -> ok we'll "memoize" it. It's not enough to reconstruct the profile from registry, just enough to make a menu item out of it.

so we aren't going into "store profiles in the registry" territory

[^1]: Of course, naming in software is a Hard problem, but adding settings is easy once you've figured that out 😋

[Mujtaba0150]

An easy workaround for someone willing to mess with the registry would be to add a registry key to the right click context menu to use PowerShell to open wt as an admin using the UAC prompt using this command: powershell Start-Process wt.exe -ArgumentList '-p \"Command Prompt\"' -Verb RunAs