SUME_CONFIG_DIR in GitHub Actions: keep Sume CLI config off the runner

Set SUME_API_KEY from a repository secret and set SUME_CONFIG_DIR to a temporary directory, so the Sume CLI keeps any local state out of the default ~/.sume-com/config.json. Then run sume doctor --agent --json as a first step: it checks local readiness without calling the API, so a bad setup fails before any paid command runs.

The variables are from the CLI configuration page. The secret handling is from GitHub's own guide, which this post cites.

Why isolate the config directory at all?

The CLI stores local configuration under ~/.sume-com/config.json, and the security page lists that file among the things to never print or commit. On a hosted runner the home directory is throwaway. On a self-hosted runner it is shared between jobs, and a config written by sume login or sume auth setup by one job can be picked up by another.

SUME_CONFIG_DIR is documented as an override for the local config directory for tests or isolated environments. Pointing it at a per-job temp path means a stale key from an earlier run cannot be used by accident.

What does the workflow look like?

The hosted installer puts sume under ~/.sume-com/bin, so add that to the path. GitHub's guide shows secrets passed in through env with the secrets context, and says secrets are masked in logs. The installer verifies the binary against checksums.txt; for a pinned version, see the pin-a-release post.

name: sume-check
on: [workflow_dispatch]
jobs:
  check:
    runs-on: ubuntu-latest
    env:
      SUME_API_KEY: ${{ secrets.SUME_API_KEY }}
      SUME_CONFIG_DIR: ${{ runner.temp }}/sume-config
    steps:
      - name: Install sume
        run: |
          curl https://cli.sume.com/install -fsS | bash
          echo "$HOME/.sume-com/bin" >> "$GITHUB_PATH"
      - name: Readiness (no API call)
        run: sume doctor --agent --json
      - name: Who am I
        run: sume auth status
      - name: Balance
        run: sume balance

What can still go wrong?

Secrets are not passed to the runner when a workflow is triggered from a forked repository, per GitHub's guide, so a pull request from a fork gets an empty SUME_API_KEY. The CLI will then report a missing key; that is the secret model working, not a Sume fault. Do not work around it by echoing keys or loosening triggers.

Keep paid commands behind explicit confirmation. The CLI requires --confirm-paid for Avatar generation that can spend credits and --confirm-submit for non-paid writes such as cancelling a job, so a pipeline cannot spend by accident. Image, Video and Music have no CLI submit command; call the API for those and recover with sume jobs.

Do not upload sume doctor output as a build artifact without --agent. Agent mode redacts or summarizes URL-like fields and account or workspace details where supported.

Should the key live in a repo secret or an environment secret?

GitHub supports secrets scoped to a deployment environment, which needs admin access in organization repositories. For a key that can spend credits, an environment with required reviewers is a better home than a repo-wide secret, because only jobs that target that environment can read it. That is a GitHub feature, so check GitHub's page for the exact controls before you rely on it.

Create the key in the API Keys dashboard with only the scopes the job needs. Scopes are fixed at creation, so a key made before a scope existed cannot be upgraded; mint a new one and rotate.

How do I know the isolation worked?

Add a step that proves it. After sume doctor --agent --json, list the temp config directory and confirm the default location is untouched. On a clean runner ~/.sume-com/config.json should not exist unless something ran sume login or sume auth setup, which this workflow never does. The CLI also documents sume auth setup --api-key for CI, but with SUME_API_KEY in the environment you do not need to persist the key to disk at all.

If a later step fails with a missing key, check where the variable is defined. A secret set at job level is visible to every step in the job, while a secret set in one step's env is not visible to the others. In the workflow above it is job level on purpose, because the install, doctor and balance steps all need it.

Finally, pin what you install. The hosted installer fetches the latest release; for a reproducible pipeline use the direct GitHub binary path with a release tag in place of latest, and verify against the checksums.txt attached to the release, as covered in the pin-a-release post.