Authentication and project profiles
Aient CLI uses customer OAuth for ordinary development work. Refresh credentials stay in the operating-system credential store; local profile and project files contain non-secret selectors only.aient auth login
Open the browser consent flow and save a refresh-backed customer session:
On macOS, project access keeps refresh authority in Keychain and installs a
launchd user service that rotates a 15-minute envelope under the Git common
directory for up to 90 days. Login returns only after that exact manager-owned
renewal is verified. The terminal can then close; no foreground process or PID
owns renewal.
Linux managed renewal remains preview pending a real systemd-user and D-Bus
Secret Service renewal, restart, and logout canary. Use
--project-access=none for host-only login when you do not explicitly want to
opt into that preview.
Use a distinct profile for each organisation context you work in. Existing OAuth sessions may need a new login when Aient introduces additional consented capabilities.
Customer MCP management adds mcp_connections:read and mcp_connections:manage. Run
aient auth login again if an existing profile receives 403 for aient environment mcp after
upgrading to a CLI release that includes those commands.
aient auth status
Verify the selected login and display its issuer, organisation, and granted scopes:
auth status --all displays local metadata for every profile without refreshing credentials. A status check for a selected refresh-backed profile verifies the live session. From a configured project with no explicit profile, status discovers the repository-private access envelope, verifies its product context, and reports safe lease metadata without reading host refresh authority. A present invalid or expired project envelope fails closed instead of falling back to a host profile. An explicit --profile selects the host recovery view, including derived managed-service health.
aient auth logout
Revoke and remove only the selected login:
aient auth profiles
List locally known named profiles:
aient auth profiles default
Choose the non-secret fallback profile:
Bind a checkout with .aient/config.yaml
Create a project file in the checkout or linked worktree:
.aient/config.yaml. Supported keys are:
The file is intentionally strict: it accepts only these scalar keys and must not contain credentials. The organisation and repository values are selectors and mismatch checks, never authority.
Profile resolution order
For each invocation, Aient resolves authentication in this order:- An explicit access-only source:
--access-token-file,AIENT_ACCESS_TOKEN_FILE, orAIENT_ACCESS_TOKEN. --profile NAME.AIENT_PROFILE.- A valid
<git-common-dir>/aient/access-v1.jsonbelonging to the nearest configured project. - The profile named by the nearest
.aient/config.yaml. - The user default selected by
auth profiles default. - Compatibility profile
customer.
--profile and AIENT_PROFILE are rejected instead of silently choosing one. A portable access token and refresh-profile selection are also mutually exclusive for the same invocation.
aient auth export
Export a shorter-lived access-only credential for a child process, CI job, or another machine. Prefer a uniquely named, mode-0600 file outside every uploaded workspace:
Use the project form to repair an already logged-in host profile without
re-running browser OAuth:
files put.
aient auth exec
Run a trusted local task with a renewable, access-only credential rather than exposing the selected profile or its refresh token:
AIENT_ACCESS_TOKEN_FILE only. The CLI removes Aient profile, token, and sandbox-control variables from the child environment, creates a temporary access-only file, renews it while the task runs, and removes it when the task finishes.
auth exec requires a refresh-backed customer profile. It rejects an imported access token and operator authority. If you do not provide --profile, the nearest project configuration must contain a canonical organisation UUID.
By default, the delegated credential covers sandbox reads, creation, deletion, execution, shell access, file operations, and authorised environment use. Use repeatable --scope only when the task needs a different exact scope set; it replaces the default set. Repository-write and pull-request scopes also require an exact project repository, a matching origin or upstream remote, and --confirm-repository OWNER/NAME.