Can we use the default host names?

[code-asher]

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:

1. So we can use vscodessh instead of ssh.
2. 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?

[EhabY]

I think (1) is already implemented and we use ssh by default unless the server is old and only supports vscodessh. As for (2), given that users can connect without our extension then it makes sense to track this from the server somehow

[code-asher]

Yeah it is tricky because there is no good way to tell from the server what kind of connection it is (I think). We have done things with JetBrains for example where we look at process names, but it is brittle. Right now the two ways we have are to add an environment variable or add --usage to the cli.

[EhabY]

Currently we just pass this as an argument as can be seen here:

vscode-coder/src/remote/remote.ts

Line 822 in a1ad85e

? `${escapeCommandArg(binaryPath)}${globalConfigs} ssh --stdio --usage-app=vscode --disable-autostart --network-info-dir ${escapeCommandArg(this.pathResolver.getNetworkInfoPath())}${await this.formatLogArg(logDir)} --ssh-host-prefix ${hostPrefix} %h`

But yes it wouldn't cover connecting directly through the Remote SSH extension, like I guess it depends on how much we care about this specifically. If we NEED it then some kind of server process parsing is a must.

[code-asher]

Yeah I know IDE tracking is a must, but I am not sure if it needs to work outside our plugin. At least so far, no one has said that it needs to work outside our plugin. 🤞