Use profiles in scripts and CI

These steps apply to the CLI. VS Code asks you to choose a profile in its own interface; see Set up Connection Profiles.

Profile resolution order

When a CLI command needs Azure DevOps credentials, Atomize chooses a profile in this order:

1. --profile <name> flag on the command
2. ATOMIZE_PROFILE environment variable
3. Default Azure DevOps profile (set via atomize auth use)

If none of these names a profile, the command stops and tells you to run atomize auth add. ATOMIZE_PAT is not a fallback for connected commands: it only supplies the token when atomize auth add creates a profile.

This order applies to CLI commands that read Azure DevOps, such as a connected generate, Online Validation with validate, fields list, queries list, and grounded AI drafts and improvements. The Copilot Session itself does not use profile resolution: see AI Drafting: Copilot Session. VS Code asks you to choose a profile for each connected command.

Managing multiple profiles

You can have as many profiles as you need: one per organization, project, or environment.

# Two ADO profiles: personal and work
atomize auth add personal --org-url https://dev.azure.com/personal-org ...
atomize auth add work     --org-url https://dev.azure.com/work-org ...

# Switch between them per-run
atomize generate template:backend-api --profile personal
atomize generate template:backend-api --profile work

# Or change the default
atomize auth use work

Switching the default

atomize auth use              # pick interactively
atomize auth use work-ado     # set by name

Azure DevOps is currently the only profile type with a default to set.

Removing a profile

atomize auth remove old-profile
atomize auth rm old-profile   # alias

If the removed profile was the default for its platform, Atomize prompts you to assign a new default. In scripts, pass --confirm to skip the confirmation and --new-default <name> to choose the replacement.

CI/CD setup

For automated environments, inject the PAT via stdin and create a short-lived profile in the job workspace.

- name: Generate Tasks
  env:
    AZURE_DEVOPS_PAT: ${{ secrets.AZURE_DEVOPS_PAT }}
  run: |
    echo "$AZURE_DEVOPS_PAT" | atomize auth add ci \
      --org-url "${{ secrets.AZURE_DEVOPS_ORG_URL }}" \
      --project "${{ secrets.AZURE_DEVOPS_PROJECT }}" \
      --team "${{ secrets.AZURE_DEVOPS_TEAM }}" \
      --default \
      --pat-stdin \
      --insecure-storage

    atomize generate template:backend-api \
      --execute \
      --auto-approve \
      --continue-on-error

Why --pat-stdin? Passing the token as a flag (--pat abc123) risks it appearing in process listings (ps aux) or shell history. Reading from stdin keeps it out of both.

If your runner has a working OS keychain, you can omit --insecure-storage. On headless runners, the flag explicitly opts into Atomize's local encrypted file fallback for that job.

You can also provide the PAT through ATOMIZE_PAT while still creating a profile:

- name: Generate Tasks
  env:
    ATOMIZE_PAT: ${{ secrets.AZURE_DEVOPS_PAT }}
  run: |
    atomize auth add ci \
      --org-url "${{ secrets.AZURE_DEVOPS_ORG_URL }}" \
      --project "${{ secrets.AZURE_DEVOPS_PROJECT }}" \
      --team "${{ secrets.AZURE_DEVOPS_TEAM }}" \
      --default \
      --insecure-storage

    atomize generate template:backend-api --execute --auto-approve

Next steps

Rotate expired tokens with the rotation steps. For machine-readable output, exit codes, and failure handling, see Automate the CLI; every command is in the CLI reference.