The CLI in CI/CD

In a pipeline you don't want secrets committed to a repo or pasted into CI settings one by one. The CLI pulls them from a vault at runtime and injects them into your process.

1. 1

   Set the non-interactive credentials in your shell or CI secrets store. Exchange your 1ck_ key at POST /v1/auth/api-key-token (see Foundations), or use your 1ck_ key directly as ONECLAW_API_KEY. Use the vault UUID from 1claw vault list or from the Foundations track.

   bash Copy

   export ONECLAW_TOKEN="your-jwt"
   export ONECLAW_VAULT_ID="your-vault-uuid"

2. 2

   Seed your vault with a local .env file first.

   bash Copy

   1claw env push .env

3. 3

   Pull secrets into a .env file for tooling that reads one.

   bash Copy

   1claw env pull -o .env.production

4. 4

   Or skip the file entirely and run a command with secrets injected as env vars. This is the safest option since nothing lands on disk.

   bash Copy

   1claw env run -- npm start

- name: Deploy with secrets
  env:
    ONECLAW_TOKEN: ${{ secrets.ONECLAW_TOKEN }}
    ONECLAW_VAULT_ID: ${{ secrets.ONECLAW_VAULT_ID }}
  run: |
    npx @1claw/cli env run -- npm run deploy

Your build process now starts with secrets injected straight from the vault, with no plaintext secrets checked into the repo or pasted into CI config.

Where this goes wrong in practice. CI is the place secrets leak most often, because a pipeline is a machine that prints things for a living.

• Values reach the log. Any step that echoes an environment, runs with set -x, or dumps a failed request body publishes the secret to anyone who can read the build. The official GitHub Action emits ::add-mask:: before export for exactly this reason.
• Pull requests from forks inherit the workflow. A deny-by-default ref list is what stops an untrusted branch from running a job that can read your vault.
• One CI credential is shared by every job. Convenient, and it means the smallest job on the least trusted branch holds the same access as the deploy.
• The key is stored in CI and forgotten. A key in a CI secret store is a key with no expiry in a system many people can configure, which is why the agent key should be exchanged for a short-lived token at job start rather than used directly.
• Caches and artifacts outlive the job. A .env written for a build step and left in a cached directory is available to every subsequent run.