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

'Use parent process directory' not being respected for new Tabs #19353

New Issue
Open
opened 2026-01-31 06:40:51 +00:00 by claunia · 6 comments
claunia commented 2026-01-31 06:40:51 +00:00
Owner
Copy Link

Originally created by @EskimoRuler on GitHub (Feb 9, 2023).

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.

  1. Use the context menu to launch Windows Terminal from a folder.
  2. WT will launch default profile in the directory of the folder it was launch
  3. 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.

Originally created by @EskimoRuler on GitHub (Feb 9, 2023). ### 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. 1. Use the context menu to launch Windows Terminal from a folder. 2. WT will launch default profile in the directory of the folder it was launch 3. 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.
claunia commented 2026-01-31 06:40:52 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (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.

Note

Walkthrough

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 commented on GitHub (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. > **Note** > ## Walkthrough 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.
claunia commented 2026-01-31 06:40:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (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> to elevate-shim, to open the new tab in the requested directory.

This however, requests that elevate-shim somehow 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 #4637

I dunno if this regressed in 1.16 or was always broken.

@zadjii-msft commented on GitHub (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>` to `elevate-shim`, to open the new tab in the requested directory. This however, requests that `elevate-shim` somehow 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 #4637 I dunno if this regressed in 1.16 or was always broken.
claunia commented 2026-01-31 06:40:53 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 2, 2023):

There's maybe an equal and opposite here - maybe the Terminal should have it's CWD set to system32 when 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.exe to get elevated when the CWD is set to something other than system32, 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.

@zadjii-msft commented on GitHub (May 2, 2023): There's maybe an equal and opposite here - maybe the Terminal _should_ have it's CWD set to `system32` when 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.exe` to get elevated when the CWD is set to something other than `system32`, 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.
claunia commented 2026-01-31 06:40:53 +00:00
Author
Owner
Copy Link

@EskimoRuler commented on GitHub (May 31, 2023):

Hmmmmmm.

This almost looks like a dupe of #15173, but subtly different.

With #15173, it's sufficient to just pass -d <path> to elevate-shim, to open the new tab in the requested directory.

This however, requests that elevate-shim somehow 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 #4637

I dunno if this regressed in 1.16 or was always broken.

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.

@EskimoRuler commented on GitHub (May 31, 2023): > Hmmmmmm. > > This almost looks like a dupe of #15173, but subtly different. > > With #15173, it's sufficient to just pass `-d <path>` to `elevate-shim`, to open the new tab in the requested directory. > > This however, requests that `elevate-shim` somehow 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 #4637 > > I dunno if this regressed in 1.16 or was always broken. 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.
claunia commented 2026-01-31 06:40:54 +00:00
Author
Owner
Copy Link

@medallyon commented on GitHub (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.

@medallyon commented on GitHub (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.
claunia commented 2026-01-31 06:40:54 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (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

@zadjii-msft commented on GitHub (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
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-UserInterface Help Wanted Issue-Bug Priority-3 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#19353
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?