Setup Guide

Setup Guide

Get from zero to your first command.

Installation

Homebrew (macOS/Linux)

brew install Jamf-Concepts/tap/jamf-cli

Binary releases

Download pre-built binaries from GitHub Releases. Archives cover macOS, Linux, and Windows on both amd64 and arm64.

From source

go install github.com/Jamf-Concepts/jamf-cli/cmd/jamf-cli@latest

Staying current

Releases land about once a week, and a stale binary is the usual cause of "that command doesn't exist" against an endpoint a newer build generates. Since v1.26.0 an interactive release build checks once a day for a newer version and prints one line naming the upgrade command for your install channel:

hint: new jamf-cli release: v1.25.2 → v1.26.0 (brew upgrade jamf-cli)
      https://github.com/Jamf-Concepts/jamf-cli/releases/tag/v1.26.0

The check does not run in CI, when output is piped, or under --quiet / --no-hints, and the CLI does not update itself. To silence the notice, see Configuration & Profiles#Release Update Notice (v1.26.0+).

A go install build reports its own module version, so the notice works on that channel too.

Jamf Pro Quick Start: Platform Gateway (Recommended)

For Jamf Cloud instances, use the platform gateway. A single profile routes all Pro API traffic through the Jamf Platform Gateway and enables Platform API commands: blueprints, compliance benchmarks, device groups and DDM reports under pro, the platform namespace (AI Governance, Jamf Account, platform audit; see Jamf Platform Commands), and the gateway-served half of Jamf Security Cloud.

The Jamf Platform API reached general availability on 2026-09-03. Two GA changes affect a setup built during the public beta:

• The gateway base URL is https://{region}.api.jamfcloud.com, and the /api path segment the beta needed is gone. A profile naming the pre-GA https://{region}.apigw.jamf.com is refused before any request is sent, with the replacement URL in the message. Edit the profile yourself; the CLI leaves the file alone.
• Public-beta credentials stopped working at GA, and a beta client cannot be migrated. Register a replacement API integration in Jamf Account, then run platform setup again.

See Platform API GA Migration for the full migration, including the commands that are refused on a gateway profile.

Step 1: Register an API integration in the Jamf Account portal, at the scope level you want (see Scope levels below). The Getting started with Platform API guide has the instructions.

Step 2: Run the setup wizard:

jamf-cli platform setup

The wizard asks for:

1. Profile name (default: platform)
2. Region: US, EU, APAC, or a custom gateway URL
3. Client ID and Client Secret: hidden input, stored in the system keychain
4. Scope: the platform environment ID, or a tenant ID, or neither for an organization-scoped integration

It then runs two checks, in this order:

1. The credentials, against the gateway's token endpoint. A failure here is fatal: nothing works without them.
2. The scope ID, by sending the header on one request. The token exchange sends no scope header, so working credentials say nothing about the ID you pasted, and a mis-paste saves without complaint and then refuses every command. The gateway resolves the scope at the edge, ahead of routing and any permission check, so this check judges the ID alone.

Two answers reject an ID. An X-Environment-Id the gateway does not know (an unknown UUID, or a tenant ID pasted at the environment prompt) answers 404 ENVIRONMENT_NOT_FOUND. An X-Tenant-Id it will not accept answers 403 OWNERSHIP_FORBIDDEN, which covers an unknown UUID and an environment or organization ID pasted at the tenant prompt. Any other answer leaves the ID unjudged, and the wizard says so.

Validating credentials... ok
Checking the scope ID... ok: the gateway accepts this environment ID

The closing summary comes from the declared scope of every platform resource the binary ships, whichever prompt you filled in:

This scope serves the Pro API and Classic API commands.
It also reaches all 29 Platform API resources, audit and AI Governance included.

A tenant-scoped credential gets a split instead, It also reaches 16 of the 29 Platform API resources, naming the 13 that declare environment scope, plus the caveat that some of those answer on a tenant credential anyway. No command is refused for its declared scope. Treat a 400 or 403 naming the scope as the signal to create an environment-scoped integration.

