What shipped this week

Between September 27 and October 2, 2026, we published 4 changelog entries and 33 releases across 11 public repos. Three things run through them: more control and predictability for platform teams, fewer gaps for teams moving off GitHub Actions, and more of the platform agents can drive directly.

• Tightened how secrets are handled. Pipeline-scoped secrets live in pipeline settings, the Buildkite CLI (bk) migrates GitHub Actions secrets, and the agent now redacts anything shaped like a Buildkite-issued token from job logs. Captured errors redact the secrets registered for that job.
• Expanded what agents can do. The MCP server added pipeline validation, build comparison, test execution traces, and webhook repair, and each Remote MCP connection now pins to an organization.
• Steadied build environments. Agent v4.1.0 reports cache timings and adds commit, pull request, and author attributes to OpenTelemetry spans. Elastic CI Stack for AWS replaces instances whose agent stops responding, the Kubernetes stack completes its move to agent v4, and the agent scaler stops duplicate scale-ins. New RSS feeds announce macOS base image releases on hosted agents. All v3 agent support ends September 3, 2027.
• Closed more gaps in GitHub Actions workflows on Buildkite. Fourteen releases added a Linux arm64 runtime and broader support for vars, secrets, matrix values, and strategy expressions.
• Moved test splitting toward shared pools. The Buildkite test engine client (bktec) 3.2.0 adds commands to plan and run tests from shared scheduler pools, with persistent runners and dynamic parallelism.

Changelog entries

Dates are US Pacific time.

You can now subscribe to RSS feeds for macOS base image releases on Buildkite hosted agents, making it easier to keep up with changes to your build environments.

For updates to stable base images used in production, add the stable RSS feed to your preferred RSS reader.

If your organisation wants access to the latest Xcode betas and runtimes, request a move to the canary channel. You can follow those releases with the canary RSS feed.

You can also explore the available macOS base images and see the Xcode versions, runtimes, and packages included in each image.

This is a first step towards giving you more control over release notifications. We’re also exploring configurable Slack notifications so you can choose the releases that matter most to your organisation.

If you belong to more than one Buildkite organization, you can now choose which one each Remote MCP Server connection uses. Add the organization's slug to the server URL:

https://mcp.buildkite.com/mcp?organization=your-organization

When your MCP client asks you to authorize, that organization is already selected.

This also works with toolset and read-only URLs, such as https://mcp.buildkite.com/mcp/x/pipelines/readonly?organization=your-organization. It's optional: leave it off and you choose an organization when you authorize, just like before.

Working across several organizations? Add a connection for each one, and each connection sticks with the organization in its URL.

Add ?organization= to your MCP server URL and the right organization will be ready the next time you authorize. New to the Remote MCP Server? Get started here.

From 1 January 2027, each minor release line of the Buildkite agent will be supported for one year from its first stable release. The final three months are a deprecation period: agents remain supported, with warnings encouraging you to upgrade. Installing an agent or updating to a newer patch doesn't restart that window.

The policy applies to existing releases, using their original release dates:

• v3.115.x and earlier become unsupported on 1 January 2027. Unsupported agents won't be blocked solely because they're out of support, but compatibility with Buildkite will no longer be guaranteed.
• v3.116.x through v3.121.x become deprecated on that date. They remain supported until their individual one-year windows end.
• Support for all v3 releases ends on 3 September 2027, when the final v3 minor release line, v3.138.x, reaches the end of its support window. Plan your move to v4 before then.

If you run self-hosted agents, check the versions across your fleet and upgrade to the latest stable release. If you stay on an older supported minor release line, use its latest patch.

Buildkite manages updates for your hosted agents. There's nothing you need to do for those agents.

Read the agent version support policy for the full support terms, version checks, and upgrade instructions.

If you have any questions or concerns, reach out to your TAM, or to Buildkite support

If you can edit a pipeline and manage its associated cluster, you can now create and manage secrets directly from Pipeline settings → Secrets.

Pipeline secrets are cluster secrets with access restricted to the current pipeline. You can add branch, queue, build source, or creator conditions to narrow access further, and secret values remain hidden after creation.

The new view keeps pipeline-specific secrets together, shows how many other secrets are managed by the pipeline's cluster, and links to the cluster's secrets page. Restricted secrets now have a lock indicator in cluster settings, making access policies easier to spot. For GitHub Actions pipelines, a dismissible prompt links to secrets setup before the first workflow runs.

