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

New Tab should launch in the original starting directory #17592

New Issue
Closed
opened 2026-01-31 05:46:58 +00:00 by claunia · 12 comments
claunia commented 2026-01-31 05:46:58 +00:00
Owner
Copy Link

Originally created by @jacob-pro on GitHub (May 27, 2022).

Windows Terminal version

1.12.10982.0

Windows build number

10.0.19043.1706

Issue

I am stuck between two bad options for the starting directory option:

Launched From Expected Starting Directory . Starting Directory %USERPROFILE%
"Open in Terminal" Context Menu The folder you are currently in ✓ ✓
Entering wt -d . in the explorer address bar The folder you are currently in ✓ ✓
Start menu / task bar shortcuts $USERPROFILE directory ✘ System32 ✓
Clicking new tab The folder the first tab launched in ✓ ✘ %USERPROFILE%

In short, the new tab behaviour works as expected when the "Use parent process directory" option is enabled, however I can't use this option because it breaks the start menu shortcuts (#11834 and #878)

Background

The use-case for this is that I often want to right click a folder to open in terminal, this opens in my default shell (e.g. WSL), but sometimes I actually want to be using a different shell in this directory (Powershell).

Or another example: I'm developing a project in C:\Users\jacob\projects\example, I want to right click open in terminal, and then have multiple tabs for running different tasks in the project

Originally created by @jacob-pro on GitHub (May 27, 2022). ### Windows Terminal version 1.12.10982.0 ### Windows build number 10.0.19043.1706 ### Issue I am stuck between two bad options for the starting directory option: | Launched From | Expected | Starting Directory . | Starting Directory %USERPROFILE% | |------------------------------------------------|--------------------------------------|----------------------|-----------------------------------| | "Open in Terminal" Context Menu | The folder you are currently in | ✓ | ✓ | | Entering `wt -d .` in the explorer address bar | The folder you are currently in | ✓ | ✓ | | Start menu / task bar shortcuts | $USERPROFILE directory | ✘ System32 | ✓ | | Clicking new tab | The folder the first tab launched in | ✓ | ✘ %USERPROFILE% | In short, the new tab behaviour works as expected when the "Use parent process directory" option is enabled, however I can't use this option because it breaks the start menu shortcuts (#11834 and #878) ### Background The use-case for this is that I often want to right click a folder to open in terminal, this opens in my default shell (e.g. WSL), but sometimes I actually want to be using a different shell in this directory (Powershell). Or another example: I'm developing a project in C:\Users\jacob\projects\example, I want to right click open in terminal, and then have multiple tabs for running different tasks in the project
claunia commented 2026-01-31 05:47:01 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 30, 2022):

There's another option: You can use "Duplicate Tab" (Ctrl+Shift+D) to duplicate the current tab including its starting directory.

@lhecker commented on GitHub (May 30, 2022): There's another option: You can use "Duplicate Tab" (Ctrl+Shift+D) to duplicate the current tab including its starting directory.
claunia commented 2026-01-31 05:47:02 +00:00
Author
Owner
Copy Link

@AltitudeApps commented on GitHub (May 30, 2022):

I like to use:

wt --window 0 new-tab -d .

to start a new tab, and have it be in the same directory that the first tab is in.

wt -w 0 nt -d .

is a shortcut for the same thing. It's always in my command history, so I just use 'up-arrow' to find it.

@AltitudeApps commented on GitHub (May 30, 2022): I like to use: > `wt --window 0 new-tab -d .` to start a new tab, and have it be in the same directory that the first tab is in. > `wt -w 0 nt -d .` is a shortcut for the same thing. It's always in my command history, so I just use 'up-arrow' to find it.
claunia commented 2026-01-31 05:47:03 +00:00
Author
Owner
Copy Link

@jacob-pro commented on GitHub (May 31, 2022):

Thanks @lhecker, but the problem is that I often don't want to duplicate the tab, since I would like to swap to a different shell.

@jacob-pro commented on GitHub (May 31, 2022): Thanks @lhecker, but the problem is that I often don't want to duplicate the tab, since I would like to swap to a different shell.
claunia commented 2026-01-31 05:47:03 +00:00
Author
Owner
Copy Link

@AltitudeApps commented on GitHub (May 31, 2022):

@jacob-pro
I think I now I see what you mean.

If I have my profiles set to "Use parent process directory", things work well, except for the fact that invoking Terminal from the start menu now drops me into C:\Windows\System32. (Which is rather nostalgic.) Both C:\Windows\System32 and %USERPROFILE% meet the criteria of "almost NEVER where I want to be", so I had never noticed that being dropped into C:\Windows\System32 was inconvenient, because %USERPROFILE% is just as inconvenient for me. But I can see how System32 would be pretty irritating if you mostly needed to be in %USERPROFILE%.

However, aside from the above issue, I am able to launch a new tab into a shell of my choice, in a directory that makes sense for the current session, by using the following command (which is itself a bit inconvenient, admittedly):

wt --window 0 --profile 'Command Prompt'

