Remote code command precedence on PATH

[SteelPhase]

• VSCode Version: 1.53.1
• Local OS Version: Windows 10 20H2
• Remote OS Version: macOS Catalina 10.15.7
• Remote Extension/Connection Type: SSH

I am using remote ssh to connect to a machine that already has vscode installed on it. It seems that the local vscode code command takes presidence in the path over the remote vscode's code command. on macos the local code is located in /usr/local/bin/code.

Is there a way to have remote-ssh handle this situation to prefer the remote code command. I'm not entirely sure if this is a bug, or a misconfiguration on my end.

[nrcrast]

@SteelPhase did you ever solve this? I know previously I have gotten this to work just fine in Linux remote OS configurations. I'm struggling a bit with this on my Mac right now though.

[SteelPhase]

I have a real hacky work around right now

if [[ ! -z VSCODE_IPC_HOOK_CLI ]]; then
    REMOTE_CODE_BIN_PATH=$(echo $PATH | tr ':' '\n' | grep "/Users/steelphase/.vscode-server/bin/.*/bin")
    if [[ -d $REMOTE_CODE_BIN_PATH ]]; then
        NEW_PATH=$(echo $PATH | sed -e "s~:$REMOTE_CODE_BIN_PATH~~g")
        export PATH="$REMOTE_CODE_BIN_PATH:$NEW_PATH"
    fi
fi

[nrcrast]

Lol I was just about to come in and post something similar!

if [[ ! -z VSCODE_IPC_HOOK_CLI ]]; then
	for i in $(ls ~/.vscode-server/bin); do
		export PATH=$HOME/.vscode-server/bin/$i/bin:$PATH
	done
fi

[roblourens]

If you have a bashrc or other terminal config file that adds code to the PATH, it might override our PATH modification. Do you? What is echo $PATH

[SteelPhase]

I stated that in my initial comment. VSCode is installed on the target system, and I executed Shell Command: Install 'code' command in path for it on the target system. This means that the code command for the local instance of vscode on the target system will be added to the path. It appears that VSCode installs drops that code binary into /usr/local/bin/code

This is an unavoidable situation if the target system you are remoting into has VSCode installed and the code command configured.

Remote-SSH will need to make sure that it's code command takes precedence in the path, by prepending the equivalent of ~/.vscode-server/bin/.*/bin to the path instead of appending it.

[roblourens]

So we do already do this, but your own scripts will still take precedence when starting the terminal, so it's likely that your bashrc either replaces PATH entirely or prepends /usr/local/bin so it comes before the entry that we prepend - this is what I've seen when this has come up before.

And a new issue that occurred to me is that if you have disabled the setting terminal.integrated.inheritEnv, then our entry will also be missing. But there is a new mechanism that I can adopt to fix this part at least.

[SteelPhase]

That is incorrect. /usr/local/bin is added to the path by /etc/profile when /usr/libexec/path_helper is executed. path_helper reads /etc/paths and /etc/paths.d to build a PATH environment variable. Current versions of macOS have /usr/local/bin as the top entry in /etc/paths

This is default OS behaviour, not a user configuration issue. If you want your code command to work correctly, you need to prepend to the system path.

[roblourens]

Apologies, I guess I didn't realize that this just doesn't work on mac remotes. I do see /Users/roblou/.vscode-server-insiders/bin/42e27fe5cdc58539dad9867970326a297eb8cacf/bin in the PATH but after the system paths.

As far as I know, this should only be set for the remote server's environment, not whole the system path. Is there no way to do that? I don't want to affect local terminals outside of vscode remote, or other remote connections.

[SteelPhase]

I'm not sure how vscode sets the path when connecting to a remote, and i'm assuming it's not public. I'd assume that there would need to be a step after the shell inits that sets the path. This would have the benefit of already having the shell path fully loaded. If this code is available somewhere, I can try and make a more concise suggestion.

[roblourens]

We simply set the PATH of the vscode remote server process, then the terminals inherit that environment. In my testing, I see that even if I modify the initial environment that the terminal process is spawned with, the system path is applied after that. So I think the only way for us to take precedence would be to run some code in the terminal itself after it is set up, which I wouldn't do.

[SteelPhase]

My janky little hack above has solved this in the mean time. Maybe this is just going to be a bug in this specific scenario. I don't know how many people are really going to target a system that already has vscode installed locally.

[connor4312]

@eleanorjboyd bumping this issue's visibility to you 🙂 with the code-server "connect to your home machine" sort of story, we're seeing people hit this more often

[roblourens]

@connor4312 you are just seeing this for mac remotes right? From my last comment, it sounds like there is something different about when PATH is set on mac? Not sure how we can fix this from vscode.

[connor4312]

Yea, just on a mac.

This should be solvable in some way--maybe needs integration with the integrated terminal in core, perhaps.

[wtdcode]

Same here and looks like the code executable now goes to ~/.vscode-server/bin/6c3e3dba23e8fadc360aed75ce363ba185c49794/bin/remote-cli/code

[jmineau]

I'm coming from #9482, where I am having this issue when connecting to a fresh install of Raspberry Pi OS Lite from windows.

[j-silv-ti]

Lol I was just about to come in and post something similar!

if [[ ! -z VSCODE_IPC_HOOK_CLI ]]; then
	for i in $(ls ~/.vscode-server/bin); do
		export PATH=$HOME/.vscode-server/bin/$i/bin:$PATH
	done
fi

For anyone experiencing this in 2024, here is a c-shell equivalent hack (added to .cshrc_user) with VS code's updated directory structure. I had to add this because my .cshrc file which my organization manages was overwriting my $path

if ( $?VSCODE_IPC_HOOK_CLI ) then
  	foreach i (`ls -d ~/.vscode/cli/servers/*/ --indicator-style=none`)
		  set path = ( $i'server/bin/remote-cli' $path )
	  end
endif