A GitHub Actions job is just a fresh Linux, macOS, or Windows machine that exists for the duration of your workflow. Calling Claude from it works exactly like calling Claude from any other server — the CI-specific parts are getting a credential onto that ephemeral machine safely, and making sure a compromised or malicious pull request can't borrow it.
Step 1: choose the authentication path
The simple path — a repository secret. Create an API key in the Claude Console (Settings → API keys), save it as an encrypted Actions secret, and expose it to the job as the ANTHROPIC_API_KEY environment variable. Per Anthropic's authentication docs, the SDKs read that variable automatically, so no credential handling appears in your code. Scope the key to a dedicated workspace for CI so its usage is separately visible and revoking it never touches production.
The keyless path — Workload Identity Federation (WIF). Anthropic recommends WIF for CI/CD and names GitHub Actions among the compatible OIDC issuers. The job requests a short-lived identity token from GitHub, exchanges it at Anthropic's token endpoint for a short-lived Claude API access token, and the SDK refreshes it automatically before expiry. Nothing long-lived exists to leak. The one-time setup — a service account, federation issuer, and federation rule in the Claude Console — is covered in the WIF article.
The cloud-platform path. If your organization consumes Claude through AWS, note that the AWS default credential chain includes web identity federation — the standard mechanism by which a GitHub Actions job assumes an IAM role with no stored AWS key. That role can then call Amazon Bedrock (via AnthropicBedrockMantle) or Claude Platform on AWS (via AnthropicAWS, which also needs AWS_REGION and ANTHROPIC_AWS_WORKSPACE_ID set) using SigV4 signing, with access governed by IAM policy rather than by a secret.
Step 2: install and pin
Installation is one line per ecosystem — pip install anthropic for Python (3.9+), npm install @anthropic-ai/sdk for TypeScript. In CI, always install from a lockfile or a pinned version so a surprise SDK release can't break your pipeline mid-week; see version pinning. The workflow step that runs your script needs nothing Claude-specific beyond the environment variable:
# scripts/ci_smoke_check.py — run by a workflow step with
# ANTHROPIC_API_KEY exposed from an encrypted Actions secret
from anthropic import Anthropic
client = Anthropic() # reads ANTHROPIC_API_KEY from the environment
resp = client.messages.create(
model="claude-haiku-4-5",
max_tokens=64,
messages=[{"role": "user", "content": "Reply with the word: ready"}],
)
print(resp.content[0].text)
Step 3: contain the blast radius
Three guardrails matter more than any other configuration in this workflow:
Keep secrets away from untrusted code. Workflows triggered by pull requests from forks should not receive the Claude secret at all. Use GitHub environments with protection rules for jobs that need the key, and keep Claude-calling jobs off the default pull-request trigger unless you've thought through who can open one.
Never print the credential. GitHub masks registered secrets in logs, but masking can't catch transformed values. Don't dump the environment in debug steps. (If you script with Anthropic's ant CLI, its --debug flag redacts the API key in its HTTP traces — but the same caution applies to your own logging.)
Cap the cost of a bad day. A retry loop plus a bug can burn tokens fast in an unattended job. Use a cheap model for CI checks (Haiku 4.5), keep max_tokens small, set workflow timeouts, and put integration tests behind a schedule or label rather than every push — the pattern from the pytest article.
ant CLI's browser-based ant auth login flow is designed for development machines. For CI, servers, and containers, Anthropic's guidance is to use WIF (or an injected key) instead.Where to go next
The companion piece, injecting Claude credentials into CI/CD pipelines, covers GitLab and Buildkite too. For the container image your job might build, see containerizing Claude SDK applications.