sume login opens the wrong host: SUME_APP_BASE_URL and its defaults

sume login finds its approval page from SUME_APP_BASE_URL. If you leave that variable unset, the CLI chooses a default from the API base URL: https://app.sume.com for the production API, and the origin of SUME_API_BASE_URL for any other API. So when sume login opens a host you did not expect, check these two variables first.

This matters for anyone with a second environment. A shell that exports a development SUME_API_BASE_URL and then runs sume login will not be sent to the production app, and the key it stores will belong to whichever host approved it.

The rule, from the configuration docs

The CLI configuration page lists five environment variables. Only one of them decides where login happens, and it has two defaults, depending on the API. The table restates that page as it read on 2026-10-10.

The point of the split is that a production user needs no setting at all, while a user of another API gets a default that follows the API they configured.

What to do when login lands on the wrong host

Work from the cause. Print the variables that the CLI will see, then decide which one is wrong. A leftover export from an old session is the usual culprit, and it is invisible until you list the environment. Shell profiles, direnv files and CI templates are the common places such a value hides, so check those after the live environment.

Once the variables are right, run the login again. The CLI waits for approval and then stores a CLI-scoped API key in the local config.

• Run env | grep SUME_ and read every value.
• If SUME_API_BASE_URL points at a non-production API, login will follow that origin unless SUME_APP_BASE_URL is set.
• If you want production, unset SUME_API_BASE_URL and SUME_APP_BASE_URL, then run sume login.
• If you want another app host with the production API, set SUME_APP_BASE_URL to that origin explicitly.

A worked example

The commands below point the CLI at the development API and let the app host follow it. They use --no-browser, which the authentication page describes as printing the approval URL without opening a browser, so the sample also suits a remote terminal.

Read the printed URL before you approve it. It should be on the host you meant. If it is not, stop, fix the variables, and run the command again. Then run sume auth status once the approval is done, to confirm the CLI now holds a key. Nothing in this flow needs a browser on the machine that runs the CLI, so it works over SSH.

# Point the CLI at a non-production API and say where login approves
export SUME_API_BASE_URL="https://api.dev.sume.com/v1"
unset SUME_APP_BASE_URL     # default: origin of SUME_API_BASE_URL

sume login --no-browser     # prints the approval URL
sume auth status

Keep environments apart

The key from a login lives in ~/.sume-com/config.json, so two environments on one machine share one file unless you separate them. SUME_CONFIG_DIR overrides the directory, and the configuration docs mention it for tests and isolated environments. Give each environment its own directory and the keys stop overwriting each other. A small shell function per environment that exports the base URLs and the config directory together keeps the three variables from drifting apart, and it makes the active environment obvious when you read your own history.

For automation, skip login. A CI job should use SUME_API_KEY from a secret store, as the CLI authentication docs describe, and never an approval flow. For a readiness check that makes no API call, sume doctor --agent --json examines the local state, and the related post on doctor as a CI preflight covers it.