CLI authentication — Altifigence Documentation

Overview

Choose the credential path for the command you are using. Native Cloud sign-in, legacy customer action credentials, and an operator-configured DDS HTTP service are separate contracts. Local XLS and native workspace operations need no Cloud credentials.

Desktop and CLI Credentials Are Separate

Surface	Credential path	Authority
Digital Design Studio 2.0.2 Windows	Browser sign-in for protected local features; editing and saving also work without sign-in	No My PC device licence. Free sign-in supports the documented local features; Cloud and AI check separate permissions.
`alti` `ide` `cloud`	Browser PKCE and a private CLI session	Account identity and organization/project permissions are checked by the server
Customer action/job client	`ALTI_TOKEN` and `ALTI_ORG_ID`	The credential and scope presented to the selected API
`alti` `ide` `service`	Configured service origin and `ALTI_STUDIO_SERVICE_SECRET`	The legacy service’s existing authorization contract

No CLI session grants a desktop licence. Do not import desktop session files, browser cookies, or internal service headers into a native Cloud request.

Native Cloud Sign-in

alti ide cloud login
alti ide cloud whoami
alti ide cloud refresh
alti ide cloud logout

Login prints the authorization URL for the browser PKCE flow. It defaults to https://api.altifigence.com and a private session directory at ~/.local/state/altifigence/cloud-cli. Use --session-dir consistently to select another session. Login also accepts --org and a bounded --wait-seconds; subsequent commands use their own request deadlines.

Use whoami for server identity rather than inferring it from a stored token. Refresh and logout operate on this native session. Organization/project IDs on Cloud search and terminal commands scope the request but cannot grant access. Typed ide cloud run operations retain server permission checks and require --allow-source-upload when their contract carries uploaded source.

The CLI connects through its explicit native API routes. A sign-in flow does not promise that every Cloud operation is enabled for every organization.

Environment Variables the CLI Reads

The legacy customer action and Cloud job clients retain these settings:

Variable	Effect
`ALTI_TOKEN`	Required bearer credential; a missing or blank value is refused
`ALTI_ORG_ID`	Required organization scope
`ALTI_API_BASE`	API base, default `https://api.altifigence.com`
`ALTI_BYO`	`1`, `true`, or `yes` selects the bring-your-own principal kind
`ALTI_ALLOW_SOURCE_UPLOAD`	Opt-in for source-bearing customer MCP actions; absent means denied

Only set endpoint overrides to a service you control or an endpoint explicitly provided for your account. A changed origin can send the corresponding credential to a different host.

Legacy DDS HTTP commands instead use --endpoint or ALTI_STUDIO_ENDPOINT and the existing service-secret environment setting. They do not reuse the native Cloud login or invent an authentication flow for that service.

Configuration Status Is Not Authentication

alti auth status inspects legacy environment configuration only. Its serverVerification remains not_performed; it is not the equivalent of alti ide cloud whoami.

The legacy top-level alti login and alti whoami still exit 4 with AUTH_FLOW_UNAVAILABLE and IDENTITY_NOT_VERIFIED. Top-level alti logout cannot clear values inherited from a parent process. Clear or rotate those values at their source; use ide cloud logout for the native session.

Secret Handling

Keep CI credentials in the CI secret store and inject them only into the step that needs them.
Keep session directories private to their owner; do not add them to source control, caches shared between users, or published artifacts.
Do not log tokens, service secrets, browser cookies, or complete environments.
Disable shell tracing around credentialed commands and rotate any value that may have entered a log.

Remote API Access

Use the typed Job and Cloud Commands for the backend you selected. Client validation and a successful login do not replace server-side permissions or prove that a requested job has completed.

Verify and recover the native session

alti ide cloud login
alti ide cloud whoami

Run these as the same ordinary Linux user who will use the CLI. Complete the browser flow and require a successful whoami response before workspace operations. If you use an alternate --session-dir, use it for login and subsequent calls; a different directory is a different saved session.

If the session expires, use the native refresh/sign-in flow. If identity succeeds but a project is denied, inspect organization membership and project permissions. Do not copy credentials from the desktop or change API origins to work around that refusal. For account recovery, use Account security.