'Run profile as admin' ignored when running bat or cmd directly (double-clicking)

[Bostonjunk]

Windows Terminal version

1.21.2361.0

Windows build number

10.0.22631.0

Other Software

No response

Steps to reproduce

Change default profile setting to enable 'Run profile as administrator' then try and open a batch file or cmd file by double-clicking on it.

Caveat - I am logged into Windows as a standard user but need to run scripts under a separate admin account. Terminal is installed for both the standard and admin user.

Extra context - I upgraded from a Windows 10 to a Windows 11 laptop - everything else works fine, this is the only thing I can't get functioning as it did before.

Expected Behavior

To double-click on the bat or cmd file and be prompted for elevation and the bat or cmd to launch in an elevated Terminal window.
This is how it functioned on my old laptop.

Actual Behavior

I am not prompted for elevation and the bat or cmd file opens in a standard session.

If Terminal is run directly, or the + is pressed for a new tab, only then am I prompted for elevation.

[zadjii-msft]

That's totally by design. When you double-click on a batch script, the OS launches an instance of CMD.exe to process that script, then launches a terminal application to handle that script. By the time the Terminal is launched, the script is already running unelevated. The terminal settings can't affect the elevation of that process anymore. That hasn't changed between Windows 10 & 11

To double-click on the bat or cmd file and be prompted for elevation and the bat or cmd to launch in an elevated Terminal window.
This is how it functioned on my old laptop.

Are you actually clicking on a shortcut to a batch file, one that's got this box checked?

because otherwise I don't know how a batch script could request to be run as admin... Maybe it's something specific to that script/?

[Bostonjunk]

Nope, if I use a shortcut as shown in your image, it will open in a conhost window.

On my previous Windows 10 laptop I was using 2 days ago, if I double-clicked directly on a bat or cmd file, it would ask me for elevation and run in an elevated Terminal window - I was just wanting the same behaviour on my new laptop.

The only setting I changed on my old laptop to make this happen was 'Run profile as administrator' - then it functioned as described - I've been using it that way for over 2 years.

EDIT: On my new laptop, if I right-click and run as admin, it will run in a conhost window. If I double-click, it will run in a standard Terminal session.
The only way to currently have it running in Terminal AND as admin, is to run Terminal as admin, then navigate to the folder via the command line and launch it that way, which is much less convenient than just double-clicking on the file.

The bat files themselves serve only as launchers for PowerShell scripts, so the files themselves are literally just:
@ECHO OFF
CLS
powershell -Executionpolicy bypass -file [path to script]
PAUSE

[Bostonjunk]

20240904.143352-new.mp4

[zadjii-msft]

That's... definitely not supposed to happen 😨

When you get the UAC prompt for the Terminal, what's the commandline it shows? (under "Show more details")

[Bostonjunk]

[zadjii-msft]

huh. That's wacky. It

• boots the unelevated terminal
• decides that ....\Enable AD Account.bat matches one of your profiles (with a guid of {3ad42e7b-...)
• evaluates that the profile it matched should be elevated
• then hands off the commandline instead to an elevated window

So what ends up running is a second copy of that batch script, with the original one presumably terminating early when the original terminal process exits.

That's super weird.

That is on 1.20, but I don't think we changed that in 1.21.
https://github.com/microsoft/terminal/blame/7b50f12a780ec0f8a55e7f04ad12d65b451f7667/src/cascadia/TerminalApp/TerminalPage.cpp#L305-L314

Most recent changes there are:

• Fix defterm in wake of auto-elevation #12272 (1.13)
• Clearly differentiate running elevated vs. drag/drop breaking #14946 (1.18)
• Add support for restoring non-terminal panes, and opening them with splitPane, newTab #16914 (1.21, but I don't really think this is relevant)

Unless we're just not matching this commandline anymore, but I'd doubt that.

Could you manually install a 1.20 Terminal on your win11 machine, and see if that works the same as before? Or inversely, a 1.21 Terminal on win10? I cannot imagine that the handoff logic that's in the OS is different between those two OS versions.

[Bostonjunk]

I've had this behaviour going back quite a long way - it survived many updates.
I don't know when I first installed Terminal, but I'm pretty sure in the early days it wasn't a Store app, but installed via an old-skool MSI package, maybe? I can't remember my exact update path over the years, but that's the only 'non-standard' aspect to things here. Possibly something to do with my upgrade path from very early versions? (Clutching at straws here a bit)

[zadjii-msft]

Terminal's been an MSIX "store package" since our earliest release - 0.2, so I doubt it's that. I just want to try and narrow down where the delta happened that regressed this scenario for you.

What's the profile in your settings.json with the 3ad42e7b... guid? The commandline for that might be enlightening

[Bostonjunk]

Apologies - did you want the settings.json file itself or something else as well?

[zadjii-msft]

Yea the settings.json file would be good enough ☺️

[1EDExg0ffyXfTEqdIUAYNZGnCeajIxMWd2vaQeP]

still relevant AFAIK

[zadjii-msft]

@1EDExg0ffyXfTEqdIUAYNZGnCeajIxMWd2vaQeP if you're hitting this too, then the same question applies to you ☺️ That's the next thing I'd investigate, and can't do much else without it.