If your default shell is not bash it will still launch bash in the terminal. If I open VS Code in Windows and configure the default terminal is WSL it will launch zsh.
Linux DESKTOP-GR5DSKM 4.4.0-18362-Microsoft #1-Microsoft Mon Mar 18 12:02:00 PST 2019 x86_64 x86_64 x86_64 GNU/LinuxSteps to Reproduce:
Does this issue occur when you try this locally?: Yes.
Does this issue occur when you try this locally and all extensions are disabled?: Yes
A cascading problem that happens here is that because my aliases are in my .zshrc file they don't get loaded and things like docker (which I alias to docker.exe in Windows) don't work.
It's worth note that this is not a WSL problem, as it happens on any local system when you connect to a user@server that has a default shell other than bash. My remote machine is configured as @aaronpowell described -- zsh as the default shell with all my aliases and development tooling in my .zshrc. When I ssh into the box from a standard terminal window, I get zsh. When I connect from VSCode, I get bash and have to launch zsh manually.
I filed https://github.com/Microsoft/vscode-remote-release/issues/44 for ssh.
I've looked into this a little bit and for the meantime the workaround is to open your remote settings and set a shell there.

{
"terminal.integrated.shell.linux": "/bin/zsh"
}
After set:
{
"terminal.integrated.shell.linux": "/bin/zsh"
}
on remote server, still cannot connect it via macOS VS Code latest stable version.

But, I can connect the remote server via another Linux (Ubuntu) machine or Insider version without doing this.
@hologerry this issue was about getting the default shell to work when terminal.integrated.shell.linux is not set. It looks like you're probably setting it to /bin/zsh which does not exist on the local machine so it fails to set up the connection in a local terminal.
@Tyriar Again this issue is caused by
"terminal.integrated.env.osx": {
"PATH": ""
},
comment out this, the remote connection works ...
The PATH problem needs to be fixed in the next stable version(which is fixed in the insider version).
Most helpful comment
I've looked into this a little bit and for the meantime the workaround is to open your remote settings and set a shell there.