Configuration

CLI

Configuration

The CLI needs two things: which organisation to act on, and an API key to authenticate. You can supply them through environment variables or a configuration file.

Environment variables

# Required
export HUTLY_ORG_ID="your-org-id"
export HUTLY_API_KEY="your-api-key"

# Optional — defaults to the production API
export HUTLY_API_ENDPOINT="https://api.intellia.com.au"

Variable	Required	Purpose
`HUTLY_ORG_ID`	Yes	The organisation every command is scoped to
`HUTLY_API_KEY`	Yes	API key used to authenticate; its org role gates what you can do
`HUTLY_API_ENDPOINT`	No	Override the API base URL (defaults to the production endpoint)
`HUTLY_AGENT_INVOCATION`	No	Set to `1` to run non-interactively (see Agent mode)

Configuration file

Instead of environment variables, create .hutlyrc.yaml in your project directory or home directory:

organizationId: your-org-id
apiEndpoint: https://api.intellia.com.au

Store the API key separately in ~/.hutly/credentials:

{
  "apiKey": "your-api-key"
}

Environment variables take precedence over the configuration file, so you can keep defaults in .hutlyrc.yaml and override per-shell when needed.

JSON output

Most commands emit machine-readable JSON by default and accept --json (a no-op for compatibility) and --pretty for indented output:

hutly workflow list --json --pretty | jq '.[] | .name'

This makes the CLI safe to use as a building block in shell scripts and CI pipelines.

Agent mode

When the CLI is driven by an automated agent rather than a human, set:

export HUTLY_AGENT_INVOCATION=1

In agent mode, commands that would normally prompt for input (interactive org create, secret get, confirmation prompts) instead fail fast with a documented exit code rather than hanging on a prompt. Use flags or YAML files to provide input non-interactively, and secret use instead of secret get. See Secrets for the exit-code table.

Installation Workflows