Perhaps more convenient is that clicking the profile selection dropdown in Terminal and choosing a shell from there also drops me into the expected directory. (Meaning the directory that this wt.exe window was originally launched in.)

In other words, by starting the session by right-clicking on the 'directory of the day' in Windows Explorer, and choosing "Open in Terminal", things will get set up such that all other tabs opened via the Terminal GUI controls in that particular window will open in that same directory.

Launching a different shell in the same directory via a command:

image

image

Launching a different shell in the same directory via the GUI:

image

image

@AltitudeApps commented on GitHub (May 31, 2022): @jacob-pro I think I now I see what you mean. If I have my profiles set to "Use parent process directory", things work well, except for the fact that invoking Terminal from the start menu now drops me into `C:\Windows\System32`. (Which is rather nostalgic.) Both `C:\Windows\System32` and `%USERPROFILE%` meet the criteria of "almost NEVER where I want to be", so I had never noticed that being dropped into `C:\Windows\System32` was inconvenient, because `%USERPROFILE%` is just as inconvenient for me. But I can see how `System32` would be pretty irritating if you mostly needed to be in `%USERPROFILE%`. However, aside from the above issue, I am able to launch a new tab into a shell of my choice, in a directory that makes sense for the current session, by using the following command (which is itself a bit inconvenient, admittedly): > ` wt --window 0 --profile 'Command Prompt' ` Perhaps more convenient is that clicking the profile selection dropdown in Terminal and choosing a shell from there also drops me into the expected directory. (Meaning the directory that this wt.exe window was originally launched in.) In other words, by starting the session by right-clicking on the 'directory of the day' in Windows Explorer, and choosing "Open in Terminal", things will get set up such that all other tabs opened via the Terminal GUI controls in that particular window will open in that same directory. #### Launching a different shell in the same directory via a command: ![image](https://user-images.githubusercontent.com/70041186/171271656-7cb0e7e4-0dd9-4dc7-b6ec-e4759394f19b.png) ![image](https://user-images.githubusercontent.com/70041186/171271696-3292f944-46c4-487d-9717-681b978af6e9.png) #### Launching a different shell in the same directory via the GUI: ![image](https://user-images.githubusercontent.com/70041186/171271868-c33aa229-6b62-43a3-8515-65b64fbdc4e1.png) ![image](https://user-images.githubusercontent.com/70041186/171271949-f18f30e4-a002-485c-a783-bef5eb7a3bd5.png)
claunia commented 2026-01-31 05:47:04 +00:00
Author
Owner
Copy Link

@jacob-pro commented on GitHub (Jun 7, 2022):

Yep exactly @AltitudeApps if you have "Use parent process directory" set then new tabs work as expected, and as a bonus you can also run wt.exe in your explorer address bar without the -d . hack.

IMO "Use parent process directory" is how it should work by default, because that is how all other shells on Windows - cmd.exe, powershell.exe normally work.

But as I already noted this breaks the start menu / task bar shortcuts, since they seem to default to System32. Normally (if this was any Win32 application) I would just create a custom shortcut with the right starting directory set, but this doesn't work properly for Windows Apps: https://github.com/microsoft/terminal/issues/12996#issuecomment-1148048802

@jacob-pro commented on GitHub (Jun 7, 2022): Yep exactly @AltitudeApps if you have "Use parent process directory" set then new tabs work as expected, and as a bonus you can also run `wt.exe` in your explorer address bar without the `-d .` hack. IMO "Use parent process directory" is how it should work by default, because that is how all other shells on Windows - cmd.exe, powershell.exe normally work. But as I already noted this breaks the start menu / task bar shortcuts, since they seem to default to System32. Normally (if this was any Win32 application) I would just create a custom shortcut with the right starting directory set, but this doesn't work properly for Windows Apps: https://github.com/microsoft/terminal/issues/12996#issuecomment-1148048802
claunia commented 2026-01-31 05:47:04 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 7, 2022):

But as I already noted this breaks the start menu / task bar shortcuts, since they seem to default to System32.

Honestly that's like 95% of why we added startingDirectory in the first place. It remains atrocious that applications launched by "PLM" (the "Package Lifetime Manager" or whatever) start in System32.

We tried to fix it at one point, but it turned out to be even worse than we thought. You can see the damage in Mike's comment here: https://github.com/microsoft/terminal/pull/3547#issue-521851468, detailed description section.

@DHowett commented on GitHub (Jun 7, 2022): > But as I already noted this breaks the start menu / task bar shortcuts, since they seem to default to System32. Honestly that's like 95% of _why we added `startingDirectory` in the first place_. It remains atrocious that applications launched by "PLM" (the "Package Lifetime Manager" or whatever) start in System32. We tried to fix it at one point, but it turned out to be even worse than we thought. You can see the damage in Mike's comment here: https://github.com/microsoft/terminal/pull/3547#issue-521851468, detailed description section.
claunia commented 2026-01-31 05:47:04 +00:00
Author
Owner
Copy Link

@jacob-pro commented on GitHub (Jun 7, 2022):

@DHowett IMHO you should have merged that PR to open in the working directory by default, that makes almost everything work how it is expected by developers, and is consistent with CMD/Powershell, basically any other shell application.

