You can now retry all failed jobs in a build with a single API call, matching the behavior of the "Retry Failed Jobs" button in the UI.

REST: POST /organizations/{org}/pipelines/{pipeline}/builds/{number}/retry_failed_jobs GraphQL: buildRetryFailedJobs mutation

Both return the count of jobs queued for retry.

An optional filter parameter states lets you choose which job states to retry, so you can target exactly the failures that matter:

• failed: Jobs that ran and exited with a non-zero status
• soft_failed: Jobs that failed but were marked with soft_fail — the build continues regardless
• expired: Jobs that weren't accepted by an agent before the timeoug
• canceled: Jobs that were manually or programmatically canceled before completing

By default, all failed states are retried. Pass a filter to narrow it — for example, retry only failed jobs without re-queuing dozens of soft failures that would just add pressure to your queue.

Detail available in the GraphQL or REST docs.

User API access tokens now have an explicit GraphQL access mode. You can create tokens that can run GraphQL queries but not mutations.

When creating or editing a user API access token, the GraphQL permission offers three options:

• Disabled: No GraphQL API access
• Read-only: Can run queries, but mutations are rejected
• Full access: Can run both queries and mutations

Key details

• Existing tokens are unaffected: All previously created GraphQL-enabled tokens continue to work with full access.
• Mutation guard: Read-only tokens are blocked before any mutation code runs, so there is no risk of partial side effects.
• Audit visibility: The selected GraphQL access mode is displayed in the token summary and the organization API access audit view.

For more information, see the API access tokens documentation.

You can now save a default filtered view directly from the Tests tab. After configuring your filters, save them as your default view so the Tests tab loads with your preferred filters each time you visit.

This makes it easier to:

• Jump straight to the test results that matter most to your team
• Share a consistent, filtered view across your organization
• Reduce time spent reconfiguring filters between visits

Agents running buildkite-agent start now receive jobs in sub-second time, with no configuration changes necessary. Agent v3.122.0 replaces the polling-based dispatch with a persistent streaming connection, enabled by default.

What changed

Agent v3.122.0 changes the default agent API endpoint to agent-edge.buildkite.com, a new Go-based edge service that maintains a ConnectRPC stream to each connected agent. When a job is dispatched, it's pushed to agents over this stream rather than waiting for the next poll.

Why this matters

Previously, agents checked for work by polling every 10 seconds, plus random jitter to avoid synchronized requests across fleets. A job dispatched right after a poll could wait up to 20 seconds before that agent checks in again. Across a pipeline with many steps, that wait compounds.

With streaming dispatch, job acceptance latency drops to under 1 second. For an average build, that can save minutes of unnecessary wait time - resulting in faster and more efficient builds.

Availability

This is now the default for all agents running buildkite-agent start, including those on the Elastic CI Stack for AWS.

Buildkite Hosted Agents, Agent Stack for Kubernetes, and workflows using --acquire-job use different dispatch mechanisms and don't benefit from this change.

Upgrade to Agent v3.122.0 to get streaming dispatch by default. We'd love to hear how it goes! Reach out to support@buildkite.com with any feedback.

Annotations can now be scoped to individual jobs. Previously, all annotations lived at the build level, but with large builds this meant scrolling through a list of annotations and mentally mapping each one back to its job. Now, test failures, lint errors, etc. can show up next to the job that produced them. Existing annotations are unaffected — the default scope remains build.

🆕 What's new

• Job-scoped annotations via the agent CLI: Use buildkite-agent annotate --scope job to create an annotation that's tied to the current job.

  buildkite-agent annotate --scope job "3 tests failed — see details below"

• Annotation indicators on jobs: Jobs with annotations show an indicator on the canvas. When you open a job's drawer, its annotations are available in a dedicated Annotations tab.

  

• Annotations tab with build and job sub-tabs: The Annotations tab now has separate Build and Jobs sub-tabs, with links to jump to the originating job.

  

• Full API support: Job annotations are fully supported in both the REST API and GraphQL API, including create, read, and delete operations.

• Real-time updates: Annotations update in real-time as your build runs — no page refresh needed.

Job-scoped annotations require Buildkite Agent v3.112 or newer and are not available in the classic build page experience. For more information, see the annotations documentation.

Steps on the build canvas now display their run duration directly on each node, so you can quickly spot slow steps and see the progress of running jobs without clicking into them. Steps that haven't started yet show a -- placeholder, so you can see at a glance which parts of your build are still waiting to run.

Group steps on the build canvas are now collapsed by default, making complex dependency graphs much easier to follow at a glance.

• Collapsed by default: Group steps are now collapsed when you open a build, reducing visual noise and improving page performance on large pipelines.
• Expand and collapse all: A new button on the canvas lets you expand or collapse all group steps at once. You can also press G to toggle.

• Auto-expand on failure or input: Groups containing failed steps or steps waiting for user input are automatically expanded, so you never miss something that needs your attention.

You can still expand or collapse individual group steps by clicking on them.

You can now toggle case-sensitive matching when searching through job logs on the new build page. Click the Aa button in the log search bar to switch between case-sensitive and case-insensitive search.

The Buildkite MCP Server now sanitizes all tool responses to protect agents from prompt injection attacks. Build logs, pipeline names, commit messages, and annotations are passed through a multi-stage sanitization pipeline before reaching the agent — filtering invisible characters, stripping control sequences, sanitizing HTML, and neutralizing LLM delimiter tokens.

The list_builds tool no longer requires a pipeline_slug. When omitted, it queries across the entire organization, making it easier for agents to find failing builds without needing to call the tool once per pipeline.

When the Buildkite API returns an authentication error, the MCP server now surfaces it as a proper 401 response rather than a generic tool error. This means MCP clients and agents can correctly prompt you to re-authenticate instead of failing with a cryptic message.

A new --max-log-bytes flag (and BKLOG_MAX_LOG_BYTES environment variable) lets you cap how much log data the server downloads per request, defaulting to 100 MB. This gives you more control over memory consumption when working with large pipeline logs.

These improvements apply to both the open-source MCP server and the Remote MCP server.

The Buildkite Remote MCP server now rate limits on a per-user basis, so one person can't chew through your organization's entire API quota.

If you've been hesitant to roll out the remote MCP server broadly, this should help. Each user gets their own limit of 50 requests per minute, so you can invite your whole team to connect their AI coding assistants to Buildkite without worrying about one heavy user blocking everyone else.

There's nothing to configure, per-user limits apply automatically. If someone hits their limit, only their requests are throttled. Everyone else carries on as normal.

For more on API rate limits across Buildkite, see the Remote MCP server limits documentation.

Organization administrators can now view the service quotas that apply to their organization directly in Buildkite. Head to Settings > Quotas to see your actual limits, broken down by product area.

Each quota shows the effective limit for your organization. A Custom badge indicates a limit that differs from the default for your plan, and an Exceeded in last 24h badge flags any quotas your organization has hit recently.

If you need a quota increased, contact support@buildkite.com or reach out to your Technical Account Manager.

For the full list of default limits, see the Limits documentation.

We've been busy making changes to the way the Buildkite CLI can authenticate against organizations. We've implemented some features, as well as improvements to security so folks can feel safer in giving the CLI assess to their Buildkite organization.

OAuth availability

The CLI can now be authenticated via OAuth, with permissions scoped within the user's own accepted access. The permissions can also be customized to meet your needs for CLI use.

A single auth family

We've introduced an auth command, with various subcommands, to ensure all things authentication can be found in a logical spot. whoami and use can still be used, for now, performing the same actions as their new subcommands, bk auth status and bk auth switch, respectively.

We've also implemented bk auth login, replacing configure add, and bk auth logout, a new command which will clear keychain credentials for the current authenticated organization, or all keychain configurations with the --all flag.

No more text-based tokens

The CLI, until now, has been writing API tokens to a config file, typically at ~/.config/bk.yaml, which is convenient but a pattern we've wanted to move away from. As of v3.32.0, we'll no longer write to this file, only read from it. API tokens will be encrypted and stored in the OS keychain exclusively.

The CLI will fall back to reading bk.yaml files, so if those are in use, or you wish to continue using them, you can, you'll just see a warning in the terminal when you do. If you do wish to store API tokens in your bk.yaml file, you can manually adjust the file;

organizations:
  my-cool-org:
    api_token: bkua_hunter28265989387498729792378

A lot to take in? Read the Buildkite CLI documentation

The Buildkite SDK now supports C#, starting in v0.8.0. You can define and manage your Buildkite pipelines programmatically in C#, with the same type-safe experience available in the SDK's other supported languages: JavaScript/TypeScript, Python, Go, and Ruby. The package is now available for download from NuGet.

Several of our most popular plugins now support GCP and Azure, making it easier to use Buildkite with your preferred cloud provider.

The secrets plugin fetches secrets and injects them as environment variables into your builds. It now supports GCP Secret Manager and Azure Key Vault, in addition to Buildkite Secrets.

The cache plugin stores and restores build cache between pipeline runs. It now supports Google Cloud Storage and Azure Blob Storage backends alongside Amazon S3.

The docker-cache plugin speeds up Docker builds by caching images between pipeline runs. It now supports Azure Container Registry as a caching provider.

The docker-image-push plugin builds and pushes Docker images to Google Artifact Registry and Azure Container Registry alongside its existing support for Amazon ECR and Docker Hub.

(New) The azure-login plugin authenticates your Buildkite agents with Azure using managed identity or service principal credentials. Pair it with our secrets, docker-image-push, or cache plugins to streamline your Azure workflows.

You can now save filtered views directly from the Suite Summary page. After configuring your filters, save them as a custom view that will appear in your suite navigation for quick access later.

This makes it easier to:

• Quickly access the summary trends you check most often
• Share a consistent, filtered view across your team
• Reduce time spent reconfiguring filters between visits

You can now set an expiry date when creating an API access token. Once a token expires, any API requests using it will stop working, so forgotten tokens don't become a security risk.

Choose from preset durations (1 day, 7 days, 30 days, 90 days, 1 year), pick a custom date, or select "Never" to create a token with no expiry.

Key details

• Expiry is set at creation and cannot be changed afterward. To extend access, create a new token.
• You'll receive an email 3 days before a token expires, with a link to create a replacement.
• Expired tokens are automatically deleted after a grace period.
• All existing tokens are unaffected and continue to work with no expiry.

For more information, see the API access tokens documentation.

Test Engine Client (bktec) v2.1.0 introduces a new custom test runner and several improvements for pytest users.

🛠️ Custom test runner

You can now use bktec to split tests with any test runner that supports running specific test files via command-line arguments. For details, see the custom test runner documentation for Test Engine Client.

🐢 Split slow files by example (pytest)

You can now split slow test files by individual test examples when using pytest. This helps distribute long-running tests more evenly across agents and reduces build times.

🏷️ Tag filters (pytest)

The new --tag-filters option allows you to select and run tests based on a single key:value tag pair when using pytest.

Example:

bktec run --test-runner pytest --tag-filters "test.type:integration"

Read more about splitting slow files by example and tag filters in the Test Engine Client pytest documentation.

bktec v2.1.0 Release Notes.

We're pleased to announce migration documentation to help our customers transition from our Elastic CI Stack for AWS to the Buildkite Agent Stack for Kubernetes (agent-stack-k8s). This documentation addresses key differences between the two platforms and provides practical guidance for migrating your CI/CD workloads to Kubernetes:

• Amazon ECR authentication - Learn how to authenticate with Amazon Elastic Container Registry from Kubernetes environments.
• Docker login configuration - Understand the options for configuring Docker registry authentication in agent-stack-k8s.
• Package management - Discover approaches for handling required software packages and dependencies in Kubernetes-based builds.
• Hook execution differences - Understand the agent hook execution differences in agent-stack-k8s.
• Secrets management - Explore options for managing secrets when migrating your S3-based secrets.
• Docker daemon configuration - Learn about Docker daemon access patterns and container building approaches.

These guides are designed to help you understand the architectural differences between EC2 and Kubernetes environments, and provide practical examples for adapting your existing pipelines to use agent-stack-k8s.

Have questions or need help? Reach out to us at support@buildkite.com

You can now bring your CircleCI pipelines over to Buildkite even faster! Our pipeline conversion tool now supports more cases to convert CircleCI workflows to Buildkite pipelines. In addition to generating pipeline YAML that you can run, the output also includes information about required agent setup and other adjustments that may be needed to get a complete functional pipeline.

This makes it simple to:

• Copy an existing CircleCI pipeline
• Instantly see the equivalent Buildkite pipeline steps
• Speed up trying out Buildkite with less manual rewriting

👉 Try it out in the Pipeline Converter
📖 See the documentation

Starting in Agent v3.104.0, OIDC tokens are automatically redacted from build logs by default. This security improvement uses the Job API (a local API exposed over a unix socket) to perform redaction.

By default, the Job API environment variables (BUILDKITE_AGENT_JOB_API_SOCKET and BUILDKITE_AGENT_JOB_API_TOKEN) and socket are available in the job environment. However, when running buildkite-agent oidc request-token in a container or sandbox, these variables and the socket path must be explicitly passed through. See this docker-compose example.

If the Job API is not accessible, the command will fail with:

buildkite-agent: fatal: failed to create Job API client: BUILDKITE_AGENT_JOB_API_SOCKET empty or undefined

Who is affected: Customers using buildkite-agent oidc request-token outside of a standard Buildkite job environment.

Workaround: If you're unable to make the Job API available to buildkite-agent oidc request-token, you can disable automatic redaction with:

buildkite-agent oidc request-token --skip-redaction

If you need to roll back, v3.103.1 does not include this change.