Give it a try in your pipeline settings today, and learn more about creating, securing, and using secrets in the Buildkite secrets documentation.

Job logs on the new build page are easier to scan now that Buildkite folds de-emphasized system groups into compact rows by default. Command output and the groups you usually need remain visible, while setup and other supporting output take up less space.

Select a folded row to reveal just that section in place. The job log toolbar also lets you Show system groups temporarily and hide them again, while Show all system groups in display options saves your preference for future job logs. The separate Expand groups and Collapse groups controls open or close the groups currently visible without revealing hidden system groups.

Buildkite automatically keeps relevant output in view:

• Groups explicitly opened in the log remain open
• Following a link to a specific line or range reveals its containing group
• Search includes folded groups and reveals matching output

Buildkite Cache is now available in public preview. It saves and restores files and directories across pipeline jobs and builds. Use it for package manager download caches, compiled dependencies, and other regenerable data to avoid repeating work.

Define what to cache in .buildkite/cache.yml, then use buildkite-agent cache restore and buildkite-agent cache save in your pipeline. Cache keys let you match entries to inputs such as your operating system, architecture, and lockfile contents.

Cache registry policies let you control which jobs can save and restore entries. Use them to prevent untrusted builds from writing caches that trusted builds consume, helping protect against cache poisoning.

Buildkite Cache works with both Buildkite hosted and self-hosted agents. Hosted agents receive a default cache store automatically. For self-hosted agents, configure your own Amazon S3 or S3-compatible storage. Jobs must run on clustered agents with Buildkite agent version 4.0.3 or later.

Buildkite Cache is separate from hosted agent cache volumes: it saves and restores files using cache keys rather than providing attached storage.

See the Buildkite Cache guide for setup instructions and cache policy configuration.

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

Run a pipeline schedule as configured, or customize a one-off build without changing the schedule. Helpful when you need to validate your schedules before turning them on. Two actions on the schedule page make the choice clear:

• Run now asks for confirmation, then creates a build using the schedule's saved message, commit, branch, and environment variables. The build has source schedule, just like an automatic scheduled run, and appears in the schedule's Recent Builds. Use it to test conditions and policies that depend on scheduled builds without waiting for the next run.
• Run with edits opens the familiar, prefilled New Build form for an ad-hoc run. Try a different environment variable value for a one-off validation without updating the saved schedule. These builds keep source ui, rather than schedule.

Neither action changes your saved configuration or the next scheduled run. You can also run a disabled schedule once without enabling it.

The Buildkite Agent Stack for Kubernetes Helm chart now includes built-in support for Slack App integration. You can configure Slack notifications directly in your Helm values without needing a separate sidecar or custom webhook setup. The chart handles token management and channel routing so your pipelines can post build status updates to Slack out of the box.

Understand PR retry patterns in your existing observability tool, without joining webhook data. Buildkite's server-side OpenTelemetry traces include PR metadata, including for GitHub merge-queue builds, and job retry metadata to compare manual and automatic retries and follow attempts.

See how often PRs need retries and which repositories have the most retry activity. Comparing those patterns over time can help you decide where to investigate recurring CI failures and track whether changes reduce retries.

Server-side OpenTelemetry tracing is available only on Enterprise plans. These additions don't change agent-native spans.

Try it with your agent

In [observability tool], what percentage of observed Buildkite PRs
had a manual job retry in the last 7 days?

Write a query using resource attributes buildkite.pipeline.repo and
buildkite.build.pull_request.number, and job span attribute
buildkite.job.retry_source.retry_type = "manual".

Divide distinct PRs with a manual retry by all distinct PRs in the
same dataset and time window, deduplicating by repository + PR number.
Check the tool's attribute mapping and query syntax.

Return the counts and percentage, explaining coverage limitations
and that manual includes API/automation retries. Without data access,
provide runnable steps instead of results.

What's in the traces

• PR resource attributes: buildkite.build.pull_request.number (string) and buildkite.build.pull_request.url (provider URL). Both are omitted without a PR; the URL is omitted when unavailable.
• Job span attributes: buildkite.job.retries_count counts preceding manual and automatic retries (0 for originals, 1 for first retries). buildkite.job.retry_source.job_id links to the preceding job's UUID; buildkite.job.retry_source.retry_type identifies the incoming retry as manual or automatic. Both source attributes are omitted for originals or unavailable predecessors.

Results reflect the traces your tool receives and retains, not every retry; attempts that never started aren't included.

For setup and integration details, see the OpenTelemetry docs.

Elastic CI Stack for AWS v7 is now available, bringing Buildkite Agent v4 to both Linux and Windows instances.

Agent v4 clears out functionality deprecated since v3 arrived in 2018 and makes supported behavior the default. New capabilities have continued shipping in v3, so for most setups the move changes nothing about how you use the agent.

Elastic CI Stack v7 updates its configuration to match. It replaces the tracing and cancellation parameters, removes the timestamp toggle, and drops Agent v3 support.

What happens now

• Upgrading to v7? Start with the Elastic CI Stack v6 → v7 upgrade guide. It covers the stack configuration changes and links to the Agent v4 migration steps. Check custom parameter files, deployment automation, and any settings supplied through AgentEnvFileUrl.
• Using Datadog tracing? You can keep your existing Datadog Agent. Enable OTLP ingestion if it isn't already enabled, then configure Buildkite to send traces to that endpoint. The Datadog tracing migration steps cover the settings.

If you experience any issues, contact support@buildkite.com.

The Buildkite VS Code extension is now available, bringing your pipelines and agents directly into your editor. You can browse and manage pipelines, view agent status, stream job logs, get build notifications, and validate pipeline YAML — all without leaving VS Code.

Install it from the VS Code Marketplace. Full docs are at buildkite.com/docs/platform/vscode-extension.

A few things have shipped in the Buildkite MCP Server since list_tests arrived in August.

Read the steps a dynamic pipeline uploaded

You can now ask your agent what actually ran in a dynamic pipeline. list_step_uploads returns a build's uploads, most recent first, with the state of each one, the job that sent it, and the reason for any rejection. get_step_upload returns a single upload's pipeline as YAML. get_build points agents at both, so an agent debugging a build finds them on its own.

Uploads stay readable for about 30 days, until the build reaches its maximum lifetime.

Know you've seen every failure in a build

get_build_failure_summary now returns job_state_counts, a tally of every job in the build by state. An agent can check that against the problem jobs it was handed and know it has the whole picture, rather than calling list_jobs to make sure nothing was missed.

Manage cluster secrets

Getting a new pipeline running means getting its secrets in place, which has always been a job for a person. create_cluster_secret adds a secret to a cluster, so that part can go to your agent.

list_cluster_secrets and get_cluster_secret cover the other direction. They return a secret's key and description but never its value, so an agent chasing a build that failed on a missing secret can name the problem without seeing the secret itself.

There's one thing to check before you let an agent near this. Toolsets default to all, so an agent holding a write_secrets token can create secrets. To stop that, run the server with --read-only.

Find the test suite behind a pipeline

Ask your agent about a pipeline's tests and it no longer needs you to tell it which suite they're in. list_test_suites_for_pipeline returns the Test Engine suites with runs attributed to a pipeline, so the agent finds the right one and carries on to the tests themselves.

Report a tool that gets it wrong

We want to hear when a tool gives your agent a bad answer. Run the report_issue prompt afterwards and it writes the report for you: what you were after, which tools ran with what arguments, and what came back. It fills in the server version and your client, and redacts tokens and credentials.

Paste it into a new GitHub issue or send it to Buildkite support.

All of this is in the current release, v1.22.0.

Job logs are now limited to 1 GiB (1,024 MiB) by default. You can check your organization’s current log size limit on the Quotas page.

When a job log exceeds the limit, Buildkite cancels the job and adds a Log Size Limit Exceeded event to the timeline. Logs received prior to the limit being reached are retained.

If you need to produce output greater than 1GiB, consider a build artifact.

See the managing log output guide for more ways to trim output. Need a higher limit? We’d love to learn about your use case: support@buildkite.com.

To improve GitHub Actions migration support, the Buildkite GitHub App now requests read-only access to Actions, Variables, and Environments.

These permissions let Buildkite inspect configuration that affects how workflows and deployments run—including configuration variables referenced through ${{ vars.* }}, secret names (not secret values), deployment protection rules, and deployment branch policies—so migrated pipelines can preserve existing behavior and safeguards. All three permissions are read-only; Buildkite will not modify Actions workflows, variables, or environments. The Actions permission also permits reading workflow run logs; Buildkite requests it for migration and configuration compatibility.

