Could we set HOME here instead?

This is what OpenSSH does as well: https://github.com/openssh/openssh-portable/blob/7cc8e150d51a4545b86d996692b541419b35d1a3/session.c#L991

Almost added it last time I was excavating here but I opted on the side of caution. 😅

We could, but then we'd be adding functionality AFAICT no one has asked for. I'd much prefer to reduce code than increase it.

I would like to push back on this. We're not adding functionality, we're fixing a bug. If you try out SSH server on Windows, the HOME environment variable will be set when you SSH in. As such we're just matching expectations and bringing our product in line.

@stirby punting to Product to make the call here. WDYT?

It's my understanding here that $HOME on windows is taboo. However, OpenSSH sets this, so we're either going to match the expectations of Windows administrators or OpenSSH users?

How does this fix a bug @mafredri? It sounds like adding functionality to satisfy this test.

It doesn't sound super compelling to keep this. I have no customer data suggesting one way or another.

I would opt to cut it.

@stirby I can't say I'm deep enough in the know to know whether or not it's taboo, but if you're running SSH on Windows, you're doing so via OpenSSH server (Windows component), which means that HOME will be set. So whether or not the client is using OpenSSH or PuTTY or what have you, HOME will be set. I was suggesting we would match this behavior as I consider its absence a bug. The OpenSSH implementation has always been our guiding light for our own SSH implementation, but if you see no value in it then let's drop it.

I'll just add that this is a very simple fix IMO, basically a one-line change (+ one relocation). Not sure why this would be classified as a feature.

diff --git agent/agentssh/agentssh.go agent/agentssh/agentssh.go
index 293dd4db1..eeb6d406c 100644
--- agent/agentssh/agentssh.go
+++ agent/agentssh/agentssh.go
@@ -895,21 +895,23 @@ func (s *Server) CreateCommand(ctx context.Context, script string, env []string,
 	cmd := s.Execer.PTYCommandContext(ctx, modifiedName, modifiedArgs...)
 	cmd.Dir = s.config.WorkingDirectory()
 
+	homedir, err := ei.HomeDir()
+	if err != nil {
+		return nil, xerrors.Errorf("get home dir: %w", err)
+	}
+
 	// If the metadata directory doesn't exist, we run the command
 	// in the users home directory.
 	_, err = os.Stat(cmd.Dir)
 	if cmd.Dir == "" || err != nil {
 		// Default to user home if a directory is not set.
-		homedir, err := ei.HomeDir()
-		if err != nil {
-			return nil, xerrors.Errorf("get home dir: %w", err)
-		}
 		cmd.Dir = homedir
 	}
 	cmd.Env = append(ei.Environ(), env...)
 	// Set login variables (see `man login`).
 	cmd.Env = append(cmd.Env, fmt.Sprintf("USER=%s", username))
 	cmd.Env = append(cmd.Env, fmt.Sprintf("LOGNAME=%s", username))
+	cmd.Env = append(cmd.Env, fmt.Sprintf("HOME=%s", homedir))
 	cmd.Env = append(cmd.Env, fmt.Sprintf("SHELL=%s", shell))
 
 	// Set SSH connection environment variables (these are also set by OpenSSH

(TBH I'd like to see this change irrespective of Windows implementation, just so we're guaranteed to set the env correctly and not be influenced by the outside environment.)

But if we don't do this, I'd at least like to see this change reverted so that we keep the HOME test (it must be set correctly on Linux/macOS), add an exception for Windows and an accompanying reason why where diverging from the OpenSSH implementation.

But if we don't do this, I'd at least like to see this change reverted so that we keep the HOME test (it must be set correctly on Linux/macOS), add an exception for Windows and an accompanying reason why where diverging from the OpenSSH implementation.

The Coder agent doesn't mess with the HOME environment variable on any platform. If it's set, then the logged in user will have it too, if not, then not. If we did what you are suggesting we'd be testing the environment and not the agent, which is not the point of these tests.

The Coder agent doesn't mess with the HOME environment variable on any platform

Yes @spikecurtis, that's exactly the bug right there. We don't, but we should. Unless HOME is set, certain software may not work or behave correctly. So far we seem to have been lucky that no customer environment initializes without HOME or a HOME set to the wrong path, or perhaps customers have figured out how to fix it on their own. I do not want us to continue relying on luck and undefined behavior.

See man login.

👍🏻