“split tab” or “duplicate tab” in ssh session

[pablomadriaga]

          If you are seeing the text "Could not access starting directory," do not set the `startingDirectory` in your SSH profile.

Originally posted by @DHowett in #25 (comment)

This is my “settings.json” and without “startingDirectory” and when I duplicate tab I do “split tab” or “duplicate tab” I still have the same problem.

    "list": 
    [
        {
            "commandline": "ssh -t [email protected]",
            "guid": "{d8fb0bf4-0044-406e-b034-6d3b91938a9b}",
            "icon": "ms-appx:///ProfileIcons/{9acb9455-ca41-5af7-950f-6bca1bc9722f}.png",
            "name": "UbuntuJP",
            "tabTitle": "Ubuntu1"
        },

the problem is:

[error 2147942667 (0x8007010b) when launching `ssh -t user@ip_server']
Could not access starting directory "/home/user"

[pablomadriaga]

I am facing an issue with Windows Terminal when duplicating or splitting a tab in an SSH session. The error I get is:
[error 2147942667 (0x8007010b) when launching ssh -t user@ip_server']
Could not access starting directory "/home/user"`

Problem Overview:

• When I open a new SSH session in Windows Terminal and connect to a Linux machine (through SSH), everything works fine. However, when I duplicate or split the tab, the error above appears.
• The problem seems related to the handling of the "startingDirectory" in the duplicated or split tab. It appears that the terminal is attempting to access the directory locally, even though it should be accessing the remote server’s directory.

Current Configuration:

• commandline: ssh -t user@ip_server
• startingDirectory: Either omitted or set to an empty string

The error occurs only when performing the tab duplication or splitting. When I first open a tab with the command above, the session works as expected. The issue arises only after duplicating or splitting the tab.

Additional Information:

• Modifying the startingDirectory in different ways (including setting it to empty, or leaving it out altogether).
• Various configurations in the SSH command line options (RemoteCommand, etc.), but the issue persists.

I would appreciate any guidance or resolution to this issue.

[DHowett]

Oh, I get it now. Sorry I redirected you away from the original issue. We'll have to spend some engineering time looking into this!