Setup checks no product's access and no permissions: a capability permission is granted per operation when the integration is created. The 403 that wants a permission names it in the words Jamf Account's picker uses, and jamf-cli commands -o json lists them under gatewayPermissions.

platform setup merges into an existing profile of that name and leaves credentials another setup command wrote in place, so one profile carries both these gateway credentials and the Jamf Security Cloud Radar pairs that security setup writes. Order does not matter.

Once complete:

# Pro API commands work through the gateway
jamf-cli pro computers list
jamf-cli pro computers get --name "Neil's MacBook"

# Platform API commands are now available
jamf-cli pro blueprints list
jamf-cli pro compliance-benchmarks list
jamf-cli pro ddm-reports device declarations <device-id> --filter 'active==true'   # --filter is required

Scope levels

You create a Jamf Platform API integration at one of three levels in Jamf Account, and its credential works with that level alone. The level belongs to the integration, so an environment ID cannot widen a tenant credential.

Level	Profile key	Header sent	Reaches
Organization	neither key	none (resolved from the access token)	Jamf Account only (platform account-licenses, deal-registrations, distributor-*, sso-*, US-only)
Platform environment	environment-id	X-Environment-Id	a group of tenants across product types; the level to prefer, and the only level platform audit and AI Governance (platform ai-policies, ai-tools) accept
Tenant	tenant-id	X-Tenant-Id	one Jamf Pro / School / Protect / Security Cloud tenant (the legacy level)

The wizard asks for the platform environment ID first and stops there if it gets one, since the levels are mutually exclusive. Leave both blank for an organization-scoped integration.

Organization scope has no ID to supply, so the gateway host selects platform auth for it. JAMF_URL=https://us.api.jamfcloud.com plus a client ID and secret, with no scope ID at all, is a complete organization-scoped setup.

A customer with several tenants and no platform environment keeps a profile per tenant.

See Configuration & Profiles#Authentication Methods for the resolution ladder, the per-invocation overrides and what each wire error means, and Jamf Platform Commands for the platform namespace itself.

Platform setup flags

Flag	Description
--profile-name	Profile name (default: platform)

