Authentication and profiles

The CLI authenticates to https://mcp.tensorant.io/mcp. Each credential acts as one person in one organization. Your current membership, role, access level and plan limits apply to every call, including downloads. An application API key cannot authenticate CLI commands.

Browser sign-in

tensorant auth login --level build
tensorant auth status

The browser asks you to sign in, choose an organization and approve Read, Build or Full access. Check the organization before approving. Login defaults to Read; request Build for imports and evaluation, or Full for training and experiments. Viewers can only grant Read. The CLI uses a local loopback callback and PKCE, then refreshes its credential as needed.

Use --no-browser to print the approval URL instead of opening it automatically. Open that URL in a browser on the same machine as the CLI so its loopback callback can complete. For a remote machine or CI, use a personal token.

Personal tokens

Create a token in Settings → Agents → New token, choosing its name, organization access and lifetime. Tokens expire after 30, 90 or 365 days and are shown only once. See Create a token.

To save a token without passing it as a command argument, read it from a protected file or secret manager through standard input:

tensorant auth login --token-stdin < /secure/path/tensorant-token
tensorant auth status

For CI, inject the token as the TENSORANT_TOKEN secret environment variable. The CLI uses it for that process without saving it. Do not put tokens in shell commands, configuration examples, committed files or build logs. --level applies to browser authorization; it cannot widen a token's existing access.

An environment token takes precedence over saved credentials. Clear TENSORANT_TOKEN before checking or using a saved browser login. See CI quality gates for an example.

Profiles and projects

Use separate profiles for organizations or accounts:

tensorant --profile work auth login --level full
tensorant --profile work projects list
tensorant --profile work projects use PROJECT_ID
tensorant --profile work sources list

During login, approve the organization that profile should use. projects use verifies the project's accessibility and saves its ID as the profile's default. Project commands accept --project PROJECT_ID to override that default. IDs are returned by projects list; project names are not resolved as IDs.

Select a profile with --profile NAME, or set TENSORANT_PROFILE. When neither is set, the profile is default. An explicit flag takes precedence over its environment setting. Supplying a token through TENSORANT_TOKEN determines the organization independently of the profile name, so check auth status before making changes.

Stored credentials

The CLI stores profiles and credentials in $XDG_CONFIG_HOME/tensorant/config.json, or ~/.config/tensorant/config.json if XDG_CONFIG_HOME is unset. TENSORANT_CONFIG_DIR overrides the containing directory. Configuration files are written atomically with owner-only permissions; refreshes use a lock so concurrent commands cannot race to rotate the same browser credential.

The file contains secrets. Keep it outside repositories, protect local backups and use environment tokens in ephemeral CI runners. --server and TENSORANT_SERVER select the service address; stored credentials are tied to their saved server and cannot be silently reused against another one. Normal Tensorant use needs no server override.

An interrupted or unsuccessful browser-token refresh requires another sign-in. The CLI clears the old saved credentials before sending a refresh request so a later command cannot replay a token that the server may already have consumed.

Sign out and revoke access

tensorant --profile work auth logout

Logout revokes the saved credential and removes it locally. It does not revoke a token supplied through TENSORANT_TOKEN; revoke that token under Settings → Agents, then remove it from the secret store that supplies it. You can also revoke a lost device's credential from the console. Owners can revoke any agent in their organization.

Browser grants expire after 30 days without use. Membership removal, account disabling, token expiration or revocation may cause the next call to fail. Sign in again after resolving the cause. To increase access, authorize a new grant at the required level and revoke the old grant. See Access and tokens for the complete rules.