start wt.exe with parameter fails in administrator mode #14861

Activity

1. M_a_t_z_e_ (Matzeeee)

   added

   Issue-BugIt either shouldn't be doing this or needs an investigation.It either shouldn't be doing this or needs an investigation.

   Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

   on Feb 16, 2023
2. zadjii-msft commented on Feb 16, 2023

   

   Mike Griese (zadjii-msft)

   on Feb 16, 2023

   Member

   More actions

   Welp. Okay that's wacky, unexpected, and tricky to resolve.

   • Your profiles default is set to elevate:true (profiles.defaults, not just the profile that is your default).
   • When you do wt ping 8.8.8.8, the Terminal opens, and tries to run with all your profiles.default profile's settings, except with the commandline explicitly set to pint 8.8.8.8.
   • After evaluating the settings, Terminal determines this new tab should be run elevated (in accordance with your settings) and then ShellExectute's itself, passing in the profile it should use to spawn the new tab.
     • In this step, it does NOT pass that overwritten commandline along
   • The elevated terminal spawns, and just uses the default commandline for the profile it was told (which was just profiles.defaults)

   This one's tricky. We basically need to pick something sensible to happen here. The argument could probably go either way:

   • Should the terminal open elevated, running ping 8.8.8.8?
   • Or should it open unelevated?

   I'd lean towards the second. Does that make sense to you M_a_t_z_e_ (@Matzeeee)?

   ---

   In that case, we'd want to modify ShouldImmediatelyHandoffToElevated / _maybeElevate in TerminalPage to ensure that the commandline is the same as the profile, before we decide to just elevate.
3. Mike Griese (zadjii-msft)

   added

   Product-TerminalThe new Windows Terminal.The new Windows Terminal.

   Priority-2A description (P2)A description (P2)

   and removed

   Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

   on Feb 16, 2023
4. Mike Griese (zadjii-msft)

   added this to the Terminal v1.18 milestone on Feb 16, 2023
5. microsoft-github-policy-service

   added

   Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

   on Feb 16, 2023
6. Matzeeee commented on Feb 16, 2023

   

   M_a_t_z_e_ (Matzeeee)

   on Feb 16, 2023

   Author

   More actions

   This one's tricky. We basically need to pick something sensible to happen here. The argument could probably go either way:

   • Should the terminal open elevated, running ping 8.8.8.8?
   • Or should it open unelevated?

   I'd lean towards the second. Does that make sense to you M_a_t_z_e_ (@Matzeeee)?

   In that case, we'd want to modify ShouldImmediatelyHandoffToElevated / _maybeElevate in TerminalPage to ensure that the commandline is the same as the profile, before we decide to just elevate.

   I expected the terminal to start elevated and then execute the command.
7. microsoft-github-policy-service

   added

   Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

   on Feb 16, 2023
8. Carlos Zamora (carlos-zamora)

   added

   Area-Commandlinewt.exe's commandline argumentswt.exe's commandline arguments

   and removed

   Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meetingIt's a new issue that the core contributor team needs to triage at the next triage meeting

   Needs-Tag-FixDoesn't match tag requirementsDoesn't match tag requirements

   on Feb 22, 2023
9. zadjii-msft commented on May 5, 2023

   

   Mike Griese (zadjii-msft)

   on May 5, 2023

   Member

   More actions

   You know, we might be able to something like #15286 for this. Pre-evaluate the actual commandline, given the NewTerminalArgs, and pass that in to elevate-shim.

   I'd worry about escaping that commandline though. That'd be scary.
10. Mike Griese (zadjii-msft)

    modified the milestones: Terminal v1.18, Terminal v1.19 on May 12, 2023
11. Mike Griese (zadjii-msft)

    added

    Help WantedWe encourage anyone to jump in on these.We encourage anyone to jump in on these.

    on Oct 4, 2023
12. Mike Griese (zadjii-msft)

    modified the milestones: Terminal v1.19, Backlog on Oct 4, 2023
13. Matzeeee commented on Dec 16, 2024

    

    M_a_t_z_e_ (Matzeeee)

    on Dec 16, 2024

    Author

    More actions

    will this ever be fixed?
14. lhecker commented on Dec 17, 2024

    

    Leonard Hecker (lhecker)

    on Dec 17, 2024

    Last edited by lhecker

    Member

    More actions

    It seems it partially was fixed: wt pwsh now properly spawns PowerShell in an elevated tab. However, it seems something's wrong with parameter escaping, as mentioned above, because the entire commandline given to wt is passed as a "single argument string" that is interpreted as a command line path with spaces. Example:

    

    I'll keep this tab open and look into it after the holidays.
15. wkin-t commented on Oct 9, 2026

    

    Wah (wkin-t)

    on Oct 9, 2026

    More actions

    Still reproducible on Windows Terminal 1.24.12741.0 (Windows 11, 10.0.26300), and I have a real-world trigger plus a process-creation log that shows exactly where the quoting gets mangled. It matches what a maintainer described in Dec 2024 in this thread: the whole command line reaches elevate-shim.exe as one quoted string and is then treated as an executable path containing spaces.

    Setup: profiles.defaults.elevate is true (this is what makes a plain wt -- <command> go through the elevation path, as noted earlier in this thread).

    Trigger: a third-party app (NetEase "UU Remote") launches a tab with an absolute, correctly quoted path:

    wt.exe -w uuyc-terminal-xxxx new-tab --title <guid> -- "C:/Program Files/Netease/GameViewer/bin/uuyc-cli.exe" term --device-id <redacted> --new-session --local-host-token <redacted> ...
    

    Result: WT shows 0x80070002 (The system cannot find the file specified) for C:/Program "Files/Netease/GameViewer/bin/uuyc-cli.exe term ....

    Where it breaks (Security event 4688 with command-line auditing, same click, abridged):

    wt.exe (parent: the app)
      wt.exe -w uuyc-terminal-xxxx new-tab --title <guid> -- "C:/Program Files/Netease/GameViewer/bin/uuyc-cli.exe" term --device-id <redacted> ...
    elevate-shim.exe (parent: WindowsTerminal.exe)
      new-tab --profile "{...}" --startingDirectory "C:\Program Files\Netease\GameViewer\bin\\" --title <guid> -- ""C:/Program Files/Netease/GameViewer/bin/uuyc-cli.exe" term --device-id <redacted> ... "
    

    The incoming command line is correctly quoted. By the time it is handed to elevate-shim.exe, the executable and all its arguments are wrapped in an extra pair of quotes, so the target becomes C:/Program + the rest.

    Workaround that confirmed the cause for me: set profiles.defaults.elevate to false and add "elevate": true explicitly to the profiles that really need admin. After that the same launch works.

    Happy to test a fix or provide more logs.