platform setup prompts for the client ID and client secret, with hidden input. It needs interactive input and is refused with --no-input. In CI/CD, use environment variables (see Configuration & Profiles#Environment Variables) or script config add-profile (see Manual Profile Configuration).

Jamf Pro Quick Start: Direct Instance

For on-premises instances, or Jamf Cloud instances where platform gateway credentials are not available, use pro setup. It saves OAuth2 client credentials for one instance as a config profile, from one of two sources:

--credentials	Where the credentials come from
existing (default)	An API client you already created in Jamf Pro (Settings > API roles and clients). You supply its client ID and secret; its own API role decides what the CLI can do.
create	jamf-cli authenticates with a Jamf Pro account, creates an API role and client scoped by --scope, and generates the credentials. The username and password are not stored.

Omit the flag and the wizard asks:

How should jamf-cli get its API credentials?
  1. Existing API client  — you supply a client ID and secret already created in Jamf Pro (default)
  2. Create one for me    — authenticate with a Jamf Pro account; jamf-cli creates the API role and client
Choose [1-2]:

# Existing API client, the default
jamf-cli pro setup --url https://jamf.company.com

# Have jamf-cli create the role and client for you
jamf-cli pro setup --url https://jamf.company.com --credentials create --scope standard

Omit --url too and the wizard prompts for it first.

--credentials names a source, never a value. You type every credential at an interactive prompt on both branches; no flag, environment variable or stdin route accepts one, so nothing lands in shell history, ps output or a CI log. Both branches refuse --no-input (setup requires interactive input for credentials, exit 1), and four usage errors exit 2 and write nothing: --scope with existing, --rotate-credentials with existing, an unrecognised --credentials value, and --url together with --from-file.

On the existing branch, setup proves the pair with one client-credentials token exchange before it writes anything. A failure leaves no profile behind.

── https://jamf.company.com ──
Client ID: f3d5f2a1-a3eb-4bb0-83e1-919329349e4b
Client Secret:
  Verifying credentials... ✓
  ✓ Profile "prod" ready (client ID: f3d5f2a1-a3eb-4bb0-83e1-919329349e4b)

Profile "prod" set as default.

  Verifying credentials... ✗
OAuth2 token exchange failed: invalid client credentials, verify your client-id and client-secret are correct

jamf-cli did not write profile "prod"

The create branch generated the pair itself, so it has nothing to verify. Either way, once setup finishes:

jamf-cli pro computers list

--credentials create is on a deprecation path. Local Jamf Pro accounts, SAML and LDAP/directory administrator authentication are deprecated for cloud-hosted Jamf Pro, with an estimated removal in the second half of 2027; self-hosted instances are not affected. Once those accounts go, that branch has no account left to authenticate with. The branch prints This path is deprecated. See "jamf-cli pro setup --help". before its first prompt. Prefer --credentials existing, or platform setup for the Platform API. Deprecations and Removals

Upgrading from v1.28.0 or earlier? pro resource names come from the API's own tags and paths, and 103 spellings were retired. 100 of them work until 2027-03-09, printing a warning on stderr that names the replacement; three refuse, as do 48 invocations whose operation name moved as well. See Pro Command Renames.

Note: Direct instance profiles have no access to Platform API commands (blueprints, compliance-benchmarks, platform-devices, platform-device-groups, ddm-reports) or the platform namespace. Running one on an instance profile is refused before any request is sent, with exit code 8; see Platform API GA Migration. For those, set up a platform gateway profile.

Scope options

--scope applies to --credentials create alone: it is the privilege set of the API role jamf-cli creates. With --credentials existing the privileges come from the role already attached to your client, so --scope there is a usage error.

Scope	Privileges granted
read-only	Read and view access to all resources
standard (default)	All operations except delete, flush, dismiss, and remote wipe/lock commands
full-admin	All privileges

Omit --scope on the create branch and the wizard offers the same three as a numbered menu, defaulting to Standard.

SSO or no local accounts? --credentials create needs a local username and password to bootstrap credentials, so it will not work on an instance using SSO with local admin accounts disabled. Use --credentials existing for that case: create the API client in the console, then hand its ID and secret to setup. See SSO / No local accounts below.

Jamf Protect Quick Start

Jamf Protect uses OAuth2 client credentials that you create in the Jamf Protect console. Go to Settings > API Clients in your Protect tenant to generate a client ID and secret before running this command.

jamf-cli protect setup --url https://tenant.protect.jamfcloud.com

The wizard prompts for the client ID and client secret (hidden input) and stores the secrets in the system keychain. Once complete, run commands:

jamf-cli protect overview
jamf-cli protect plans list

Setup flags

Flag	Description
--url	Jamf Protect URL (e.g., https://tenant.protect.jamfcloud.com)
--profile-name	Profile name (default: protect)

protect setup prompts for the client ID and client secret, with hidden input, which keeps both out of shell history and process listings.

Note: protect setup needs interactive input and cannot be automated. In CI/CD, use environment variables (see below) or create a config profile with env: / file: secret references.

Environment variable authentication

For ad-hoc use or CI pipelines, skip profiles:

export JAMFPROTECT_URL="https://tenant.protect.jamfcloud.com"
export JAMFPROTECT_CLIENT_ID="your-client-id"
export JAMFPROTECT_CLIENT_SECRET="your-client-secret"

jamf-cli protect plans list

Note: Protect-specific env vars (JAMFPROTECT_*) take priority. The CLI also checks the generic JAMF_URL, JAMF_CLIENT_ID, and JAMF_CLIENT_SECRET as fallbacks.

Jamf School Quick Start

Jamf School uses API key authentication (network ID + API key). Generate these in the Jamf School console: Organization > Settings > API for the API key, and find the Network ID at Devices > Enroll Device(s).

jamf-cli school setup

The wizard asks for:

1. Profile name (default: school)
2. School URL: e.g., https://tenant.jamfschool.com
3. Network ID: from the Jamf School console
4. API Key: hidden input, stored in the system keychain
5. Platform API access (optional): answer yes and the wizard collects gateway region, tenant ID, client ID, and client secret for Platform API commands (blueprints, DDM reports). The School wizard is tenant-scoped: it asks for a tenant ID, not a platform environment ID.

Once complete:

jamf-cli school overview
jamf-cli school devices list
jamf-cli school classes list

# If platform credentials were configured:
jamf-cli school blueprints list

Setup flags

Flag	Description
--url	School instance URL (e.g., https://tenant.jamfschool.com)
--profile-name	Profile name (default: school)

school setup prompts for the network ID and API key. It needs interactive input and cannot be automated. In CI/CD, use environment variables (see Configuration & Profiles#Environment Variables).

Environment variable authentication

For ad-hoc use or CI pipelines, skip profiles:

export JAMFSCHOOL_URL="https://tenant.jamfschool.com"
export JAMFSCHOOL_NETWORK_ID="your-network-id"
export JAMFSCHOOL_API_KEY="your-api-key"

jamf-cli school devices list

To also enable Platform API commands:

export JAMFSCHOOL_URL="https://tenant.jamfschool.com"
export JAMFSCHOOL_NETWORK_ID="your-network-id"
export JAMFSCHOOL_API_KEY="your-api-key"
export JAMFSCHOOL_PLATFORM_URL="https://eu.api.jamfcloud.com"
export JAMF_CLIENT_ID="your-client-id"
export JAMF_CLIENT_SECRET="your-client-secret"
export JAMF_TENANT_ID="your-tenant-id"

jamf-cli school blueprints list

Note: JAMFSCHOOL_URL falls back to JAMF_URL when unset. Platform credentials use the shared JAMF_* variables.

Jamf Security Cloud Quick Start

Two APIs with two different credential sets serve Jamf Security Cloud, so it takes two setup commands. Both write into the same profile, in either order:

Command	Owns	Serves
jamf-cli platform setup	gateway region, platform client credentials and the scope the integration was created at	the gateway-served half: 16 resources, dns-*, ztna-*, content-categories, device-groups, uem-*, enrollment-activation-profiles
jamf-cli security setup	the three Radar application ID/secret pairs	risk, device-lifecycle, stream, status, verification, jwks, well-known

The gateway-served half needs a platform gateway credential at any scope level. An environment-scoped credential reaches it (content-categories, dns-zones, ztna-apps and uem-connectors all returned data on an EU environment credential), and tenant is a valid level too. See Configuration & Profiles#Scope levels. Answer platform setup for the level your integration was created at; the scope check rejects an ID pasted at the wrong prompt.

Both commands merge into the profile they write to, so running one after the other against a single profile name keeps both credential sets. Each command's --help and security <TAB> description says which API serves it: (Security Cloud · platform gateway) or (Security Cloud · Radar API).

For the Radar half, Jamf Security Cloud provisions a separate application ID/secret pair per API: Risk, Device Lifecycle, and Shared Signals & Events (SSE) each have their own "Security Integration" under Settings > Security Integrations in the Radar portal. Create integrations for the APIs you need before running setup.

jamf-cli security setup

The wizard asks for:

1. Profile name (default: security)
2. Risk API: application ID and secret (leave the application ID blank to skip)
3. Device Lifecycle API: application ID and secret (leave blank to skip)
4. Shared Signals & Events API: application ID and secret (leave blank to skip)

At least one pair is required, and the CLI stores the secrets in the system keychain. There is no URL to configure: all three APIs share one global production host, and the JWT carries tenancy. On a re-run, a pair you skip by pressing Enter is left as it was, and the closing summary says which pairs were entered and which were retained. To remove a pair, delete the profile with jamf-cli config remove-profile <name> and run setup again with only the pairs you want.

Once complete:

jamf-cli security risk list
jamf-cli security stream get

Setup flags

Flag	Description
--profile-name	Profile name (default: security)

security setup prompts for credentials, with hidden input. It needs interactive input and is refused with --no-input. In CI/CD, use environment variables.

Environment variable authentication

For CI pipelines, skip profiles by setting the credential pair(s) for the API(s) you use:

# Risk API
export JAMFSECURITY_RISK_CLIENT_ID="your-risk-application-id"
export JAMFSECURITY_RISK_CLIENT_SECRET="your-risk-application-secret"

# Device Lifecycle API
export JAMFSECURITY_LIFECYCLE_CLIENT_ID="your-lifecycle-application-id"
export JAMFSECURITY_LIFECYCLE_CLIENT_SECRET="your-lifecycle-application-secret"

# Shared Signals & Events API
export JAMFSECURITY_SSE_CLIENT_ID="your-sse-application-id"
export JAMFSECURITY_SSE_CLIENT_SECRET="your-sse-application-secret"

jamf-cli security risk list

Note: Each API's client ID and secret must both come from the same source: set both via env or neither. Configure the API(s) you need; commands for an unconfigured API fail with a "run security setup" hint. See Configuration & Profiles#Jamf Security Cloud for the full variable list, including the optional JAMFSECURITY_URL / JAMFSECURITY_SSE_URL host overrides.

Jamf Pro Setup Details

Setup flags

All flags are optional; the wizard prompts for anything you omit.

Flag	Description
--credentials	Credential source: existing (default) or create
--url	Jamf Pro server URL; prompted for if omitted
--from-file	File containing one Jamf Pro URL per line (for multi-instance setup)
--scope	read-only, standard, or full-admin; --credentials create only
--profile-name	Profile name (default: default; ignored with --from-file)
--rotate-credentials	Regenerate client credentials for an existing integration; --credentials create only
--report-dir	Directory the MCP server writes HTML reports to; see MCP Server

--url and --from-file are mutually exclusive. So are --scope and --rotate-credentials with --credentials existing: jamf-cli did not issue that client, so it can neither choose its privileges nor rotate its secret. Each combination exits 2 naming the conflict.

Note: pro setup needs interactive input and refuses --no-input. In CI/CD, use environment variables or create a config profile with env: / file: secret references (see Configuration & Profiles).

The CLI stores secrets in the system keychain. On systems without keychain access, use config add-profile with env: or file: references instead.

Multi-instance setup (MSPs)

For environments managing many Jamf Pro instances with shared admin credentials, use --from-file with a file containing one URL per line:

# instances.txt
school1.jamfcloud.com
school2.jamfcloud.com
school3.jamfcloud.com

# Have jamf-cli create a role and client on each instance
jamf-cli pro setup \
  --from-file instances.txt \
  --credentials create \
  --scope standard

# Or hand it a client you already created on each one
jamf-cli pro setup --from-file instances.txt

Profiles are auto-named pro-<subdomain> (e.g., pro-school1, pro-school2). Setup continues with the remaining instances after one fails, and reports a summary at the end.

The branch decides how often you are prompted. --credentials create asks once for the admin credentials and reuses them across every instance. --credentials existing asks for a client per instance, because Jamf Pro issues an API client against the instance it lives on:

Setting up 2 instance(s) from existing API clients...

── https://school1.jamfcloud.com → profile "pro-school1" ──
Client ID:

After setup, switch between instances with --profile:

jamf-cli -p pro-school1 pro overview
jamf-cli -p pro-school2 pro computers list

Idempotent setup

pro setup is safe to re-run on either branch.

With --credentials create, it checks whether the API role and integration exist on the instance and updates them in place, so duplicates do not accumulate. It preserves existing client credentials by default, so other processes (CI pipelines, scripts, MJT) using the same integration keep working. To regenerate credentials, invalidating the old ones, pass --rotate-credentials:

jamf-cli pro setup --url https://jamf.company.com --credentials create --rotate-credentials

With --credentials existing, setup touches nothing on the instance: it verifies the pair and writes the profile. Rotating is Jamf Pro's job, so generate a new secret in the console and re-run setup. --rotate-credentials is refused on this branch.

Team usage

On --credentials create, API integrations are named jamf-cli [<username>], so several team members can run setup against the same instance without colliding. The API role (jamf-cli-<scope>) is shared. --credentials existing creates nothing on the instance.

Setup steps

With --credentials existing, two steps:

1. Exchanges the client ID and secret you typed for a token, to prove the pair works
2. Stores both in the system keychain (see Secrets & Keychain) and saves the profile, setting it as the default (single instance) or auto-naming it (multi-instance)

With --credentials create, these steps run against the temporary bearer token from your Jamf Pro account:

1. Fetches available API privileges from the Jamf Pro instance
2. Creates (or updates) an API role named jamf-cli-<scope> with the selected privilege set
3. Creates (or updates) an API integration named jamf-cli [<username>] linked to that role
4. Generates OAuth2 client credentials (client ID + secret); skipped for an existing integration unless you pass --rotate-credentials
5. Stores the client secret in the system keychain (see Secrets & Keychain)
6. Saves the profile to the config file and sets it as the default (single instance) or auto-names it (multi-instance)

Manual Profile Configuration

If you already have API credentials, or prefer not to use the wizard, add a profile by hand:

# Platform gateway profile, environment-scoped (recommended: enables both Pro API and Platform API)
jamf-cli config add-profile prod \
  --url https://us.api.jamfcloud.com \
  --auth-method platform \
  --environment-id your-environment-id
# You'll be prompted for client ID and client secret (hidden input)

# Platform gateway profile, tenant-scoped (the legacy level)
jamf-cli config add-profile prod-tenant \
  --url https://us.api.jamfcloud.com \
  --auth-method platform \
  --tenant-id your-tenant-id

# Platform gateway profile, organization-scoped (Jamf Account only)
jamf-cli config add-profile org \
  --url https://us.api.jamfcloud.com \
  --auth-method platform
# No --environment-id or --tenant-id: saved as an organization-scoped profile

# Direct instance profile (Pro API only)
jamf-cli config add-profile prod \
  --url https://jamf.company.com \
  --auth-method oauth2
# You'll be prompted for client ID and client secret (hidden input)

config add-profile is the scripted alternative to platform setup: it takes the URL and scope as flags, leaving only the credential prompts. It verifies the credentials before writing anything, with one token exchange:

Verifying credentials... ✗
platform token exchange failed: invalid client credentials, verify your client-id and client-secret are correct

jamf-cli did not write the profile. Add --no-verify to save it without checking

--no-verify skips the check, for pre-seeding a config offline or on a machine that cannot reach the server it names. The check is skipped anyway for token auth (a bearer token is only testable by spending it) and for an env: or file: secret reference, which is often written where the server is unreachable.

add-profile skips the scope-ID check and the closing scope summary that platform setup runs, so a mis-pasted environment or tenant ID saves here and is caught there.

See Configuration & Profiles for full details on auth methods and profile management.

add-profile flags

Flag	Description
--url	Server URL: gateway URL for platform auth, instance URL for oauth2/token (required)
--auth-method	platform, oauth2, or token (default: token)
--environment-id	Platform environment ID for platform auth (the preferred level; mutually exclusive with --tenant-id)
--tenant-id	Tenant ID for platform auth (the legacy level; mutually exclusive with --environment-id)
--no-verify	Save without checking the credentials against the server, for offline or pre-seeded configs

Passing both scope flags is a usage error: you create an integration at one level and its credential only works with that level's header, so one of the two is wrong. Passing neither with --auth-method platform saves an organization-scoped profile, and the command says so.

config add-profile prompts for credentials (token, client ID, client secret), with hidden input, which keeps them out of shell history and process listings.

With no interactive input available, use env: or file: secret references in the config file (see Secrets & Keychain).

SSO / No local accounts

On a Jamf Pro instance using SSO with local admin accounts disabled or unavailable, pro setup --credentials create will not work: it requires a local username and password to bootstrap credentials. Create the API client in the Jamf Pro console, then hand its ID and secret to pro setup --credentials existing (the default) or to config add-profile.

Step 1: Create an API role

1. In Jamf Pro, go to Settings > System > API roles and clients
2. Click New under the API Roles tab
3. Give it a name (e.g., jamf-cli)
4. Assign the privileges you need; the scope options above are a guide to what each level covers
5. Save

Step 2: Create an API client

1. Still in Settings > System > API roles and clients, select the API Clients tab
2. Click New
3. Give it a display name (e.g., jamf-cli)
4. Assign it to the API role from step 1
5. Set an appropriate access token lifetime
6. Save, then click Generate Client Secret
7. Copy both the Client ID and Client Secret; Jamf Pro shows the secret once

Step 3: Configure the CLI

# Either: setup's existing-client branch
jamf-cli pro setup --url https://jamf.company.com
# You'll be prompted for client ID and client secret (hidden input)

# Or: add-profile, which takes the same pair
jamf-cli config add-profile prod \
  --url https://jamf.company.com \
  --auth-method oauth2

Both verify the pair with one token exchange and write nothing if it fails. Run jamf-cli config validate --connectivity afterwards to confirm the profile resolves.

Validate Your Configuration

Run config validate to check the config file structure and secret resolution, and to test server reachability:

jamf-cli config validate
jamf-cli config validate --connectivity

validate also finds platform profiles left over from the beta. It reports the retired {region}.apigw.jamf.com host for each profile naming it, with the GA replacement URL, and it fails a profile that sets both environment-id and tenant-id:

 NAME   SCOPE                    STATUS   MESSAGE
 url    platform-graham          fail     https://eu.apigw.jamf.com is the retired Jamf Platform gateway; use https://eu.api.jamfcloud.com

Any failing check makes the command exit 1.

See Configuration & Profiles#Validate for example output and profile management commands.

Config File Location

The config file follows XDG conventions:

Priority	Path
1	$XDG_CONFIG_HOME/jamf-cli/config.yaml
2	~/.config/jamf-cli/config.yaml (XDG default)

Use jamf-cli config path to see which file is active.

Shell Completion

Auto-install

jamf-cli completion install

Detects your shell (bash, zsh, or fish) and installs completions to the standard location.

Manual install

# Bash (Linux)
jamf-cli completion bash > /etc/bash_completion.d/jamf-cli

# Bash (macOS with Homebrew)
jamf-cli completion bash > $(brew --prefix)/etc/bash_completion.d/jamf-cli

# Zsh
jamf-cli completion zsh > "${fpath[1]}/_jamf-cli"

# Fish
jamf-cli completion fish > ~/.config/fish/completions/jamf-cli.fish

# PowerShell
jamf-cli completion powershell | Out-String | Invoke-Expression

Next Steps

• Configuration & Profiles: auth methods and multi-environment setup
• Pro Command Renames (upgrading from v1.28.0 or earlier): every pro resource name that moved in v1.29.0, and what each retired spelling does now
• Platform API GA Migration (coming from the public beta): base URL, credentials, scope, and the commands refused on a gateway profile
• Jamf Pro Commands, Platform API Commands, Jamf Platform Commands, Jamf Protect Commands, Jamf School Commands: every available command
• Pro Workflows, Platform Workflows, Protect Workflows, School Workflows: recipes for daily use