Other options for overriding profile starting directory

Description of the new feature/enhancement

The new command line arg for specifying starting directory is great but it's limited to individual panes and tabs created during launch. I'd like additional ways of specifying starting directories for panes/tabs, particularly those that get created after launch. Here's two additions I think would be useful:

Window-wide starting directory command line argument

Starting a terminal with wt --windowStartingDirectory "c:\my\project\dir" would cause all tabs/panes opened during the life of that terminal window to start in c:\my\project\dir. This is useful for opening a terminal window directly in a deeply nested project directory and then quickly and easily opening/closing additional panes/tabs in that location. This should also apply to all panes/tabs created via initial command line args that don't have an individual --startingDirectory specified.

You can more or less achieve this right now by setting a profile's starting directory to . and starting wt.exe itself with the actual desired starting directory as working directory. However this requires a more complicated launch, eg. cmd /C start /D "c:\my\project\dir" wt. You also lose the ability to keep a useful default starting directory in the profile's settings for a simple launch of wt.exe.

newTab and splitPane keybind options for reusing current directory

An additional option for the newTab/splitPane keybindings could open these with starting directory set to the current working directory of the current tab/pane. Useful if you open a terminal, eventually cd to some directory, and then want additional panes/tabs in that directory.

These would be additions to a prioritized list where the tab/pane being created uses the highest priority starting directory that was provided, eg:

reuse current directory via keybind
--startingDirectory command line argument
--windowStartingDirectory command line argument
profile starting directory
wt.exe working directory

For newTab and splitPane, that's tracked by #3158. For windowStartingDirectory, I'm not sure I agree that Terminal should be the arbiter here: it seems like the issue is more correctly solved by fixing #878 (it's closed, but I do not know how I feel about that) or setting the startingDirectory in all your profiles to null (which is easily doable with the defaults key) and then simply starting WT in the desired directory. It's never going to be perfect, but neither is a big-hammer global override switch.

I'm concerned about the veritable pandora's box of features that opens up as well: if we can override startingDirectory at an app level for all profiles started under a window, why not padding? background image? But then, why have a profile system at all?

This likely warrants further discussion. 😄

I hadn't seen #3158 when I was looking around, that appears to cover newTab and splitPane.

I think you're right adding windowStartingDirectory as a global override of profile-specific settings would be an overreach and potentially confusing.

