starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Other options for overriding profile starting directory #6514

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

Originally created by @krage on GitHub (Feb 18, 2020).

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:

  1. reuse current directory via keybind
  2. --startingDirectory command line argument
  3. --windowStartingDirectory command line argument
  4. profile starting directory
  5. wt.exe working directory
Originally created by @krage on GitHub (Feb 18, 2020). ## 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: 1. reuse current directory via keybind 2. `--startingDirectory` command line argument 3. `--windowStartingDirectory` command line argument 4. profile starting directory 5. `wt.exe` working directory
claunia added the Product-TerminalIssue-ScenarioArea-Commandline labels 2026-01-31 00:40:42 +00:00
claunia commented 2026-01-31 00:40:43 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Feb 24, 2020):

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. 😄

@DHowett-MSFT commented on GitHub (Feb 24, 2020): 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. :smile:
claunia commented 2026-01-31 00:40:43 +00:00
Author
Owner
Copy Link

@krage commented on GitHub (Feb 24, 2020):

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?

@krage commented on GitHub (Feb 24, 2020): 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?
claunia commented 2026-01-31 00:40:44 +00:00
Author
Owner
Copy Link

@waahoo commented on GitHub (Mar 21, 2020):

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 commented on GitHub (Mar 21, 2020): 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".
claunia commented 2026-01-31 00:40:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 21, 2020):

@waahoo you might be interested in #878. Specifically, this: https://github.com/microsoft/terminal/issues/878#issuecomment-579508860, and the PR #3547, and the investigation that was done in that PR.

@zadjii-msft commented on GitHub (Mar 21, 2020): @waahoo you might be interested in #878. Specifically, this: https://github.com/microsoft/terminal/issues/878#issuecomment-579508860, and the PR #3547, and the investigation that was done in that PR.
claunia commented 2026-01-31 00:40:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 9, 2021):

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

@zadjii-msft commented on GitHub (Dec 9, 2021): Copying my post from #9991, which was basically the same thing > What if we had something like: > > ```json > { > "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`
claunia commented 2026-01-31 00:40:44 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 19, 2022):

From @UmbralReaper in #12200

I like to start windows terminal through the search function in the taskbar, or through PowerToys Run. However, both of these end up in undesirable starting locations when windows terminal inherits the parent process (C:\Windows\System32 and ~\AppData\Local\Microsoft\WindowsApps, respectively). However, setting a more desirable default start location (such as %USERPROFILE) prevents inheriting the location when it is useful.

I propose that you allow setting aliases for start locations in settings.

{
    "start_aliases": {
        "C:\\Windows\\System32": "%USERPROFILE%",
        "%USERPROFILE%\\AppData\\Local\\Microsoft\\WindowsApps": "%USERPROFILE%"
    }
}
@zadjii-msft commented on GitHub (Jan 19, 2022): _From @UmbralReaper in #12200_ > I like to start windows terminal through the search function in the taskbar, or through PowerToys Run. However, both of these end up in undesirable starting locations when windows terminal inherits the parent process (`C:\Windows\System32` and `~\AppData\Local\Microsoft\WindowsApps`, respectively). However, setting a more desirable default start location (such as `%USERPROFILE`) prevents inheriting the location when it is useful. > > I propose that you allow setting aliases for start locations in settings. > ```json > { > "start_aliases": { > "C:\\Windows\\System32": "%USERPROFILE%", > "%USERPROFILE%\\AppData\\Local\\Microsoft\\WindowsApps": "%USERPROFILE%" > } > } > ```
claunia commented 2026-01-31 00:40:45 +00:00
Author
Owner
Copy Link

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

Some notes: a work in progress 🏗️

