You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Having the set of host names generated by the CLI (coder.<workspace>) and the set of host names generated by the plugin (coder-vscode.<url>--*) causes some confusion when you mix connecting via the remote SSH plugin and connecting through our plugin.
Basically, you can get a different set of settings and recents, because VS Code thinks they are different connections (the host names are different, after all).
I believe we do this for two reasons:
So we can use vscodessh instead of ssh.
To attach an environment variable that allows us to track the connection as a VS Code connection, and not just a regular SSH connection. (Which, by the way, means that connections done with the remote SSH plugin without our plugin will not be tracked as VS Code connections!)
The first is easily solved, the JetBrains plugin already uses the regular ssh command. I think we just have to port the network info command? And this would make it usable with JetBrains as well, so win-win.
The second is trickier. We need some way to identify the connection but I am not sure how. We could track the process on the remote instead, like we do with JetBrains?
The text was updated successfully, but these errors were encountered:
Having the set of host names generated by the CLI (
coder.<workspace>
) and the set of host names generated by the plugin (coder-vscode.<url>--*
) causes some confusion when you mix connecting via the remote SSH plugin and connecting through our plugin.Basically, you can get a different set of settings and recents, because VS Code thinks they are different connections (the host names are different, after all).
I believe we do this for two reasons:
vscodessh
instead ofssh
.The first is easily solved, the JetBrains plugin already uses the regular
ssh
command. I think we just have to port the network info command? And this would make it usable with JetBrains as well, so win-win.The second is trickier. We need some way to identify the connection but I am not sure how. We could track the process on the remote instead, like we do with JetBrains?
The text was updated successfully, but these errors were encountered: