Channels

Purpose and Scope

A channel is the operational path through which automation is allowed to interact with Claude-related systems. In this repository, the clearest channel implementation is GitHub Actions: workflows define when automation can run, which repository events can invoke it, what credentials are available, and which build, release, or Claude Code actions can execute. Treating channels as a first-class primitive helps maintainers reason about security and behavior separately from application code. A workflow channel is not just a script; it is the combination of trigger, identity, permissions, environment, and downstream API or package operation.

Sources: .github/workflows/claude.yml, .github/workflows/ci.yml, .github/workflows/create-releases.yml, .github/workflows/publish-npm.yml

The official GitHub Actions Workload Identity Federation guidance frames CI authentication around short-lived identity tokens instead of long-lived API keys. The repository reflects both patterns. Release, publish, and build workflows request id-token: write, which is the GitHub Actions permission needed for OpenID Connect token issuance. The Claude Code workflow grants id-token: write too, but its action configuration currently passes anthropic_api_key from repository secrets. When documenting or changing channels, keep that distinction explicit: a channel may have OIDC capability even if a particular step still uses a stored secret.

Sources: .github/workflows/claude.yml, .github/workflows/ci.yml, .github/workflows/create-releases.yml, .github/workflows/publish-npm.yml

Relevant Source Files

• src/resources/beta/models.ts - Defines beta model listing and retrieval, including ?beta=true, optional betas headers, and beta model capability types used to decide which model features a channel can safely target.
• src/resources/models.ts - Defines stable model listing and retrieval, plus capability metadata such as batch, citations, code execution, context management, effort, image input, and PDF input support.
• .github/workflows/claude.yml - Defines the Claude Code interaction channel triggered from issues, pull request comments, review comments, and reviews when users mention @claude.
• .github/workflows/ci.yml - Defines validation channels for lint, build, tests, breaking-change detection, and artifact upload; the build job includes id-token: write and fetches a GitHub OIDC token in private-repository conditions.
• .github/workflows/create-releases.yml - Defines the scheduled and main-branch release channel, scoped to the public repository, protected by the production-release environment, and permitted to request an OIDC token.
• .github/workflows/publish-npm.yml - Defines the manual NPM publishing channel with a required package path input, production-release environment, and id-token: write permission.

Core Primitives

The channel primitive has five source-backed parts. The first is the trigger: claude.yml listens to issue comments, pull request review comments, newly opened or assigned issues, and submitted pull request reviews, while CI and release workflows listen to pushes, pull requests, schedules, or manual dispatch. The second is the admission rule: claude.yml only runs when the relevant body or title contains @claude, and release workflows further restrict repository and branch. These conditions are the first boundary between general repository activity and authorized Claude-related automation.

Sources: .github/workflows/claude.yml, .github/workflows/ci.yml, .github/workflows/create-releases.yml, .github/workflows/publish-npm.yml

The third primitive is identity. GitHub Actions can expose OIDC request variables only when id-token: write is granted, and repository workflows use that permission in build, release, publish, and Claude Code jobs. The fourth primitive is scope. Workflow permissions such as contents: read, pull-requests: read, issues: read, and actions: read limit what the job can inspect. The fifth primitive is execution: actions such as checkout, setup-node, bootstrap, build, test, release triggering, and package publishing convert the authorized channel into concrete repository work.

Sources: .github/workflows/claude.yml, .github/workflows/ci.yml, .github/workflows/create-releases.yml, .github/workflows/publish-npm.yml

System-to-Code Mapping

The Claude Code channel is designed for human-in-the-loop repository collaboration. It does not run on every issue or review event; it gates execution on the presence of @claude. Once admitted, it checks out the repository and invokes anthropics/claude-code-action@v1. The workflow grants read access to repository content, pull requests, issues, and actions so Claude can inspect the conversation and CI results. The action configuration also shows optional extension points, including additional permissions, a custom prompt, and claude_args for CLI-style behavior customization.

Sources: .github/workflows/claude.yml

