Restarting a process loses pwd #21019

Open
opened 2026-01-31 07:30:49 +00:00 by claunia · 2 comments
Owner

Originally created by @NewtonChutney on GitHub (Dec 28, 2023).

Originally assigned to: @zadjii-msft on GitHub.

Windows Terminal version

1.18.3181.0

Windows build number

10.0.22631.2861

Other Software

No response

Steps to reproduce

  1. Set exit behaviour in Terminal to never close automatically by default
    "profiles": 
    {
        "defaults": 
        {
            "closeOnExit": "never", 
    ...
  1. Launch a terminal app (a shell/cli editor) from the address bar in File Explorer
  2. close it
  3. press enter to restart

Expected Behavior

The respawned process should have the same environment as the original process.

Actual Behavior

The respawned process launches with the default launch directory of WT, C:\WINDOWS\system32>

https://github.com/microsoft/terminal/assets/70827815/3923ba36-08f6-4b8d-ba21-bd8ce1a5b227

Originally created by @NewtonChutney on GitHub (Dec 28, 2023). Originally assigned to: @zadjii-msft on GitHub. ### Windows Terminal version 1.18.3181.0 ### Windows build number 10.0.22631.2861 ### Other Software _No response_ ### Steps to reproduce 1. Set exit behaviour in Terminal to never close automatically by default > ```json > "profiles": > { > "defaults": > { > "closeOnExit": "never", > ... > ``` 2. Launch a terminal app (a shell/cli editor) from the address bar in File Explorer 3. close it 4. press enter to restart ### Expected Behavior The respawned process should have the same environment as the original process. ### Actual Behavior The respawned process launches with the default launch directory of WT, `C:\WINDOWS\system32>` https://github.com/microsoft/terminal/assets/70827815/3923ba36-08f6-4b8d-ba21-bd8ce1a5b227
claunia added the Issue-BugProduct-TerminalArea-TerminalControl labels 2026-01-31 07:30:49 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Jan 3, 2024):

Okay, so this isn't shell integration related. I bet this regressed in 1.18. We probably still need to initially seed the TermControl's CWD with the "virtual cwd" we used at the time we created that control, ala #15280

(you could probably work around this today by having your shell manually tell the Terminal about the CWD: https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory)

@zadjii-msft commented on GitHub (Jan 3, 2024): Okay, so this isn't shell integration related. I bet this regressed in 1.18. We probably still need to initially seed the TermControl's CWD with the "virtual cwd" we used at the time we created that control, ala #15280 (you could probably work around this today by having your shell manually tell the Terminal about the CWD: https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory)
Author
Owner

@TGSAN commented on GitHub (Jan 6, 2024):

Okay, so this isn't shell integration related. I bet this regressed in 1.18. We probably still need to initially seed the TermControl's CWD with the "virtual cwd" we used at the time we created that control, ala #15280

(you could probably work around this today by having your shell manually tell the Terminal about the CWD: https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory)

Maybe this is related to the “issue reappears after update 1.18” that occurred in #15173 ?

@TGSAN commented on GitHub (Jan 6, 2024): > Okay, so this isn't shell integration related. I bet this regressed in 1.18. We probably still need to initially seed the TermControl's CWD with the "virtual cwd" we used at the time we created that control, ala #15280 > > (you could probably work around this today by having your shell manually tell the Terminal about the CWD: https://learn.microsoft.com/en-us/windows/terminal/tutorials/new-tab-same-directory) Maybe this is related to the “issue reappears after update 1.18” that occurred in #15173 ?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#21019