Existing installations keep their current permissions until a GitHub organization owner approves the request. New installations request the current permission set when installed.

Buildkite Agent v4 is here. It's the first major version of the agent since v3 arrived in 2018, and it's now the stable release: installations and upgrades that follow the latest or stable channels now receive v4.

v4 clears out functionality deprecated over those eight years and makes current, supported behaviour the default, giving the agent a cleaner baseline for what we build next. New capabilities have continued shipping in v3, so for most setups the move changes nothing about how you use the agent.

The v3 → v4 upgrade guide covers every breaking change and how to migrate. The v4.0.0 release notes list what shipped. We announced the 1 September date in July.

What happens now

• Following latest or stable? Your next install or upgrade uses v4. Check the upgrade guide first if you haven't already.
• Pinned to a version? Nothing changes until you update the pin.
• Need more time? Stay on v3 by switching to the oldstable channel or setting the agent version to 3. v3 continues to receive critical security and reliability fixes, and we'll announce an end-of-support date with plenty of notice.

Hosted agents

We've started moving hosted agent organizations to v4 and will continue over the coming days. There's nothing for you to configure, and your agent version will update automatically when your organization moves.

Hosted agents run the same agent, so the upgrade guide applies to your pipelines too. Most setups need no changes, but it's worth a read if your pipelines use plugins or hooks.

If you experience any issues, contact support@buildkite.com or your account team.

You can now connect to running Linux hosted jobs over SSH from your terminal using the Buildkite CLI. This extends the existing bk job ssh command for macOS hosted jobs to Linux hosted agents.

Install Buildkite CLI version 3.55.1 or later, then run:

bk job ssh <job-uuid>

The command opens an interactive shell and forwards terminal size and resize events. Before connecting, configure the Buildkite CLI with your organization and an API access token with the write_builds scope, make sure your organization's Hosted Agents Remote Access (SSH and VNC) setting is active, and confirm that you have permission to manage hosted agents for the job.

SSH access from the Buildkite CLI is rolling out for running Linux and macOS hosted jobs. Self-hosted jobs aren't supported. See the terminal access documentation for details. If the command isn't available for your organization yet, contact support@buildkite.com.

Stack-managed ephemeral agents can now start with a credential for one job. The controller keeps its cluster agent token and issues a short-lived job acquisition token (JAT) after reserving work. The workload uses that JAT to register an agent and acquire only the named job.

A JAT expires fifteen minutes after issuance by default. The Stacks API accepts a lifetime of up to one hour, but the token expires sooner if the job reservation does. When the agent registers, Buildkite also checks that the issuing agent token is still active and applies its expiration and IP restrictions.

Agent Stack for Kubernetes

The Agent Stack for Kubernetes uses JATs by default. The controller requests one immediately before scheduling each reserved job Pod and supplies it only to the agent container. If issuance fails, the job remains unscheduled rather than receiving the cluster agent token.

Custom stacks

Custom stack implementations can use the same flow: reserve a job, wait for execution capacity, then issue a JAT through the Stacks API. Start the workload with the JAT as BUILDKITE_AGENT_TOKEN and the reserved job UUID as BUILDKITE_AGENT_ACQUIRE_JOB.

See the job acquisition token guide for the complete flow, retry guidance, and credential-handling recommendations.

Agent names containing %n now receive a random six-character alphanumeric suffix instead of the next available number. For example, cool-agent-%n, which previously produced a name such as cool-agent-123, now produces a name such as cool-agent-aB3dE6.

We deprecated %n in 2022 because allocating sequential agent names becomes increasingly expensive as organizations scale. Removing the sequential allocation improves the speed and reliability of agent registration, particularly when many agents connect at once.

Agents configured with %n will continue to connect and accept work. However, if you have scripts, dashboards, or other automation that expects agent names to end in a number, update them to accept a six-character alphanumeric suffix.

We still recommend replacing %n in your agent configuration. Depending on your setup, use %hostname, %hostname-%spawn, or %random. See the agent name configuration documentation for details.

Questions or need a hand? Reach out to support@buildkite.com or your account team.

Block and input steps that need your attention now appear in their own Waiting for input group when grouped by state on the build page. This separates them from steps waiting on dependencies, which remain under Waiting, so it's easier to spot where a build needs action.

You can also now filter by Waiting for input in any build page view.