Leave the Start Menu & Taskbar shortcuts opening in System32 problem to the Microsoft Windows team - since it is their silly problem to fix 😆 - All they need to do is give us the ability to modify the start menu shortcut to have a custom working directory, just like the shortcuts for powershell and cmd already do.

@jacob-pro commented on GitHub (Jun 7, 2022): @DHowett IMHO you should have merged that PR to open in the working directory by default, that makes almost everything work how it is expected by developers, and is consistent with CMD/Powershell, basically any other shell application. Leave the Start Menu & Taskbar shortcuts opening in System32 problem to the Microsoft Windows team - since it is their silly problem to fix 😆 - All they need to do is give us the ability to modify the start menu shortcut to have a custom working directory, just like the shortcuts for powershell and cmd already do.
claunia commented 2026-01-31 05:47:05 +00:00
Author
Owner
Copy Link

@michael-hawker commented on GitHub (Jun 23, 2022):

There's another option: You can use "Duplicate Tab" (Ctrl+Shift+D) to duplicate the current tab including its starting directory.

Hmm, I was expecting when I duplicated the tab for it to bring me to the current directory that I was in on that tab...

If I wanted to be in the starting directory, I'd just open a new tab with that profile right?

@michael-hawker commented on GitHub (Jun 23, 2022): > There's another option: You can use "Duplicate Tab" (Ctrl+Shift+D) to duplicate the current tab including its starting directory. Hmm, I was expecting when I duplicated the tab for it to bring me to the current directory that I was in on that tab... If I wanted to be in the starting directory, I'd just open a new tab with that profile right?
claunia commented 2026-01-31 05:47:05 +00:00
Author
Owner
Copy Link

@jacob-pro commented on GitHub (Jun 23, 2022):

@michael-hawker I don't think that is technically viable, since Windows Terminal supports all sorts of shells (cmd, mingw bash, wsl etc.) and there is no way / standard API for them to communicate back what directory they are currently in

@jacob-pro commented on GitHub (Jun 23, 2022): @michael-hawker I don't think that is technically viable, since Windows Terminal supports all sorts of shells (cmd, mingw bash, wsl etc.) and there is no way / standard API for them to communicate back what directory they are currently in
claunia commented 2026-01-31 05:47:05 +00:00
Author
Owner
Copy Link

@michael-hawker commented on GitHub (Jun 24, 2022):

@jacob-pro interesting, there's a discussion about it for #10232, so I wonder what they're thinking there?

@michael-hawker commented on GitHub (Jun 24, 2022): @jacob-pro interesting, there's a discussion about it for #10232, so I wonder what they're thinking there?
claunia commented 2026-01-31 05:47:05 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 24, 2022):

There actually totally is a standard way for the shell to tell the terminal about the CWD. There's no good way for the Terminal to ask, but the client app can tell the terminal. See Tutorial: Opening a tab/pane in the same directory in Windows Terminal

@zadjii-msft commented on GitHub (Jun 24, 2022): There actually totally is a standard way for the shell to tell the terminal about the CWD. There's no good way for the Terminal to _ask_, but the client app can tell the terminal. See [Tutorial: Opening a tab/pane in the same directory in Windows Terminal](https://docs.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory)
claunia commented 2026-01-31 05:47:06 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jul 8, 2022):

Ultimately, I don't think we're about to change the base behavior here. However, reading between the lines a little, the bit that gets me is:

Launched From Expected Starting Directory . Starting Directory %USERPROFILE%
Clicking new tab The folder the first tab launched in ✓ ✘ %USERPROFILE%

That's probably a pretty unique workflow, tbh, but I think there's another request on the backlog that might address it: #445. With the proposal in that thread, you'd be able to rebind the action of the new tab button. So, you could change it from just newTab to a newTab action, with the startingDirectory changed to .:

"newTabButton":
{
  "command": { "action": "newTab", "startingDirectory": "." }
}

That's probably the way I'd go about solving this, at least. I'd go upvote that thread as a potential solution here.

@zadjii-msft commented on GitHub (Jul 8, 2022): Ultimately, I don't think we're about to change the base behavior here. However, reading between the lines a little, the bit that gets me is: > | Launched From | Expected | Starting Directory . | Starting Directory %USERPROFILE% | > |------------------------------------------------|--------------------------------------|----------------------|-----------------------------------| > Clicking new tab | The folder the first tab launched in | ✓ | ✘ %USERPROFILE% That's probably a pretty unique workflow, tbh, but I think there's another request on the backlog that might address it: #445. With the proposal in that thread, you'd be able to rebind the action of the new tab button. So, you could change it from just `newTab` to a `newTab` action, with the `startingDirectory` changed to `.`: ```jsonc "newTabButton": { "command": { "action": "newTab", "startingDirectory": "." } } ``` That's probably the way I'd go about solving this, at least. I'd go upvote that thread as a potential solution here.
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 Issue-Bug Needs-Tag-Fix Needs-Triage Product-Terminal Resolution-Won't-Fix
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#17592
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?