The startingDirectory behavior I'm kind of emulating is tmux usage where there are various means of controlling the working directory of a session both at and after launch. With terminal I have all of my profiles' startingDirectory set to "." (the provided json schema warns if I specify a non-string and this seems to work for inheriting terminal's working directory, though it appears null also works as you suggest). I find the ergonomics currently aren't great though in both lacking a configurable default and necessitating launching via cmd.exe/powershell.exe etc. to specify a working directory in various other circumstances.

For defaults, just launching from the standard shortcut in start menu / task bar uses c:\windows\system32 (virtually never useful to me) whereas typing wt in the windows run dialog starts in %USERPROFILE% (better, but not the default I actually want). I'm not actually sure if there's a clean way to change the working directory used when launching via task bar at all. I can create my own shortcut to %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\wt.exe, give that a starting directory and pin it to the task bar... but terminal instances unfortunately aren't grouped under that taskbar icon.

Maybe a better approach that still covers what I'm hoping for would be an optional defaultWorkingDirectory in the global settings that could be overridden by an optional --workingDirectory command line arg?

In Ubuntu, when I press ctrl+alt+T, the terminal will launch at user home. Additionally, I can launch the terminal at current directory by context menu "Open in terminal. I would like windows terminal can do the same whether or not by overriding profile starting directory. That is "launch from task bar will be at user home` and context menu for current directory".

waahoo (@waahoo)

waahoo (@waahoo) you might be interested in #878. Specifically, this: #878 (comment), and the PR #3547, and the investigation that was done in that PR.

Copying my post from #9991, which was basically the same thing

What if we had something like:
{
    "ignoreStartingDirectories": bool,
}
as a global setting? Then we'd just never use the startingDirectory for a profile, and always use the CWD of the Terminal. That seems like a big hammer, but there might be folks who are all setting "startingDirectory": "." for all their profiles, where this would be an easier solution.

Alternatively: What about wt --cwd C:\foo new-tab? That would make sure that the Terminal's CWD is set to C:\foo, not just the CWD of that tab. That would work better for things like the context menu, that might want subsequent tabs to open in the same CWD, but poorly for wt -w 0 --cwd C:\foo nt

Use a "virtual CWD" for each terminal window (#15280)

Add an action to display toast with the CWD of the Terminal (#15282)

I would call the current situation the “default directory madness”:

I have the PowerShell default profile set to start in %USERPROFILE% to prevent opening in otherwise useless system32 (this applies to all my WSL2 profiles too, which are set to start in WSL2 home directory ~). This default is used when I click on the pinned Terminal icon on the taskbar.
Because the default profile opens in the fixed place, I cannot use wt command to open terminal in the parent process directory. Thus, I have a batch file wtd.cmd with wt -d . %* in it, which opens the Terminal in the current directory. I use this to open the terminal from Double Commander for example.
When I want to open another terminal in the same directory, I need to use a non-default profile, which has the “Use parent process directory” enabled (this applies to all my WSL2 profiles too).

So in summary: I doubled every profile and I also created a script to actually open the terminal.

The following behaviour would cover my use case:

Pinned Terminal app opens in user's home directory, which is either %USERPROFILE% for Windows apps (PowerShell/cmd.exe/Developer Command Prompt...), or ~ (for WSL2).
Every new Terminal window opens in the parent process directory.
Terminal started from an app (like Double Commander) opens in the parent process directory.

Interesting issue with the start in parent process directory option - if you subsequently delete that directory, you cannot start another tab without an error (this example is with Command Prompt as the default):

[error 2147942667 (0x8007010b) when launching `%SystemRoot%\System32\cmd.exe']
Could not access starting directory "C:\MyRecentlyDeletedDirectory"

On Windows 11 23H2 (OS Build 22631.3880) with Windows Terminal 1.20.11781.0

Use Case: Split with Different Profile, Inherit Working Directory

Current Limitation:

I have a custom Windows Terminal profile (e.g., "Rate Validation") that:

Launches a specific tool (perles)
Has a fixed startingDirectory set to my project root
Has custom tab color and title

What I want:

Open the "Rate Validation" profile from the dropdown
Manually split the pane (Alt+Shift+-)
Have the new pane use the default PowerShell profile
But start in the same directory as the parent pane (my project root)

Current Behavior:

Using "splitMode": "duplicate" inherits the directory ✅ but duplicates the profile ❌ (launches perles twice)
Using default split with different profile opens in %USERPROFILE% ❌
Setting PowerShell's startingDirectory to null opens in system32 ❌

Desired Behavior:

Add a splitMode option like "inheritDirectory" that:

{
  "command": {
    "action": "splitPane",
    "split": "horizontal",
    "profile": "PowerShell",
    "splitMode": "inheritDirectory"
  },
  "keys": "alt+shift+minus"
}

This would:

Open the specified profile (PowerShell)
In the current working directory (inherited from parent pane)
Without duplicating the parent profile's commandline

Workaround Attempted:

Setting profile's startingDirectory to . doesn't work because it resolves relative to where Windows Terminal was launched from, not the current pane's directory.

Related: This would also be useful for cross-profile workflows (e.g., opening WSL bash in the same directory as a PowerShell pane).

The situation is not better in any way after 6 years. The default for PowerShell changed to fixed %USERPROFILE%, which sucks, because people probably complained that starting in System32 sucks too. Are there any plans to fix this? Like ignoring Parent process path when the parent is main system's explorer.exe instance (do I hear complains that explorer.exe is once a Start Menu and Window Manager and once a File Browser and that it sucks? 😅) and using %USERPROFILE% instead?

settings.json on shift click - https://learn.microsoft.com/en-us/windows/terminal/customize-settings/startup
shell integration, context menu for explorer - https://learn.microsoft.com/en-us/windows/terminal/tutorials/shell-integration

wt, wt -d . from explorer still issue for CWD(current working directory),

directly powershell.exe, pwsh.exe without Terminal app is less broken... for CWD, on default install - if allowed to run pwsh(startup directory is null by default in settings.json, not in profiles)

but customize settings for bash, new-tab {first link} brings this question for review and quest how to allocate funds to brainware.

function prompt {
  $loc = $executionContext.SessionState.Path.CurrentLocation;

$out = ""
  if ($loc.Provider.Name -eq "FileSystem") {
    $out += "$([char]27)]9;9;`"$($loc.ProviderPath)`"$([char]27)\"
  }
  $out += "PS $loc$('>' * ($nestedPromptLevel + 1)) ";
  return $out
}

and then still some cwd issue to open powershell from explorer context menu - IE disabled by default, including ms office ieunit4 trying to bypass windows security and somehow powershell trying to use some profile ack to diminish powershell user requests... COM+ dotnet there waiting for null.

Navigation Menu

Repository navigation

Other options for overriding profile starting directory #4637

Description of the new feature/enhancement

Window-wide starting directory command line argument

newTab and splitPane keybind options for reusing current directory

7 remaining items

Use Case: Split with Different Profile, Inherit Working Directory

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Other options for overriding profile starting directory #4637

Description

Description of the new feature/enhancement

Window-wide starting directory command line argument

newTab and splitPane keybind options for reusing current directory

Activity

DHowett-MSFT commented on Feb 24, 2020

krage commented on Feb 24, 2020

waahoo commented on Mar 21, 2020

zadjii-msft commented on Mar 21, 2020

zadjii-msft commented on Dec 9, 2021

7 remaining items

oldium commented on Jun 26, 2024

ColinPMTCG commented on Aug 26, 2024

NotMyself commented on Jan 15, 2026

Use Case: Split with Different Profile, Inherit Working Directory

oldium commented on Jan 15, 2026

hifron commented on Aug 16, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions