We do this in our VS Code Extension now :)

This issue is becoming stale. In order to keep the tracker readable and actionable, I'm going close to this issue in 7 days if there isn't more activity.

When I SSH into a stopped workspace (e.g. ssh coder.ben-stable), the workspace starts and streams the build log until it is finished. Then, the SSH connection starts. No need for the user to confirm. They clearly want to access their workspace.

It will be very challenging to achieve this flow with ssh (e.g. OpenSSH). I think we already support a lot of it with coder ssh.

The problem with OpenSSH is that it calls coder as a ProxyCommand, which is supposed to make a connection to the workspace.

1. Anything we write to stdout is meant to be the SSH protocol, not random text like build logs. We could try writing to stderr instead; I'm not sure what OpenSSH will do with it. It might not do anything and the user is stuck with no feedback that a build is happening behind the scenes.
2. OpenSSH likely sets a connection timeout on the ProxyCommand. If we are busy building the workspace, we are likely going to bump up against this timeout. Combined with the above issue, it might just look like a network problem instead of it being that the workspace was switched off.

@spikecurtis We already show provisioner/startup logs during SSH if the workspace is still starting, so I think it should work 🤔. Unless there's some scenarios in which it doesn't work. (The logs are indeed output to stderr for the ProxyCommand, and show up in the terminal.)

The config-ssh command also sets ConnectionTimeout to 0, so there's nothing to worry about there.

Do we necessarily always want to autostart? In v1 we had a command prompt ask if you wanted to start the workspace (only worked with coder ssh).

It feels a bit strange to me to assume the user always wants the workspace auto started.

I don't want to assume that this would be the case for every user, but we lean on our workspace suspension TTLs to clean up idle workspaces. The cost of starting a workspace is lower for us than additional friction for our users. Users will "fire" us if there is too much friction vs their pre-Coder workflows and habits.

I'd suggest that we do the most intuitive thing by giving the user what they and/or their IDE has requested. The user doesn't care about the infrastructure (starting, stopping, etc), they just want to do their dev work.

You could then add an option if there's enough user feedback to warrant the investment.

@Emyrk I'm of the mind it should be a config-ssh option. It'd probably make sense to have it be the default (or use a deployment default) to auto-start given that if you're trying to SSH in, you're probably going to start it anyway. But admins may want to disallow this and users may not always want it happening.

@mafredri if it is some sort of "opt in", then I think we can have the coder proxy command run the start, and delay the initial ssh.

I do agree there is the problem of presenting feedback to the user that this is happening, but it sounds easier than the "prompt" problem.

@mafredri if it is some sort of "opt in", then I think we can have the coder proxy command run the start, and delay the initial ssh.

@Emyrk I'd lean towards opt-out, but essentially yes. Btw, we already delay the SSH command so everything should be in place except the autostart.

I do agree there is the problem of presenting feedback to the user that this is happening, but it sounds easier than the "prompt" problem.

What's the problem, exactly? Yes, we can't prompt, but we can display output and already do. See the following recording:

To give some feedbacks about our use cases, we're more interested in the auto-start when accessing an app. This would allow a friction-less experience to developers that use the online IDE. Also, this would make our review process a lot more easier.
A feature comparable to what it's already done on Github Codespaces or Gitpod would be perfect!
Thank you all for your amazing work!
Let me know if you need more info about our usecases.