Troubleshooting

Start with:

tsm doctor

It checks the configuration, the connection, the login and the tenant of the selected context, and says which step fails.

Problem	Check with	What to do
A command from this guide is unknown	tsm --version	Update the CLI: tsm cli upgrade
No context selected	tsm context list	Create a context and select it: tsm context use NAME --global
Wrong environment or tenant	tsm context show --explain	Pass --context / --tenant explicitly
Not logged in, HTTP 401	tsm auth status	Log in again for that context: tsm --context NAME auth login
Token is for a different tenant	tsm context show --explain	Select the matching tenant, or log in for that tenant

All checks above only read. When asking for help, include tsm --version, the selected context and workspace, and the error output. Never attach API keys, passwords or tokens.

Problems with the experimental local runtime are covered in Local runtime troubleshooting.

Credential storage and refresh

An account belongs to the storage provider used at login. Changing credential-storage does not migrate accounts. Select the original provider and log out before signing in with another provider.

auth login supports --password-stdin, --api-key-stdin, --token-stdin and --refresh-token-stdin. Only one credential can be read from stdin per command. A refresh token also requires --client-id. OS storage remains the default; there is no plaintext fallback.

File storage prompts for its passphrase once per command. If saving a rotated session fails after the server accepted the refresh, the CLI warns and keeps the new session for the current command only. Unlock the vault and sign in again before the next command. A rejected session for another tenant is never used for requests. No recovery file containing credentials is written.

Windows storage uses bounded Credential Manager chunks and encoded PowerShell scripts. Failed cleanup is reported; retry auth logout after unlocking the vault to remove committed and staged chunks.

Upgrade inputs

tsm cli upgrade requires HTTPS by default. --allow-insecure-http is an explicit opt-in for a trusted local test server; HTTPS redirects still cannot downgrade to HTTP. The GitLab token option is --gitlab-token. Upgrade limits are 256 MiB for a binary, 4 MiB for release metadata and 64 KiB for a checksum file. The binary must match the platform executable format and checksum before installation. The standalone install.sh and install.ps1 scripts also require HTTPS. Their explicit local-test override is TSM_ALLOW_INSECURE_HTTP=1; redirects from HTTPS still cannot downgrade to HTTP.