Repository navigation
'Use parent process directory' not being respected for new Tabs #14817
Description
Windows Terminal version
1.16.10262.0
Windows build number
10.0.2621.1105
Other Software
No response
Steps to reproduce
I have my WT setup so my default profile is lauch as admin and with the 'Use parent process directory' checked for starting directory. I then have all my other profiles set to 'Use parent process directory' for starting directory as well.
- Use the context menu to launch Windows Terminal from a folder.
- WT will launch default profile in the directory of the folder it was launch
- Opening a new Tab launches the new profile to the 'C:\Windows\System32' folder
Expected Behavior
Each new tab opened with different profiles should open in the same directory that WT was launched from
Actual Behavior
Each new tab is launch to the 'C:\Windows\System32' folder.
Reacted by sleepyhollo, EskimoRuler, Wizmann, Tilman, hensuu, regs01, dexeonify, aditya sahu and Mitch Razga
Activity
[-]'Use parent process directory' not being respected[/-][+]'Use parent process directory' not being respected for new Tabs[/+]zadjii-msft commentedon Feb 10, 2023
Huh. I guess that makes sense, we're probably not passing the initial CWD of the Terminal to the elevate-shim to forward that to the elevated terminal instance.
Probably wouldn't be terribly difficult to pass the original terminal's CWD to elevate-shim. I'd look at
TerminalPage::_maybeElevate- that's where the handoff from an unelevated -> elevated process happens.zadjii-msft commentedon May 2, 2023
Hmmmmmm.
This almost looks like a dupe of #15173, but subtly different.
With #15173, it's sufficient to just pass
-d <path>toelevate-shim, to open the new tab in the requested directory.This however, requests that
elevate-shimsomehow communicates that the Terminal itself should set it's CWD. In this case, the auto-self-elevate case, we need to pass the current virtual directory of the terminal to the elevate shim, to pass to the new one. Ew. Almost like #4637I dunno if this regressed in 1.16 or was always broken.
zadjii-msft commentedon May 2, 2023
There's maybe an equal and opposite here - maybe the Terminal should have it's CWD set to
system32when it's run elevated. That seems like pseudo-security, but there's some precedent here discussed in #7062.I don't think that's incompatible with #7062. I just wonder if there's perhaps a reason why it shouldn't be automatic. Is there a vector for
malicious.exeto get elevated when the CWD is set to something other thansystem32, that it wouldn't otherwise be able to do just by inserting itself into the profile? I doubt it, but I'm no security expert.EskimoRuler commentedon May 31, 2023
This did work in previous versions. It broke with the latest. Been tough dealing with it not working. Was just so used to the workflow being able to switch to different consoles for the same directory.
medallyon commentedon Jun 8, 2023
I am also experiencing this bug on Windows 11 version 10.0.22621.1702. I believe this still works on my other PC which probably uses an older version. Will verify soon.
zadjii-msft commentedon Jun 8, 2023
FWIW I'm pretty confident this isn't a OS version issue, this is a Terminal version issue. Terminal 1.16 includes the change that regressed this, regardless of OS version
MitchRazga commentedon May 3, 2026
Kayla Cinnamon (@cinnamon-msft) James Montemagno (@jamesmontemagno) I recently watched the "Kayla Makes James' Windows Terminal Awesome" livestream and it inspired me to actually take a look at what settings are available! 😄
The
Use parent process directorysetting would be a brilliant productivity boost but unfortunately this issue is blocking me from using it.This thread is a bit stale, but several dupes have been opened since, so it seems like it is causing friction for others too.
Is a fix for this still being considered?
Ankith-B commentedon Oct 11, 2026
I'd like to work on this, following the walkthrough. Could I be assigned?
From reading
main:_maybeElevatepasses-dfor the first tab, but the elevated window's own initial CWD comes fromGetCurrentDirectory()in the new elevated process, which isSystem32after arunaselevation. So subsequent tabs using "Use parent process directory" resolve againstSystem32. The unelevated version of this (#18604) was fixed in #18801, but the elevated handoff still loses the original window's CWD.Since an elevated process can't inherit the CWD (and as far as I can tell
runasdoesn't honorlpDirectoryfor this launch path; I'll confirm when testing), I think the original window'sVirtualWorkingDirectoryhas to travel on the elevated command line. Two options:--initial-cwd <path>) that_OpenElevatedWTadds andTerminalWindowuses forSetInitialCwd.new-tab -dvalue as the window's initial CWD, but only for elevate-shim handoffs.I saw your note about whether an elevated Terminal should stay in
System32(#7062). If you'd rather keep that behavior, I'm happy to close this out differently.Which would you prefer? Happy to take a different direction.
DHowett commentedon Oct 12, 2026
You seem to be a robot. Follow our AI contribution guidelines or face the consequences.
Ankith-B commentedon Oct 12, 2026
I am not a robot. Would you be able to unhide my message because it says hidden as spam.
DHowett commentedon Oct 12, 2026
You're not? Then where did this mysterious 22 come from, and why did another random user who I also suspect of being a robot reply with a 21 only a minute earlier?
TLDR follow our AI guidelines or do not return.
MitchRazga commentedon Oct 12, 2026
Dustin L. Howett (@DHowett) It peaked my interest that those comments had those random numbers so I looked into it and to give them the benefit of the doubt it might actually be this GitHub bug: https://github.com/orgs/community/discussions/209947
DHowett commentedon Oct 12, 2026
Mitch Razga (@MitchRazga) oh wow, that's actually really helpful! Thank you, and good find :)
Ankith-B commentedon Oct 12, 2026
Whenever I click "quote in reply", the number 22 just appears there.
Also, would you be able to assign this bug to me?
DHowett commentedon Oct 12, 2026
As a rule, we do not assign bugs to people who show up out of nowhere and ask. It just adds more work for us when that person invariably disappears.
As you can tell, this work has not been started and nobody is really talking about it except for you. You do not need to be assigned to submit a pull request, so you are welcome to step up to the plate and submit one. You do not need our permission.