Just to be sure, you changed the directory and also ran some commands, correct?

You also should've seen

in the terminal. Did you?

Can repro at least one issue here, we're injecting a Windows path:

This is a bit of a risky change, I think we probably need to move the shell integration arg injecting over to the server so execInstallFolder uses the right OS. Or refactor how the function is organized to support pulling that path over from the other side if needed.

I think this breaks arg injection on all remotes, except for the test resolver which we tested against

Also worked on ssh

@meganrogge oh shell integration does on ssh? Are you sshing into localhost as that should work?

Yeah it works when I ssh into localhost

I believe I'm getting a similar issue when enabling the new experimental shell integration setting.
It seems it's searching for a file local to my drive although I'm currently running the terminal in a remote SSH window.
Any new terminal I open is met with the following:

zsh:1: no such file or directory: /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-zsh.sh

I still hit this. The host OS is a Windows system with Powershell 7, using remote SSH to connect to a Linux machine (that should use zsh). I just have terminal.integrated.defaultProfile.windows: Powershell in my settings.

@connor4312 this should only happen for the first terminal in the window which is tracked inhttps://github.com//issues/141753, please verify this for terminals created after the connection is done.

This seems to happen whenever I click the "+" button https://memes.peet.io/img/22-02-0f460379-9dfb-4c56-829f-78e33458ef05.mp4

Can repro, I wasn't seeing it because I had "terminal.integrated.defaultProfile.linux": "bash" set

I see this in the log which is wrong:

WARN Shell integration cannot be enabled when custom args undefined are provided for pwsh.exe.

Cause is related to this debt item: #143965

That issue is caused because we currently only resolve backend OS/remote authority after the process is created.

I pushed a fix but could only test Windows -> Windows, make sure to verify on Windows -> non-Windows (eg. WSL) or the other way around.

Shell integration works for me over Remote-SSH with the following setup:

• Host OS: Windows, Powershell 7
• Remote OS: Linux

Verified it works here too 🎉

I just noticed the following in the logs when using Remote-SSH with shell integration enabled

 WARN Shell integration cannot be enabled when custom args -c,wget --version > /dev/null
if [ $? -eq 0 ]
then
	wget --connect-timeout=7 --tries=1 --dns-timeout=7 -q  -O - http://<redacted>/latest/meta-data/instance-id
else
	curl --version > /dev/null
	if [ $? -eq 0 ]
	then
		curl --connect-timeout 7 -s  http://<redacted>/latest/meta-data/instance-id
	fi
fi
exit 0 are provided for sh.

Is this known/expected @Tyriar?

@joyceerhl yes that's expected as a warning just to call out if someone is looking that shell integration couldn't be enabled. I just improved that warnings format in a pr I have out as well.