Problem

coder login token fails with a cryptic error when --url or CODER_URL is not provided, even after a successful coder login. Occurs on macOS, where the CLI will use the keyring by default.

  $ coder login dev.coder.com
  Welcome to Coder, zachkipp! You're authenticated.

  $ coder login token
  error: read session token: nil server URL

The config file URL exists and is valid:

  $ cat ~/Library/Application\ Support/coderv2/url
  https://dev.coder.com

Cause

When the CLI is not using the keyring, the session file on disk is simply printed out. This is what the unit tests covered. When the keyring is used, the URL needs to be provided to know what session token to print out because the storage format permits storage of multiple session tokens. In the coder, r.clientURL was used directly which is only populated from --url or CODER_URL. So essentially, when using the keyring a token could only be printed out if either --url or CODER_URL was specified even if a user is currently logged in to a deployment and the url file contains the deployment URL.

Solution

Extract the deployment URL-loading logic from InitClient into a reusable method and call it from loginToken(). This makes coder login token consistent with every other command that needs the server URL. This mean that regardless of keyring/file storage, the CLI will read the url file on disk that was updated when logging in, unless the user specifies --url or CODER_URL. So a user that has logged into a deployment with a machine that is using the keyring for session token storage should not need to provide --url or CODER_URL to print out the token for the deployment they are logged in to.

Goal:

Relates to #21515