Scenarios

  • A: "Use parent process directory" still works after the 1.18 process model changes (untracked)
  • B: "The terminal doesn't lock the directory it was started in" (#5506)
  • C: Ctrl+clicking on a "Use parent process directory" profile starts it in the original terminal's CWD. (#15173)
  • D: The user can set the CWD of the Terminal itself (#4637)
  • E: The user can change the CWD of the terminal itself (#4637)
  • F: An auto-elevate default profile, with a "Use parent process directory" profile, should inherit the CWD that the terminal was ORIGINALLY started with (before it was auto-elevated) (#14817)
  • G: I want to use the CWD of the current tab/pane in a newTab/splitPane: ALREADY POSSIBLE, see Opening a tab or pane in the same directory in Windows Terminal

Scenario A & B

"Use parent process directory" still works after the 1.18 process model changes
"The terminal doesn't lock the directory it was started in"

  • I'm gonna give each window a "virtual working directory".
  • startingDirectorys will be evaluated relative to that
  • running wt -w new in c:\some\path will set that window's virtual CWD to c:\some\path
  • The terminal will always use c:\windows\system32 as it's actual CWD
  • "Use parent process directory" I suppose now just means "use the window's CWD"

This is in 816f8b202

Warning

Breaking change‼️

This will break a profile like

            {
                "commandline": "media-test.exe",
                "hidden": false,
                "name": "Use CWD for media-test",
                "startingDirectory": "."
            },

if the user right-clicks "open in terminal", then attempts to open that profile. UNLESS we do some work down in D/E

Scenario C

Ctrl+clicking on a "Use parent process directory" profile starts it in the original terminal's CWD.

Okay, I've got a possible solution, but I think I ended up building it on top of #5506, and that might be too much to pull in this late in the release.

Basically, the simple idea is:

  • Manually pass the evaluated CWD to _OpenElevatedWT,
  • so that we launch elevate-shim new-tab -p {guid} -d <path>.
  • That'll then ShellExecute({ "shell:AppsFolder\...", "new-tab -p {guid} -d <path>"}),
  • and then the elevated window would treat that as "manually start this profile with the CWD <path>"

I deeply worry that'll cause mysterious edge cases with like, c:\ or other string escaping nonsense.

A 1.18 version of this, which builds on A&B, is in 3d1611f78

Scenario D & E

The user can set & change the CWD of the terminal itself

A couple new features:

  • wt --initialCwd c:\foo: New wt-level parameter. When starting terminal, set the CWD to c:\foo. Does nothing if running this in an existing window.
  • wt change-directory c:\bar: A new wt subcommand. Change the Terminal's virtual CWD to c:\bar. This would work for other windows, the current window
  • displayTerminalCwd: new action. pop a toast to display the Terminal's own CWD
  • changeTerminalCwd: new action.
    • With a path: Set the terminal's virtual CWD to that path.
    • Without a path: Open a window-renamer-esque toast for repathing the terminal itself.

displayTerminalCwd toast is in 072620625

Potential fix for the C break

We change the shell extension to call wt --initialCwd <path> instead of wt -d <path>. This will make the shell extension open the new Terminal window in the provided CWD, rather than just the tab.

Scenario F

An auto-elevate default profile, with a "Use parent process directory" profile, should inherit the CWD that the terminal was ORIGINALLY started with (before it was auto-elevated)

  • We launch elevate-shim --initialCwd <terminal's CWD> new-tab -p {guid} -d <path>.
    • This will set the elevated Terminal's cwd to whatever the CWD of the spawning terminal.
    • Subsequent "use parent process" profiles will work as expected in that window
    • If you've got the Terminal set to "attach to the most recently used window", then this won't change the CWD of an existing elevated Terminal window, but it will open the new tab in that directory

Planning

  • A is a severe regression in 1.18
  • C is a major regression in 1.16
  • F might be a regression in 1.16 (unconfirmed if it ever worked)

A & B can be done for 1.18, with mild risk.
C can be done on top of A&B, for 1.18, with mild risk. Unclear if a similar fix would work for a 1.17 servicing release.
D,E,F all seem too risky for 1.18 at this point, but could be early 1.19 features.

References

Lemme just cross link a bunch of threads. I used to have a better mental map for this problem space. I thought there was one for "Set Terminal's CWD" but I can't find that now.

  • #5506
    • ye olde "Terminal's actual CWD should be system32 always and it should maintain a virtual CWD"
  • #14817
    • not super relevant, really only for admin/elevated
  • #9991
    • which points at...
  • #4637
    • This was the thread I was looking for!
  • #445
    • Has other relevant thoughts on the matter
@zadjii-msft commented on GitHub (May 2, 2023): Some notes: _a work in progress 🏗️_ ## Scenarios * **A**: "Use parent process directory" still works after the 1.18 process model changes (_untracked_) * **B**: "The terminal doesn't lock the directory it was started in" (#5506) * **C**: Ctrl+clicking on a "Use parent process directory" profile starts it in the original terminal's CWD. (#15173) * **D**: The user can set the CWD of the Terminal itself (#4637) * **E**: The user can _change_ the CWD of the terminal itself (#4637) * **F**: An auto-elevate default profile, with a "Use parent process directory" profile, should inherit the CWD that the terminal was ORIGINALLY started with (before it was auto-elevated) (#14817) * **G**: I want to use the CWD of the current tab/pane in a `newTab`/`splitPane`: ALREADY POSSIBLE, see [Opening a tab or pane in the same directory in Windows Terminal](https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory) ### Scenario A & B _"Use parent process directory" still works after the 1.18 process model changes_ _"The terminal doesn't lock the directory it was started in"_ > * I'm gonna give each window a "virtual working directory". > * `startingDirectory`s will be evaluated relative to that > * running `wt -w new` in `c:\some\path` will set _that window_'s virtual CWD to `c:\some\path` > * The terminal will always use `c:\windows\system32` as it's _actual_ CWD > * "Use parent process directory" I suppose now just means "use the window's CWD" This is in 816f8b202 > **Warning** Breaking change‼️ This will break a profile like ```json { "commandline": "media-test.exe", "hidden": false, "name": "Use CWD for media-test", "startingDirectory": "." }, ``` if the user right-clicks "open in terminal", then attempts to open that profile. UNLESS we do some work down in D/E ### Scenario C _Ctrl+clicking on a "Use parent process directory" profile starts it in the original terminal's CWD._ > Okay, I've got a possible solution, but I think I ended up building it on top of #5506, and that might be too much to pull in this late in the release. > > Basically, the simple idea is: > * Manually pass the _evaluated_ CWD to `_OpenElevatedWT`, > * so that we launch `elevate-shim new-tab -p {guid} -d <path>`. > * That'll then `ShellExecute({ "shell:AppsFolder\...", "new-tab -p {guid} -d <path>"})`, > * and then the elevated window would treat that as "manually start this profile with the CWD `<path>`" > > I deeply worry that'll cause mysterious edge cases with like, `c:\` or other string escaping nonsense. A 1.18 version of this, which builds on A&B, is in 3d1611f78 ### Scenario D & E _The user can set & _change_ the CWD of the terminal itself_ A couple new features: * `wt --initialCwd c:\foo`: New `wt`-level parameter. When starting terminal, set the CWD to `c:\foo`. Does nothing if running this in an existing window. * `wt change-directory c:\bar`: A new `wt` subcommand. Change the Terminal's virtual CWD to `c:\bar`. This would work for other windows, the current window * `displayTerminalCwd`: new action. pop a toast to display the Terminal's own CWD * `changeTerminalCwd`: new action. * With a `path`: Set the terminal's virtual CWD to that path. * Without a `path`: Open a window-renamer-esque toast for repathing the terminal itself. `displayTerminalCwd` toast is in 072620625 #### Potential fix for the **C** break We change the shell extension to call `wt --initialCwd <path>` instead of `wt -d <path>`. This will make the shell extension open the new Terminal window in the provided CWD, rather than _just_ the tab. ### Scenario F _An auto-elevate default profile, with a "Use parent process directory" profile, should inherit the CWD that the terminal was ORIGINALLY started with (before it was auto-elevated)_ * We launch `elevate-shim --initialCwd <terminal's CWD> new-tab -p {guid} -d <path>`. * This will set the elevated Terminal's cwd to whatever the CWD of the spawning terminal. * Subsequent "use parent process" profiles will work as expected in that window * If you've got the Terminal set to "attach to the most recently used window", then this _won't_ change the CWD of an existing elevated Terminal window, but it will open the new tab in that directory ## Planning * A is a severe regression in 1.18 * C is a major regression in 1.16 * F might be a regression in 1.16 (unconfirmed if it ever worked) A & B can be done for 1.18, with mild risk. C can be done on top of A&B, for 1.18, with mild risk. Unclear if a similar fix would work for a 1.17 servicing release. D,E,F all seem too risky for 1.18 at this point, but could be early 1.19 features. ### References Lemme just cross link a bunch of threads. I used to have a better mental map for this problem space. ~I thought there was one for "Set Terminal's CWD" but I can't find that now.~ * #5506 * ye olde "Terminal's actual CWD should be `system32` always and it should maintain a virtual CWD" * #14817 * not super relevant, really only for admin/elevated * #9991 * which points at... * #4637 * This was the thread I was looking for! * #445 * Has other relevant thoughts on the matter
claunia commented 2026-01-31 00:40:45 +00:00
Author
Owner
Copy Link

@oldium commented on GitHub (Jun 26, 2024):

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

  1. 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.
  2. 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.
  3. 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:

  1. 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).
  2. Every new Terminal window opens in the parent process directory.
  3. Terminal started from an app (like Double Commander) opens in the parent process directory.
@oldium commented on GitHub (Jun 26, 2024): I would call the current situation the “default directory madness”: 1. 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. 2. 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. 3. 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: 1. 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). 2. Every new Terminal window opens in the parent process directory. 3. Terminal started from an app (like Double Commander) opens in the parent process directory.
claunia commented 2026-01-31 00:40:45 +00:00
Author
Owner
Copy Link

@ColinPMTCG commented on GitHub (Aug 26, 2024):

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

@ColinPMTCG commented on GitHub (Aug 26, 2024): 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
claunia commented 2026-01-31 00:40:45 +00:00
Author
Owner
Copy Link

@NotMyself commented on GitHub (Jan 15, 2026):

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:

  1. Open the "Rate Validation" profile from the dropdown
  2. Manually split the pane (Alt+Shift+-)
  3. Have the new pane use the default PowerShell profile
  4. 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).

@NotMyself commented on GitHub (Jan 15, 2026): ## 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:** 1. Open the "Rate Validation" profile from the dropdown 2. Manually split the pane (`Alt+Shift+-`) 3. Have the new pane use the **default PowerShell profile** 4. 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: ```json { "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).
claunia commented 2026-01-31 00:40:45 +00:00
Author
Owner
Copy Link

@oldium commented on GitHub (Jan 15, 2026):

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?

@oldium commented on GitHub (Jan 15, 2026): 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?
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-Commandline Issue-Scenario 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#6514
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?