Configuration

Two state surfaces:

File	Purpose	Permissions	Carries secrets?
`~/.autocom/config.toml`	Preferences (API URL, default tenant, output format)	0600	No
`~/.autocom/credentials`	File-fallback credential store (only used if no OS keychain)	0600	Yes — keychain preferred

Override either path with env vars:

AUTOCOM_CONFIG=/path/to/config.toml          autocom whoami
AUTOCOM_CREDENTIALS_FILE=/path/to/creds      autocom whoami

Useful for tests, multi-profile setups, or running multiple CLI personas on the same machine.

Config keys

The config file is TOML. Missing fields fall back to defaults; unknown keys are silently ignored (so old binaries don't break when a new key lands).

api_url = "https://api.autocom.wexron.io/api/v1"
tenant  = "acme"
output  = "table"
ring    = ""               # optional ring pin; usually inferred from hostname
no_telemetry = false       # opt out of the version-check ping (planned)

Key	Default	Type	Description
`api_url`	`https://api.autocom.wexron.io/api/v1`	string	Base URL — no trailing `/graphql`
`tenant`	—	string	Default tenant slug for the `X-Tenant` header
`output`	`table`	enum	One of `table` / `json` / `yaml`
`ring`	—	string	Pin a deployment ring (rare; usually inferred from hostname)
`no_telemetry`	`false`	bool	Opt out of the periodic version-check ping (planned)

Reading and writing

autocom config list                            # show everything + the file path
autocom config get api_url                     # one value
autocom config set output json                 # update + save
autocom config set wat foo                     # ✗ exit 2: unknown config key

set validates: e.g. output must be one of the three valid formats; an unknown key fails fast. The file is written atomically (write-temp-then-rename), so a crash mid-save can't leave you with a corrupt half-file.

Override priority

For any value that has a config key + a flag + an env equivalent, the priority is:

command-line flag    >    environment variable    >    config file    >    built-in default

Examples:

# Use a different API for one command, without touching config
autocom --api-url https://api.staging.autocom.io/api/v1 orders list

# Switch tenant for one command
autocom --tenant widgets orders list

# Force JSON output regardless of config
autocom orders list -o json

Environment variables

Variable	Effect
`AUTOCOM_CONFIG`	Path to the config file (overrides `~/.autocom/config.toml`)
`AUTOCOM_CREDENTIALS_FILE`	Path to the credentials file fallback
`AUTOCOM_CLIENT_ID`	OAuth client ID for `auth login` (used when `--client-id` not passed and no build-time default)
`NO_COLOR`	Disable ANSI styling (also `--no-color` flag)
`BROWSER`	Custom browser launcher for OAuth flow (overrides OS default)

Multi-profile workflow

If you frequently switch between a personal sandbox and a production tenant, point each profile at its own config file:

# Personal sandbox profile
AUTOCOM_CONFIG=~/.autocom/sandbox.toml \
AUTOCOM_CREDENTIALS_FILE=~/.autocom/sandbox.creds \
  autocom auth login --api-url https://sandbox.autocom.io/api/v1 --tenant my-test

# Production profile
AUTOCOM_CONFIG=~/.autocom/prod.toml \
AUTOCOM_CREDENTIALS_FILE=~/.autocom/prod.creds \
  autocom auth login --api-url https://api.autocom.wexron.io/api/v1 --tenant acme

# Use shell aliases
alias autocom-sandbox='AUTOCOM_CONFIG=~/.autocom/sandbox.toml AUTOCOM_CREDENTIALS_FILE=~/.autocom/sandbox.creds autocom'
alias autocom-prod='AUTOCOM_CONFIG=~/.autocom/prod.toml AUTOCOM_CREDENTIALS_FILE=~/.autocom/prod.creds autocom'

autocom-prod orders list --status pending

The single-config workflow ALSO supports multiple environments — see Authentication → Multi-environment — but profiles are useful when each environment has its own preferred tenant and output format too.

File locations on each OS

OS	Default config	Default credentials
macOS	`~/.autocom/config.toml`	macOS Keychain (`autocom-cli` service)
Linux	`~/.autocom/config.toml`	Secret Service (gnome-keyring, kwallet, etc.)
Windows	`%USERPROFILE%\.autocom\config.toml`	Windows Credential Manager

The keychain holds a JSON blob keyed by api_url so you can have credentials for many environments without conflict.

Inspecting credentials

The CLI does not have a creds dump command — by design, since the goal is for the OS keychain to be the storage of last resort. To inspect what's stored, use the OS-native tool:

# macOS
security find-generic-password -s autocom-cli -a credentials -w

# Linux (Secret Service)
secret-tool lookup service autocom-cli account credentials

# File fallback (when no keychain)
cat ~/.autocom/credentials | jq .

Resetting

Wipe everything for a clean start:

autocom auth logout                       # clear keychain entry for current api_url
rm -rf ~/.autocom                         # nuke config + file fallback
unset AUTOCOM_CONFIG AUTOCOM_CREDENTIALS_FILE AUTOCOM_CLIENT_ID