The CI channel is the general quality gate for the SDK and package family. It uses Node 22, runs repository bootstrap, updates internal symlinks in third-party packages, builds all packages, and then performs linting or tests. The build job also demonstrates a federated-token flow for private repository artifact upload: when repository and branch conditions match, actions/github-script calls core.getIDToken() and passes the resulting token as AUTH to an upload script. That pattern is the closest repository example of a short-lived workflow identity being exchanged into downstream service access.

Sources: .github/workflows/ci.yml

The release and publish channels are more constrained because they affect public packages. create-releases.yml runs on a daily schedule and on pushes to main, but the release job only proceeds for refs/heads/main in anthropics/anthropic-sdk-typescript. It targets the production-release environment and publishes packages when release outputs indicate that releases were created. publish-npm.yml is manual and requires a path input, making it suitable for targeted package publication such as the root SDK or provider packages. Both workflows request id-token: write, preserving the option to use short-lived identity in protected release paths.

Sources: .github/workflows/create-releases.yml, .github/workflows/publish-npm.yml

Model Capability Discovery in Channels

Channels that call Claude should not hard-code assumptions about model support. The stable Models resource exposes retrieve(modelID, params?, options?) and list(params?, options?), backed by /v1/models and /v1/models/{modelID}. The response types include capability structures that describe whether a model supports batch processing, citations, code execution tools, context-management strategies, effort levels, image input, and PDF input. In a workflow channel, this metadata is useful before enabling a job to submit a batch, request code execution, process PDFs, or rely on reasoning-effort controls.

Sources: src/resources/models.ts

The beta Models resource mirrors the stable API but routes to /v1/models?beta=true and /v1/models/{modelID}?beta=true. It also accepts a betas parameter that is converted into the anthropic-beta header. This matters for channels that intentionally exercise beta capabilities or Managed Agents-adjacent behavior: the channel should make beta participation visible in configuration and logs, rather than silently mixing stable and beta assumptions. The SDK’s generated resource shape makes the beta boundary explicit in both path construction and header construction.

Sources: src/resources/beta/models.ts

Compact Reference

Component	Public behavior	Channel relevance
client.models.list(params?, options?)	Pages through /v1/models using Page<ModelInfo>	Discover supported models before CI, release, or automation jobs choose model-dependent features.
client.models.retrieve(modelID, params?, options?)	Fetches /v1/models/{modelID}	Resolve aliases and inspect a specific model for channel policy decisions.
client.beta.models.list(params?, options?)	Pages through /v1/models?beta=true and can set anthropic-beta	Make beta model discovery explicit for beta-enabled automation.
client.beta.models.retrieve(modelID, params?, options?)	Fetches /v1/models/{modelID}?beta=true and can set anthropic-beta	Resolve beta model IDs or aliases under a declared beta header.
.github/workflows/claude.yml	Runs Claude Code when repository participants mention @claude	Interactive agent channel for issues and pull requests.
.github/workflows/ci.yml	Runs lint, build, test, and breaking-change checks	Validation channel; also demonstrates conditional OIDC token retrieval.
.github/workflows/create-releases.yml	Creates releases from schedule or main pushes	Protected release channel for automated package publication.
.github/workflows/publish-npm.yml	Manually publishes selected package paths	Operator-triggered publication channel with a required target path.

Implementation Guidance

When adding a new channel, start with the admission rule before writing scripts. Decide which event should open the channel, which repository, branch, environment, or comment pattern should authorize it, and whether the job needs a long-lived secret, a short-lived OIDC identity token, or both during migration. Then choose the smallest GitHub permission set that lets the job inspect what it needs. The existing workflows show this pattern clearly: read-only content permissions are common, release jobs use protected environments, and publishing requires an explicit path or release signal.

Sources: .github/workflows/claude.yml, .github/workflows/ci.yml, .github/workflows/create-releases.yml, .github/workflows/publish-npm.yml

For Claude-facing work, pair channel design with model discovery. A channel that runs on pull request comments may need conservative defaults and read-only repository access, while a release channel may need deterministic model and capability selection if it generates changelog or package metadata. Use client.models for stable production behavior and client.beta.models only when the workflow intentionally opts into beta headers. Next, review authentication and client configuration for credential handling, workload identity federation for short-lived CI credentials, and models and token counting for capability-aware model selection.