sume login --no-browser on a remote server: approve the user_code URL

On a server with no browser, run sume login --no-browser. The CLI prints the device approval URL and does not try to open anything. Open that URL on any machine where you are signed in to Sume, approve it, and the CLI on the server finishes the login by itself. It then stores a CLI-scoped API key in its local config.

The approval page is www.sume.com/cli/login, and the URL the CLI prints carries a user_code.

The device flow in four steps

This is the default login described on the CLI authentication page, the one the docs recommend for local users.

• Run sume login locally, or sume login --no-browser on a remote or headless terminal.
• The CLI shows the approval URL with a user_code. With --no-browser it only prints it.
• You approve in the browser. The CLI waits for that approval.
• The CLI saves a CLI-scoped key in ~/.sume-com/config.json, unless SUME_CONFIG_DIR points elsewhere.

Login or key: which one for which machine

The login flow needs a person to approve it, so it does not belong on an unattended runner. The docs keep manual API-key setup for CI, server automation and controlled environments, and call it not the recommended first-run path for local users.

Commands to run

The sample shows both paths. In the CI branch the key comes from your secret manager into the environment, never from a file checked into the repository. sume doctor --agent --json checks local readiness without calling the API, and sume auth status shows the CLI's auth state.

# On the remote server
sume login --no-browser
# -> prints the approval URL (it carries a user_code). Open it on your laptop.
sume auth status

# CI and servers: no human to approve, so use a key from your secret store
sume auth setup --api-key "$SUME_API_KEY"
sume doctor --agent --json

Common mistakes

• Expecting the login to work for hosted MCP. The docs are explicit: sume login does not broker hosted MCP OAuth tokens. Cursor and Claude connect to https://mcp.sume.com/mcp with their own OAuth consent, a separate flow.
• Pasting a key into chat or a ticket. If a key shows up in logs or chat history, rotate it.
• Not knowing which credential the CLI is using. If SUME_API_KEY is exported in the shell and a login also exists in the local config, the two can differ. The troubleshooting page asks you to report the source of the auth, env or local config, so check that first.
• Treating the stored key as a replacement for scopes you need. Keys are workspace-scoped, and a key's scopes are fixed when it is created. If a call returns 403 insufficient_scope, create a new key with the scopes you need.
• Forgetting that SUME_APP_BASE_URL decides where login points. For the production API its default is https://app.sume.com; for other APIs it is the origin of SUME_API_BASE_URL.

After login

Verify with read-only commands before anything paid: sume version, sume auth status, sume account get --json. They cost nothing and show whether the CLI sees the right workspace. Paid generation then needs --confirm-paid, and cancel or asset writes need --confirm-submit.