This message isn't quite right. We can end up here, if there's an issue with closing Teams, which in some cases, like on my work mac, requires running CLI with sudo (I wonder btw. if we could run into the same on Windows where we might need to run the command in an Admin terminal process). Let's make a distinction between Teams not running (which is perfectly fine to proceed) and the command being unable to close Teams (where we need to stop execution) and communicate it to the user.

Good point! Within the catch I have put an extra check to ensure the teams client isn't running. For all other cases, users will get the error message. I've also applied this to the function removeCacheFiles.

if (errorMessage.includes('ERROR: The process "Teams.exe" not found.')) {
  if (this.verbose) {
    logger.logToStderr('Teams client isn\'t running');
  }
} else {
  throw new Error(errorMessage);
}

Here you can see that I'm looking specifically at the error message I get when the command on windows can't find teams.exe. With this logic, it would also be interesting to make a comparison with the output a mac would send. What do you think of this approach?

Let's see if there's a different way about it so that we don't need to rely on string comparison that's different between OSes but also languages. On mac we can see if we found a Teams PID or not, so that's a reliable way to see if Teams is running or not. If we can do the same on Windows, then we'd have a more reliable way of detection.

Good point, should we maybe take this into a new issue, so we can do a bit more of research on it. Currently I am having trouble fetching the Teams PID and validating the output.

We can use the current approach for now and meanwhile look at alternatives.