We have rolled out a new config validator that produces clearer, more actionable error messages. It already runs for most pipelines and surfaces remaining issues as pipeline warnings (also included in Slack and email notifications for pipeline completion).

We have rolled out a new config validator that produces clearer, more actionable error messages. It already runs for most pipelines and surfaces remaining issues as pipeline warnings (also included in Slack and email notifications for pipeline completion).

On Dec 14, 2026, warnings will become hard failures and block pipelines: configs that still trigger them will fail validation and will not start pipelines until fixed.

Please review recent pipelines for config validation warnings and fix them before that date. Agents and local CLI command ‘circleci config validate --next' can help apply the fixes.

What to do now

1. Open a recent pipeline in the CircleCI UI and check for config validation warnings.
2. Fix the underlying .circleci/config.yml (or orb) issue using the guidance below.
3. Re-run the pipeline and confirm the warning is gone.

Common cases to fix

These are the most common remaining classes of issues we see in production (ranked by breadth × volume). Exact wording may vary slightly by location in the config.

1. Incorrectly formed step

A step map is indented incorrectly — for example when: on_fail / when: on_success sitting as a sibling of a step, or name / command not nested under run:.

Fix: Nest keys under the step. Use a proper conditional step wrapper for when:.

1. Empty requires: — message like requires has no value

A job lists requires: with no jobs (including null or a fully commented-out list).

Fix: Remove requires:, or list the job names it should wait for.

1. Invalid enum default — Invalid enum default value

A parameter default: is not one of the values in enum: (including default: “” when empty string is not listed).

Fix: Set the default to an allowed enum value, or add the value to enum:.

1. Templated job type: — Job … type … is not recognised

Using *type: « pipeline.parameters.… » *(or similar) instead of a concrete job type.

Fix: Use a literal type (approval, build, …), or gate the job/workflow with when: instead of templating type:.

1. Undeclared job or command argument — does not take an argument named …

Passing a key the job/command does not declare (for example upstream:), or an orb-prefixed argument key.

Fix: Remove the unknown key, or declare it under parameters:.

1. Invalid or empty run step — A run step must specify a command

A step name that is not a real command, or a run step missing command:.

Fix: Correct the step/command name, or add command:.

1. Both when: and unless: on a workflow — Invalid workflow condition

A workflow sets both keys (a valueless unless: still counts).

Fix: Keep only one of when: or unless:.

1. Parameter type mismatch — parameter X must be of type Y

An argument does not match the declared type (integer, enum, boolean, string). Matrix parameters that share a name with a typed argument are a common trap.

Fix: Pass a value of the declared type; rename colliding matrix parameters if needed.

1. Empty list-shaped field — Expected a list value

A key that must be a list is present but empty (for example bare docker:).

Fix: Provide a list value, or remove the key.

10.Invalid command name — Invalid command name, must match ^[a-z][a-z0-9_-]*$

Command names with characters outside the allowed pattern (for example a /).

Fix: Rename the command (e.g. ace/validate → ace-validate).

Other less common warnings you may also see include empty cache/workspace paths:, non-positive or non-integer parallelism, and unsupported checkout method values (must be blobless, shallow, or full).

We’ve updated the commit statuses CircleCI posts to your VCS to make it faster to see which run failed and why, for both people and AI agents.

We’ve updated the commit statuses CircleCI posts to your VCS to make it faster to see which run failed and why, for both people and AI agents.

More descriptive status URLs

Status links previously used the format https://circleci.com/{project-slug}/{build-number}. They now include the workflow and job IDs:

• Build jobs: https://circleci.com/workflow/:workflow-id/job/:job-id
• Non-build jobs: https://circleci.com/workflow/:workflow-id

Failure details you can act on

When a job fails, the commit status description now points to the CircleCI CLI:

This replaces the generic “Your tests failed on CircleCI” message. It gives you, and any AI agents working on your pipelines, the context needed to diagnose and fix failing CI.

What you need to do

Nothing. If you have tooling that parses the old status URL format, update it to handle the new one.

We’ll continue to make improvements here. Have feedback or a request? Let us know here.

The Xcode 27.3 Beta 1 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

Following our Xcode image retention policy, Xcode 16.2.0 and 26.2.0 will be removed on December 7th, 2026.

Following our Xcode image retention policy, Xcode 16.2.0 and 26.2.0 will be removed on December 7th, 2026.

Why we’re announcing this again: Under our policy, deprecated Xcode images are retained for 30 days after announcement and then removed. Some of these images were not fully removed on their original schedule. This was unintentional and doesn’t reflect our policy. We’re correcting it, and because some teams may have continued running on these images in the meantime, we’re giving a full 30 days’ notice, including brownouts, before the removal is enforced. We apologize for the confusion.

What you need to do: Update the xcode: version in your config to a currently supported image before the first brownout. If your jobs run on one of these images, you’ll also see a deprecation warning on them. Apple has required Xcode 26 or later for App Store uploads since April 28, 2026, so we recommend moving to a current Xcode 26 release or later. See supported Xcode versions.

We will be performing 24 hour brownouts from 00:00:01 to 23:59:59 UTC during which these images will be unavailable. The brownout and removal schedule can be found below.

You can opt out of brownouts and continue using these images until they are removed on December 7th, 2026, by following our opt-out instructions.

Need help with your migration? If you have questions about moving to a supported Xcode version, contact CircleCI Support. Scale customers can also reach out to their Technical Success Manager.

Functions are versioned and tested programs that set up what your jobs need, from installing Node to configuring AWS credentials. You and your coding agent can find and configure them from the CircleCI CLI or MCP server.

Functions are versioned and tested programs that set up what your jobs need, from installing Node to configuring AWS credentials. You and your coding agent can find and configure them from the CircleCI CLI or MCP server.

With functions you can:

• Pin each function to a version like a normal package, and upgrade to the latest versions with circleci function update
• Catch version and input mistakes before your pipeline runs, with errors that tell you what’s wrong
• Get dependency caching built in, with no separate save and restore steps

Getting started

• With your coding agent: Ask your agent to set up CircleCI with functions. It can use the CircleCI CLI or connect through the CircleCI MCP server to find the right function, configure it, and validate your config before you push.
• With the CLI: Install the CircleCI CLI (v1.3.0 or later), then run circleci function list to browse the catalog and circleci function add setup-node to add one to your config.
• In your config: Declare the function in a functions: block at the top of your config, then call it by name in any job:

version: 2.1

functions:
  setup-node: github.com/circleci-functions/[email protected]

jobs:
  test:
    docker:
      - image: cimg/base:stable
    steps:
      - checkout
      - setup-node:
          with:
            node-version: "22"
      - run: npm ci && npm test

Functions are free on every plan, and your orbs remain fully supported. Learn more in the functions docs or browse the functions catalog.

This is a beta feature, so we’d love your feedback on what’s useful, what’s missing, and how we can make it better. Share your thoughts here.

Before Upgrading

See the CircleCI server 4.10 release notes and upgrade guide for this release.

Before Upgrading

See the CircleCI server 4.10 release notes and upgrade guide for this release.

If you mirror images to a private registry or run an air-gapped install, copy the new Kong and datastore images before you upgrade. See Configuration Changes below.

NOTE: Vault is being deprecated and will no longer be supported in server 5.0. Refer to our script for steps to migrate to Tink.

What’s New in Release 4.10.2

Updates

• Updated all CircleCI services to stop trusting certificates from the compromised eMudhra intermediate CAs, so these services reject forged certificates that chain to them. The Go services moved to Go 1.26.10. The Clojure service images were rebuilt to no longer have the compromised root certificates. No dependency changes were required in the clojure or JVM runtimes.

Bug Fixes

• Fixed HTTP 500 errors on the project pipelines list when an outbound proxy is enabled. The chart now exempts the in-cluster headless service hostnames from the Java proxy settings, so internal gRPC calls no longer go to the corporate proxy.
• Fixed the “Details” links on approval job statuses in GitHub, which returned 404. The links now open the workflow page again.
• Fixed orb import for site administrators, which failed with an authorization error. A failed downstream lookup during a permission check no longer stops the whole check.
• Fixed context permission checks on Server. Users can edit context environment variables and run jobs that use a context without an organization check that does not apply to Server.
• Fixed the project settings overview page, which showed a Not Found error. The page no longer calls an extra organizations endpoint to decide if the user is an admin.
• Fixed the web-ui on Server installs sending experiment and onboarding analytics requests to an endpoint that Server does not deploy, or to CircleCI cloud on an install without a configured hostname. These requests failed silently, so no data reached either service and no data was ever shared with CircleCI. They only added errors to the browser console. Server installs no longer make these requests.

CVE Fixes

• CVE-2026-33818, CVE-2026-39821, CVE-2026-46600, CVE-2026-56853, CVE-2026-56857, CVE-2026-56858, CVE-2026-56859, CVE-2026-56860, CVE-2026-56862, CVE-2026-56866, CVE-2026-78659, CVE-2026-78660, CVE-2026-78663, CVE-2026-78667, CVE-2026-78669, CVE-2026-94439, CVE-2026-94440, CVE-2026-94448, CVE-2026-97030, CVE-2026-97031, CVE-2026-97032, CVE-2026-111943 in the Go standard library was addressed in init-known-hosts, oidc-service, permissions-service, runner-admin, server-license services.
• CVE-2026-78659, CVE-2026-78660, CVE-2026-78663, CVE-2026-78669, CVE-2026-97032 in golang.org/x/net was addressed in api-gateway, execution-gateway, machine-provisioner, oidc-tasks-service, output, step services.
• CVE-2026-46595, CVE-2026-56854, CVE-2026-56855, CVE-2026-78662 in golang.org/x/crypto was addressed in authentication-svc, ciam-gateway, init-known-hosts, notifications, oidc-service, oidc-tasks-service, policy-service, public-api-service, runner-admin, step services.
• CVE-2026-56864, CVE-2026-56865 in golang.org/x/mod was addressed in ciam-gateway, contexts-service, distributor, docker-provisioner, execution-gateway, notifications, oidc-service, oidc-tasks-service, output, permissions-service, policy-service, runner-admin, step services.
• CVE-2026-46603 in golang.org/x/image was addressed in public-api-service service.
• CVE-2026-84304, CVE-2026-84445 in gRPC-Go (google.golang.org/grpc) was addressed in authentication-svc, ciam-gateway, contexts-service, distributor, execution-gateway, machine-provisioner, oidc-service, output, policy-service, public-api-service, runner-admin, step services.
• CVE-2026-41178 in OpenTelemetry Go (go.opentelemetry.io/otel) was addressed in authentication-svc, distributor, oidc-service, permissions-service services.
• CVE-2026-81870 in the OpenTelemetry Go OTLP trace exporters (otlptracegrpc, otlptracehttp) was addressed in authentication-svc, ciam-gateway, contexts-service, distributor, machine-provisioner, notifications, oidc-service, oidc-tasks-service, output, permissions-service, policy-service, public-api-service, runner-admin, step services.
• CVE-2026-114437 in go-chi (github.com/go-chi/chi/v5) was addressed in authentication-svc, ciam-gateway services.
• CVE-2026-73500 in the etcd Go client (go.etcd.io/etcd/client/pkg/v3) was addressed in authentication-svc service.
• CVE-2025-30153, CVE-2026-100347, CVE-2026-100348, CVE-2026-100349, CVE-2026-100351, CVE-2026-100352, CVE-2026-100353, CVE-2026-100354 in kin-openapi (github.com/getkin/kin-openapi) was addressed in public-api-service service.
• CVE-2026-10722 in ebpf-go (github.com/cilium/ebpf) was addressed in docker-provisioner service.
• CVE-2026-79921 in the RabbitMQ Go client (github.com/rabbitmq/amqp091-go) was addressed in execution-gateway service.
• CVE-2026-75595 in Netty (io.netty:netty-handler) was addressed in builds-service, circle-www-api, insights-service services.
• CVE-2026-54399 in Apache HttpComponents (httpcore5) was addressed in domain-service service.
• CVE-2026-67213 in nanoid was addressed in web-ui, web-ui-server-admin services.
• CVE-2026-84375 in js-yaml was addressed in web-ui service.
• CVE-2026-73088, CVE-2026-73089 in browserslist was addressed in web-ui service.
• CVE-2026-69153 in postcss was addressed in web-ui service.
• CVE-2026-71437 in mermaid was addressed in web-ui service.
• CVE-2026-63670, CVE-2026-84371 in sanitize-html was addressed in web-ui service.
• CVE-2026-8769 in @ai-sdk/provider-utils was addressed in web-ui service.
• CVE-2026-111943 in the system CA trust store (the emSign ECC Root CA - G3 and AAA Certificate Services roots behind the compromised eMudhra intermediates) was addressed in kong, server-redis services.
• CVE-2026-111497 (Node2Shell) in the Brotli library (libbrotli1) was addressed in kong, server-mongodb, server-rabbitmq services.

Configuration Changes

• Kong now runs a CircleCI-maintained Kong image from the CircleCI registry instead of the upstream kong:3.4.2 image from Docker Hub. We made this change so that we could timely patch the Kong image to address the compromised eMudhra root certificates (CVE-2026-111943) and Node2Shell vulnerability (CVE-2026-111497). CircleCI Hosted Kong image removes libbrotli1, git and libcurl, and it removes both distrusted eMudhra certificate roots. The Kong version stays at 3.4.2. The kong.image.repository and kong.image.tag values are removed. The chart ignores them and builds the Kong image path from global.container.registry and global.container.org, like other CircleCI images.
  • Action: if you mirror images for an air-gapped or private-registry install, mirror the kong image too: cciserver.azurecr.io/kong:3.4.5968-e68a9d5 with the default registry settings. Then remove any kong.image overrides.
• Changed the default mongodb.image.tag, rabbitmq.image.tag and redis.image.tag values to rebuilt internal MongoDB, RabbitMQ and Redis images: MongoDB from 7.0.15-debian-12-r2 to 7.0.5967-e68a9d5, RabbitMQ from 3.12.4066-fcf0542 to 3.12.5969-e68a9d5, and Redis from 6.2.2471-c0995cc to 6.2.5966-e68a9d5. The new images remove the distrusted eMudhra roots, and the major and minor versions do not change, so no migration is needed.
  • Action: if you override these tags, set mongodb.image.tag to 7.0.5967-e68a9d5, rabbitmq.image.tag to 3.12.5969-e68a9d5 and redis.image.tag to 6.2.5966-e68a9d5, or your datastores keep the old images.
• Added the optional contexts_service.javaToolOptions value. When you set it, the chart passes the value to contexts-service as JAVA_TOOL_OPTIONS. You no longer need to patch the Deployment after each upgrade to add JVM flags. The default is empty, so existing installs do not change.

Component Updates

• api-gateway
• api-service
• approval-job-provider-migrator
• authentication-svc
• authentication-svc-migrator
• branch-service
• branch-service-migrator
• builds-service
• builds-service-migrator
• ciam
• ciam-gateway
• circle-www-api
• contexts-service
• contexts-service-migrator
• cron-service
• cron-service-migrator
• distributor
• distributor-migrator
• docker-provisioner
• domain-service
• domain-service-migrator
• execution-gateway
• init-known-hosts
• insights-service
• insights-service-migrator
• lock-job-provider
• machine-provisioner
• machine-provisioner-migrator
• no-op-job-provider
• notifications
• oidc-service
• oidc-tasks-service
• oidc-tasks-service-migrator
• orb-service
• orb-service-analytics-migrator
• orb-service-migrator
• output
• permissions-service
• permissions-service-migrator
• picard
• policy-service
• public-api-service
• runner-admin
• runner-admin-migrator
• server-license
• server-mongodb
• server-postgres
• server-rabbitmq
• server-redis
• step
• web-ui
• web-ui-server-admin
• webhook-service
• webhook-service-migrator
• workflows-conductor
• workflows-conductor-migrator

Service changes

New components

• kong: the CircleCI-built Kong image (circleci/kong:3.4.5968-e68a9d5), new in images.yaml in this release. It replaces the upstream kong:3.4.2 image from Docker Hub. See Configuration Changes Section.

Deprecated components

None.

Before Upgrading

See the CircleCI server 4.9 release notes and upgrade guide for this release.

Before Upgrading

See the CircleCI server 4.9 release notes and upgrade guide for this release.

If you mirror images to a private registry or run an air-gapped install, copy the new Kong and datastore images before you upgrade. See Configuration Changes below.

NOTE: Vault is being deprecated and will no longer be supported in server 5.0. Refer to our script for steps to migrate to Tink.

What’s New in Release 4.9.7

Updates

• Updated all CircleCI services to stop trusting certificates from the compromised eMudhra intermediate CAs, so these services reject forged certificates that chain to them. The Go services moved to Go 1.26.10. The Clojure service images were rebuilt to no longer have the compromised root certificates. No dependency changes were required in the clojure or JVM runtimes.

Bug Fixes

• Fixed a crash loop on installs that keep tracing disabled (the default). Kubernetes service links injected a non-numeric OTEL_COLLECTOR_PORT value, which some services could not parse. The chart now always sets a numeric port, so these pods start without a workaround.
• Fixed the Insights CronJobs, which ran as the wrong user and failed with “Permission denied”. The hourly and daily Insights refresh jobs now complete.
• Fixed HTTP 500 errors on the project pipelines list when an outbound proxy is enabled. The chart now exempts the in-cluster headless service hostnames from the Java proxy settings, so internal gRPC calls no longer go to the corporate proxy.
• Fixed the “Details” links on approval job statuses in GitHub, which returned 404. The links now open the workflow page again.
• Fixed the web-ui on Server installs sending experiment and onboarding analytics requests to CircleCI cloud and to an endpoint that Server does not deploy. These requests failed silently, so no data reached either service. They only added errors to the browser console. Server installs no longer make these requests.

CVE Fixes

• CVE-2026-33818, CVE-2026-39821, CVE-2026-39822, CVE-2026-42505, CVE-2026-56853, CVE-2026-56858, CVE-2026-56859, CVE-2026-56860, CVE-2026-56862 in the Go standard library was addressed in init-known-hosts, server-license services.
• CVE-2026-46600, CVE-2026-78659, CVE-2026-78660, CVE-2026-78661, CVE-2026-78663, CVE-2026-78669, CVE-2026-97032, CVE-2026-97045 in golang.org/x/net was addressed in docker-provisioner, execution-gateway, machine-provisioner, no-op-job-provider, output, picard, step services.
• CVE-2026-56855, CVE-2026-78662 in golang.org/x/crypto was addressed in authentication-svc, distributor, machine-provisioner, no-op-job-provider, oidc-tasks-service, output, public-api-service, runner-admin, step services.
• CVE-2026-56864, CVE-2026-56865 in golang.org/x/mod was addressed in authentication-svc, ciam-gateway, distributor, lock-job-provider, machine-provisioner, no-op-job-provider, oidc-service, oidc-tasks-service, output, permissions-service, policy-service, runner-admin, step services.
• CVE-2026-46603 in golang.org/x/image was addressed in public-api-service service.
• CVE-2026-84304, CVE-2026-84445 in gRPC-Go (google.golang.org/grpc) was addressed in authentication-svc, ciam-gateway, distributor, execution-gateway, lock-job-provider, no-op-job-provider, oidc-service, permissions-service, policy-service, public-api-service, step services.
• CVE-2026-41178 in OpenTelemetry Go (go.opentelemetry.io/otel) was addressed in distributor, execution-gateway, oidc-service, permissions-service services.
• CVE-2026-81870 in the OpenTelemetry Go OTLP trace exporters (otlptracegrpc, otlptracehttp) was addressed in authentication-svc, ciam-gateway, distributor, lock-job-provider, machine-provisioner, no-op-job-provider, oidc-service, output, permissions-service, policy-service, public-api-service, runner-admin, step services.
• CVE-2026-114437 in go-chi (github.com/go-chi/chi/v5) was addressed in authentication-svc, ciam-gateway services.
• CVE-2026-73500 in the etcd Go client (go.etcd.io/etcd/client/pkg/v3) was addressed in authentication-svc service.
• CVE-2026-100347, CVE-2026-100348, CVE-2026-100349, CVE-2026-100351, CVE-2026-100352, CVE-2026-100353, CVE-2026-100354 in kin-openapi (github.com/getkin/kin-openapi) was addressed in public-api-service service.
• CVE-2026-41579 in runc (github.com/opencontainers/runc) was addressed in docker-provisioner service.
• CVE-2026-5160 in goldmark (github.com/yuin/goldmark) was addressed in docker-provisioner service.
• CVE-2026-10722 in ebpf-go (github.com/cilium/ebpf) was addressed in docker-provisioner service.
• CVE-2026-79921 in the RabbitMQ Go client (github.com/rabbitmq/amqp091-go) was addressed in execution-gateway service.
• CVE-2026-75595, CVE-2026-75596 in Netty (io.netty:netty-handler) was addressed in api-service service.
• CVE-2026-54399 in Apache HttpComponents (httpcore5) was addressed in domain-service service.
• CVE-2026-64641, CVE-2026-64643, CVE-2026-64644, CVE-2026-64645, CVE-2026-64646, CVE-2026-64647, CVE-2026-64648, CVE-2026-64649, CVE-2026-75604, CVE-2026-96889 in Next.js (next) was addressed in web-ui, web-ui-server-admin services.
• CVE-2026-13676, CVE-2026-16221, CVE-2026-18446, CVE-2026-75899, CVE-2026-75975, CVE-2026-76172 in fast-uri was addressed in web-ui, web-ui-server-admin services.
• CVE-2026-59869, CVE-2026-84375 in js-yaml was addressed in web-ui, web-ui-server-admin services.
• CVE-2026-67213, CVE-2026-67214, CVE-2026-73086 in nanoid was addressed in web-ui, web-ui-server-admin services.
• CVE-2026-83605, CVE-2026-83607, CVE-2026-83608, CVE-2026-83610, CVE-2026-83611, CVE-2026-83613, CVE-2026-83614 in @xmldom/xmldom was addressed in web-ui, web-ui-server-admin services.
• CVE-2026-111755, CVE-2026-111756 in follow-redirects was addressed in web-ui-server-admin service.
• CVE-2026-111943 in the system CA trust store (the emSign ECC Root CA - G3 and AAA Certificate Services roots behind the compromised eMudhra intermediates) was addressed in kong, server-redis services.
• CVE-2026-111497 (Node2Shell) in the Brotli library (libbrotli1) was addressed in kong, server-rabbitmq services.

Configuration Changes

• Kong now runs a CircleCI-maintained Kong image from the CircleCI registry instead of the upstream kong:3.4.2 image from Docker Hub. We made this change so that we could timely patch the Kong image to address the compromised eMudhra root certificates (CVE-2026-111943) and Node2Shell vulnerability (CVE-2026-111497). CircleCI Hosted Kong image removes libbrotli1, git and libcurl, and it removes both distrusted eMudhra certificate roots. The Kong version stays at 3.4.2. The kong.image.repository and kong.image.tag values are removed. The chart ignores them and builds the Kong image path from global.container.registry and global.container.org, like other CircleCI images.
  • Action: if you mirror images for an air-gapped or private-registry install, mirror the kong image too: cciserver.azurecr.io/kong:3.4.5976-281b064 with the default registry settings. Then remove any kong.image overrides.
• Changed the default rabbitmq.image.tag and redis.image.tag values to rebuilt internal RabbitMQ and Redis images: RabbitMQ from 3.12.4071-a535ab2 to 3.12.5977-281b064, and Redis from 6.2.2471-c0995cc to 6.2.5979-281b064. The new images remove the distrusted eMudhra roots, and the major and minor versions do not change, so no migration is needed.
  • Action: if you override these tags, set rabbitmq.image.tag to 3.12.5977-281b064 and redis.image.tag to 6.2.5979-281b064, or your datastores keep the old images.
• Added the optional contexts_service.javaToolOptions value. When you set it, the chart passes the value to contexts-service as JAVA_TOOL_OPTIONS. You no longer need to patch the Deployment after each upgrade to add JVM flags. The default is empty, so existing installs do not change.

Component Updates

• api-gateway
• api-service
• approval-job-provider-migrator
• audit-log-service
• authentication-svc
• authentication-svc-migrator
• branch-service
• branch-service-migrator
• builds-service
• builds-service-migrator
• ciam
• ciam-gateway
• circle-www-api
• contexts-service
• contexts-service-migrator
• cron-service
• cron-service-migrator
• distributor
• distributor-migrator
• docker-provisioner
• domain-service
• domain-service-migrator
• execution-gateway
• init-known-hosts
• insights-service
• insights-service-migrator
• lock-job-provider
• machine-provisioner
• machine-provisioner-migrator
• no-op-job-provider
• oidc-service
• oidc-tasks-service
• oidc-tasks-service-migrator
• orb-service
• orb-service-analytics-migrator
• orb-service-migrator
• output
• permissions-service
• permissions-service-migrator
• picard
• policy-service
• public-api-service
• runner-admin
• runner-admin-migrator
• server-license
• server-postgres
• server-rabbitmq
• server-redis
• step
• web-ui
• web-ui-server-admin
• webhook-service
• webhook-service-migrator
• workflows-conductor
• workflows-conductor-migrator

Service changes

New components

• kong: the CircleCI-built Kong image (circleci/kong:3.4.5976-281b064), new in images.yaml in this release. It replaces the upstream kong:3.4.2 image from Docker Hub. See the Configuration Changes Section.

Deprecated components

None.

When you re-run a workflow from a GitHub check, CircleCI now attributes the re-run to the CircleCI user who clicked Re-run, not the user who started the original workflow. This matches how re-running from the CircleCI web app already works.

When you re-run a workflow from a GitHub check, CircleCI now attributes the re-run to the CircleCI user who clicked Re-run, not the user who started the original workflow. This matches how re-running from the CircleCI web app already works.

• Contexts, security groups and permissions are checked against the user who requested the re-run.
• Their identity is used for the new workflow, including CIRCLE_USERNAME and the workflow’s “started by”.
• If CircleCI can’t match your GitHub user to a CircleCI user, or you don’t have permission to run the workflow, the re-run won’t start. Re-run from the CircleCI web app instead.

GitHub check runs for CircleCI workflows now clearly indicate when a workflow is paused at a manual approval job, along with a link to the workflow so you can act on it.

GitHub check runs for CircleCI workflows now clearly indicate when a workflow is paused at a manual approval job, along with a link to the workflow so you can act on it.

• Clearer summary: the headline shows workflow state, job counts, and elapsed time, followed by a one-line explanation of the current status.
• Table layout: jobs are listed in a Status / Job / Duration table, with failed and on-hold jobs shown first and the reason displayed inline.
• Condensed success view: workflows where every job passes collapse to a single summary line.
• No change to check behavior: the check run remains in_progress while a workflow is on hold, so branch protection and required checks are unaffected.

The Xcode 27.2 RC 1 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

CLI v1.11.0 adds circleci notification slack commands, so you can script Slack setup across projects instead of clicking through each one.

CLI v1.11.0 adds circleci notification slack commands, so you can script Slack setup across projects instead of clicking through each one.

• circleci notification slack set --channel #ci-alerts connects a project to a channel. Use a channel name or ID (private channels need the ID).
• circleci notification slack set --disable / --enable pauses or resumes notifications and keeps the channel configuration.
• circleci notification slack get shows the channel and notification settings. Add --json for scripting.
• circleci notification slack delete removes the channel.

Your org needs the CircleCI Slack app installed. More details about each command can be found in the CircleCI CLI reference.

We consolidated the project creation flow into a single page, so setting up a new project takes fewer steps and less time. If your repository does not have an existing config file, we now provide an AI prompt to generate one with your preferred agent.

This flow is only available for orgs using CircleCI’s GitHub App, GitLab Cloud, GitLab Self-Managed, or Cursor Origin (in beta) integration.

Security

Rebuilt Machine Runner Orchestrator with a patched Go release that stops trusting the compromised eMudhra and Comodo AAA root certificate authorities, in response to the October 2026 eMudhra intermediate CA key compromise. We recommend that all users upgrade. This addresses CVE-2026-111943.

See our Discuss Post for more details.

CircleCI now issues a third version of its OIDC (OpenID Connect) token, alongside the V1 and V2 tokens. In V3 the subject (sub) claim covers where the code was checked out from and where the pipeline config came from.

CircleCI now issues a third version of its OIDC (OpenID Connect) token, alongside the V1 and V2 tokens. In V3 the subject (sub) claim covers where the code was checked out from and where the pipeline config came from.

What’s new

• Jobs now get the V3 token in $CIRCLE_OIDC_TOKEN_V3, alongside $CIRCLE_OIDC_TOKEN and $CIRCLE_OIDC_TOKEN_V2.
• The V3 sub claim has a new format, shown below.
  • It looks like org:<org-id>:project:<project-id>:user:<user-id>:checkout-source:<checkout-source>:checkout-ref:<checkout-ref>:config-source:<config-source>:config-ref:<config-ref>
  • Segments are separated by : instead of /. Branch names can contain /, so a / separator can be spoofed in wildcard matches.
  • Any : inside a value is escaped as %3A.
• V3 adds four claims: oidc.circleci.com/checkout-source, checkout-ref, config-source and config-ref.
• V3 renames these claims:
  • vcs-origin → checkout-source
  • vcs-ref → checkout-ref
  • pipeline-definition-id → pipeline-id
  • The old pipeline-id → run-id
• The V2 token now also carries checkout-source, checkout-ref, config-source and config-ref. Its existing claims and sub format are unchanged.
• circleci run oidc get now takes --v1, --v2 or --v3 to request a specific token version.
  • If that version can’t be minted, the command fails instead of returning a different version.
  • With no flag it still returns a V2 token, falling back to V1.
  • Example: circleci run oidc get --v3 --aud "my-audience"
• circleci run oidc get also has a new --aud flag to set a custom audience, for any token version. --claims '{"aud": "..."}' is deprecated but still works. You can’t pass both.

What to know

• Existing policies keep working, because V1 and V2 tokens are unchanged.
• If a job’s checkout values are missing, it gets no V3 token. $CIRCLE_OIDC_TOKEN_V3 won’t be set, and circleci run oidc get --v3 will fail.
• pipeline-id means something different in V3: it’s the pipeline definition, not the pipeline run. Update any policy that uses it before switching.

See Using OpenID Connect tokens in jobs for the full claims table and policy examples.

Rebuilt Container Runner and Machine Runner with a patched Go release that stops trusting the compromised eMudhra and Comodo AAA root certificate authorities, in response to the October 2026 eMudhra intermediate CA key compromise. We recommend that all users upgrade. This addresses CVE-2026-111943.

See our Discuss Post for more details.

The Xcode 27.2 Beta 3 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

The Xcode 27.1 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

You can now assign a scope to Personal API Tokens, controlling exactly what access a token grants.

You can now assign a scope to Personal API Tokens, controlling exactly what access a token grants.

Previously, every Personal API Token was issued with full admin-level access, regardless of what the token was actually used for. Now, when creating a new token, you can choose one of three scopes - Read, Write or Admin.

This lets you issue narrowly-scoped tokens for CI integrations, scripts, or third-party tools that only need read or write access, reducing the blast radius if a token is ever leaked or compromised.

Existing tokens are unaffected and continue to operate with admin-level access. To start using scoped tokens, generate a new Personal API Token from your user settings and select the desired scope.

To learn more, see Managing API tokens.

Instead of always starting with full parallelism as set in the config, Dynamic Parallelism can scale the number of parallel nodes your test job needs depending on the number of tests that were selected by Smarter Testing’s Intelligent Test Selection.

Instead of always starting with full parallelism as set in the config, Dynamic Parallelism can scale the number of parallel nodes your test job needs depending on the number of tests that were selected by Smarter Testing’s Intelligent Test Selection.

Why we built this:

Parallelism used to be fixed in config, so a job set to 100 nodes started all 100 even when test selection picked only a handful of tests. Most of those nodes had little or nothing to run, so you ended up spending credits on them without any speedup.

How it works:

An upstream job calculates how many tests will run and passes that number to the downstream test job, which starts only the nodes it needs. By default, Smarter Testing picks the fewest nodes that will still finish in about the same time as running the full suite. If you’d rather optimize for developer time, set a target duration and Smarter Testing sizes parallelism to aim for it.

Getting started:

experimental:
  dynamic-parallelism:
    test:
      key: ci-tests-parallelism-key
      min: 1
      max: 20
      target: 1m

• key: links the downstream job to the parallelism value calculated upstream.
• min / max: the lowest and highest number of nodes the job can run with.
• target (optional): the wall-clock time to aim for, such as 1m. This is useful if you keep your test suite at around a minute and don’t want to keep returning parallelism by hand.

See the Smarter Testing docs for full setup: here

We are adding two AWS compute regions, us-west-1 and us-west-2. They join us-east-2 as fallback regions. CircleCI uses a fallback region when capacity is not available in the primary region. This change improves availability.

We are adding two AWS compute regions, us-west-1 and us-west-2. They join us-east-2 as fallback regions. CircleCI uses a fallback region when capacity is not available in the primary region. This change improves availability.

What is affected

• Machine executor jobs and remote Docker can run in a fallback region.

Reduce cross-region ECR costs

If you’d like to reduce cross-region data transfer charges from AWS when jobs run in a fallback region, use prefer_same_region. With this option set, remote Docker first tries to pull the image from ECR in the region where the job runs. If the image is not there, it pulls from the region you specified.

To get the most from this option, publish your ECR images to these regions:

• us-east-2
• us-west-1
• us-west-2

For example, a job runs in us-west-2 and refers to an image in us-east-1. CircleCI first tries us-west-2. If the image is not there, it uses us-east-1.

For setup details, refer to Building Docker images: prefer same region pulls.

Smarter Testing is now generally available for all Cloud customers. Since beta, teams have used test impact analysis, dynamic test splitting, and automatic rerun of failed tests to run fewer tests, run them faster, and get signal sooner, while maintaining full confidence.

Smarter Testing is now generally available for all Cloud customers. Since beta, teams have used test impact analysis, dynamic test splitting, and automatic rerun of failed tests to run fewer tests, run them faster, and get signal sooner, while maintaining full confidence.

What’s included

Smarter Testing is a comprehensive set of testing capabilities. The foundational capabilities of test running, static test splitting, and rerun failed tests remain free. Intelligent test selection, dynamic test splitting, auto-rerun failed tests, and the test analytics dashboard go GA and will be billed by test atoms evaluated starting today. Learn more about test atoms here

• Intelligent test selection: Run only the tests affected by your code changes.
• Dynamic test splitting: Balance tests across parallel containers based on real timing data.
• Auto-rerun failed tests: Automatically rerun failed tests to separate flakes from real failures.
• Test analytics dashboard: Track test performance, flakiness, and trends over time.

Pricing

Every plan includes a free monthly allowance of test atoms evaluated:

• Free plan: 1,000 test atoms evaluated per month
• Performance plan: 10,000 test atoms evaluated per month
• Scale plan: 100,000 test atoms evaluated per month

Usage above your allowance is billed at 3,000 credits per 100,000 test atoms evaluated, rounded up.

Get Started

Read the Smarter Testing blog post to see how it works and what it can do for your jobs. To understand and configure Smarter Testing for your projects, see the docs.

Using an older CLI setup? Make sure you’ve applied the command, flag, and plugin changes from August.

New

• Run runner VMs on spot nodes to cut compute costs, without failing jobs when a node is reclaimed. Set runner.enableUnsafeRetries on a resource class, and a job that is still running when its VM shuts down is retried on another VM instead of failing. The job restarts from the beginning, so only enable it for jobs that are safe to run more than once. Off by default. Requires machine runner 3.1.13 or later.

Fixes

• A resource class can now override resourceClassDefaults with false, zero or empty values. Previously these were ignored and the class got the default instead. For example, a class can now set grantSudo: false or headroom: 0, or set a list to empty to clear a default. A class that leaves out scaleDownDelay also no longer has it forced to 0s.

Machine Runner:

Machine Runner:

• Run machine runners on spot or preemptible instances to cut compute costs, without failing jobs when an instance is reclaimed. With the new runner.enable_unsafe_retries option, a job that is still running when the runner receives SIGINT, SIGTERM or SIGHUP is retried on another runner instead of failing. The job restarts from the beginning, so only enable it for jobs that are safe to run more than once. Any other error still fails the job.
• SIGHUP now triggers a graceful shutdown rather than killing the runner.

Container Runner:

• SSH reruns are now generally available on container runner.
• The Helm chart (v101.2.1) now creates SSH TCPRoute resources with the gateway.networking.k8s.io/v1 API version, so standard channel Gateway API CRDs work and experimental CRDs are no longer needed. Gateway API v1.6 or later is now required for SSH reruns.

The Xcode 27.1 RC 1 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

Gen2 Arm resource classes for Docker and Linux VM are now available in Beta on CircleCI, delivering priority access to newer-generation Arm CPUs that are up to 94% faster than gen1 for your Linux workloads, at a lower credit cost.

Gen2 Arm resource classes for Docker and Linux VM are now available in Beta on CircleCI, delivering priority access to newer-generation Arm CPUs that are up to 94% faster than gen1 for your Linux workloads, at a lower credit cost.

Gen2 Docker (Arm) is available for all users in the following configurations:

Gen2 Linux VM (Arm) is available for all users in the following configurations:

See the Arm documentation, the Docker documentation, and the CircleCI price list for details.

Beta Release Notes:

• This feature is stable but still being refined based on customer feedback
• Preview pricing shown above may change at General Availability
• SLOs are measured but not guaranteed during Beta
• Self-service activation is available now through your config
• Remote Docker is not yet available for Gen2 Arm

The CircleCI plugin for JetBrains IDEs is now available on the JetBrains Marketplace. It brings your CircleCI runs, jobs and config into IntelliJ IDEA and the other JetBrains IDEs, so you can see what CI is doing and act on it without switching to the browser.

The CircleCI plugin for JetBrains IDEs is now available on the JetBrains Marketplace. It brings your CircleCI runs, jobs and config into IntelliJ IDEA and the other JetBrains IDEs, so you can see what CI is doing and act on it without switching to the browser.

Follow your runs

• A CircleCI tool window, next to Commit and Pull Requests, lists your project’s runs with their workflows and jobs underneath. Statuses update live while anything is running.
• You can filter by branch (current, default, all, or My runs across every project), by status, and by age. These filters work the same way as circleci run get.
• Rerun a workflow from the start or from failed jobs, cancel it, approve jobs on hold, or open any run, workflow or job in the web app.

Open a job like a file

• Each job opens in its own editor tab, and you can have as many open as you like. The tab lists the job’s steps and opens on the step that failed or the one that’s running. A running step’s output streams in, in colour.
• Tests: see failed tests first. You can filter by name, sort by any column, and read each test’s failure message.
• Artifacts: a file tree you can browse. Open artifacts right in the IDE or download them, including from private projects.
• Resource usage: charts of CPU and memory against your resource class’s limits, with a line for each parallel run, so you can see whether you’re paying for a resource class you don’t need.

Debug over SSH from the IDE

• Rerun a job with SSH and connect to it in the IDE’s terminal. The connection uses your existing SSH config, agent and keys, and you can open as many sessions as you need.

Write config with confidence

• A built-in language server checks .circleci/config.yml as you type, with completion and docs. It can also resolve private orbs.
• Validate your config before you commit, or try a change with a test run that doesn’t need a commit.

Manage secrets and contexts

• You can view and edit project environment variables and your org’s contexts from the tool window. Each context gets its own page, much like the web app’s. You can manage a context’s variables and its group, project and expression restrictions there, and expressions are completed and checked as you type.

Getting started

Install CircleCI from the JetBrains Marketplace. Then open the CircleCI tool window and choose Log In via CircleCI…, which signs you in through your browser, or log in with a personal API token. CircleCI server is supported too. The plugin needs IntelliJ IDEA or another commercial JetBrains IDE, version 2026.1 or newer. It doesn’t run in open-source builds or Android Studio.

For customers needing cleanup work to run no matter how a job ends, we now support teardown steps. Add a teardown list to any run step, and CircleCI runs those steps at the end of the job, including when the job fails, is canceled, or times out.

For customers needing cleanup work to run no matter how a job ends, we now support teardown steps. Add a teardown list to any run step, and CircleCI runs those steps at the end of the job, including when the job fails, is canceled, or times out.

Use teardown for saving caches, storing test results, and other cleanup that would otherwise be skipped when a job ends early. It also lets you place a save_cache near its matching restore_cache, rather than at the end of the job.

steps:
  - checkout
  - restore_cache:
      keys:
        - v1-build-{{ checksum "go.sum" }}
  - run:
      name: Build
      command: make build
      teardown:
        - save_cache:
            key: v1-build-{{ checksum "go.sum" }}
            paths:
              - ~/.cache/go-build

Supported steps: run, save_cache, persist_to_workspace, store_artifacts, and store_test_results. Teardown steps share a 10-minute total time limit per job.

See the teardown configuration reference for details.

Slack notifications for on-hold workflows are now actionable. When a workflow is paused at an approval job, the Slack notification includes Approve and Cancel buttons, so you can act on it without opening the CircleCI web app. The buttons appear in both project channel notifications and direct messages, and each action asks for confirmation before it runs.

Slack notifications for on-hold workflows are now actionable. When a workflow is paused at an approval job, the Slack notification includes Approve and Cancel buttons, so you can act on it without opening the CircleCI web app. The buttons appear in both project channel notifications and direct messages, and each action asks for confirmation before it runs.

What’s included

• Approve and Cancel buttons on on-hold workflow notifications, in shared channels and DMs
• A confirmation dialog before any action runs
• The same permissions as the CircleCI web app, so you can only approve or cancel workflows you’d be able to act on in the app
• In-Slack feedback: the message updates with the outcome, and you get a message if something goes wrong or you don’t have permission

To use it

1. Make sure your organization has the CircleCI Slack app installed (Org Settings → Slack Integration).
2. Enable Slack notifications for workflows awaiting approval for your project or DMs.
3. Link your Slack identity from User Settings → Notifications. If you haven’t, you’ll be prompted to when you select a button.

Learn more in the Slack integration guide. You can share feedback and feature enhancement requests here.

You can now get additional assistance and file support tickets directly from the CircleCI web app with the new in-app support chat. To use it, open the Help menu at the top right of the web app and enable the support chat toggle.

CircleCI is retiring 9 legacy v1 and v1.1 API endpoints used to trigger and rerun builds. They will be removed on February 1, 2027. This extends the date previously communicated by email (November 1, 2026). After that date, requests to these endpoints return HTTP 410 Gone. This change does not affect other v1 or v1.1 endpoints, and it does not affect API v2 or v3. This change applies to both CircleCI cloud and CircleCI server.

CircleCI is retiring 9 legacy v1 and v1.1 API endpoints used to trigger and rerun builds. They will be removed on February 1, 2027. This extends the date previously communicated by email (November 1, 2026). After that date, requests to these endpoints return HTTP 410 Gone. This change does not affect other v1 or v1.1 endpoints, and it does not affect API v2 or v3. This change applies to both CircleCI cloud and CircleCI server.

What’s changing

These endpoints were built for the CircleCI 1.0 build system and are no longer compatible with the current platform.

v1 endpoints:

• POST /api/v1/project/:username/:repo/
• POST /api/v1/project/:username/:repo/:build_num/retry
• POST /api/v1/project/:username/:repo/:build_num/ssh
• POST /api/v1/project/:username/:repo/tree/:branch

v1.1 endpoints:

• POST /api/v1.1/project/:vcs-type/:username/:repo/
• POST /api/v1.1/project/:vcs-type/:username/:repo/:build_num/retry
• POST /api/v1.1/project/:vcs-type/:username/:repo/:build_num/ssh
• POST /api/v1.1/project/:vcs-type/:username/:repo/build
• POST /api/v1.1/project/:vcs-type/:username/:repo/tree/:branch

What you should do

• To trigger a pipeline, use POST /api/v3/runs (API v3) or POST /api/v2/project/:provider/:organization/:project/pipeline/run (API v2 - Cloud) or POST /api/v2/project/:provider/:organization/:project/pipeline (API v2 - Server & Cloud).
• To rerun, use POST /api/v3/workflows/:id/rerun (API v3) or POST /api/v2/workflow/:workflow-id/rerun (API v2). Reruns are workflow-based, and you can choose which jobs to rerun. To rerun with SSH enabled, set enable_ssh (v2) or is_ssh_enabled (v3).
• CircleCI server customers should use the API v2 endpoints, since API v3 is available on cloud only.
• Find your calls. Check your CI scripts, internal tooling, and third-party integrations for requests to the endpoints above.
• Update project addressing. v1 uses :username/:repo. v2 uses :provider/:organization/:project, and v3 uses UUIDs.

Cloud customers: we recommend starting with v3. API v2 remains supported if v3 doesn’t cover what you need.

Timeline

• Now: These endpoints return Deprecation and Sunset headers.
• February 1, 2027: The endpoints are removed and return HTTP 410 Gone.

Need help?

If you have questions or need help migrating, contact CircleCI Support. See the API v3 developer’s guide and the API v2 reference.

API v3 is CircleCI’s current API version, and all new API development happens in v3. Every endpoint follows the same conventions, so you can predict how the API works without reading a spec for each one:

API v3 is CircleCI’s current API version, and all new API development happens in v3. Every endpoint follows the same conventions, so you can predict how the API works without reading a spec for each one:

• UUID resource IDs instead of project slugs
• Cursor-based pagination
• One error format with structured error objects
• Standard rate limit headers, so tools can back off automatically

What this means for v1 and v2

• Start with v3. It’s built for an improved developer experience and for the use cases developers need today, including AI agents.
• v2 remains supported. If v3 doesn’t cover what you need yet, use v2 with confidence.
• v1 is being replaced by v3. Some v1 endpoints already have v2 or v3 equivalents and will be deprecated first. We’ll announce deprecations of v1 APIs as we remove them or provide alternatives.
• If you use v1, review which endpoints you call. Not all v1 endpoints are affected at the same time.

The CircleCI CLI and MCP server already use API v3, so AI coding agents and scripts that go through them get it automatically.

Some endpoints are marked experimental in the reference and may change. Check each endpoint’s description before you depend on it.

To get started, follow the API v3 developer’s guide or browse the API v3 reference. API v3 is available on CircleCI cloud only. If you use CircleCI server, continue to use API v2.

Related announcements

• Deprecation of GraphQL Unstable API

Bitbucket Cloud is retiring SSH access via bitbucket.org on 12 November 2026 and moving it to ssh.bitbucket.org (Atlassian announcement). We are updating CircleCI’s build agent to use the new host so that Bitbucket Cloud checkouts continue to work after the cutover.

Bitbucket Cloud is retiring SSH access via bitbucket.org on 12 November 2026 and moving it to ssh.bitbucket.org (Atlassian announcement). We are updating CircleCI’s build agent to use the new host so that Bitbucket Cloud checkouts continue to work after the cutover.

What’s changing

When checking out code from a Bitbucket Cloud repository over SSH, the build agent will now connect to ssh.bitbucket.org instead of bitbucket.org. Who is affected

Customers who don’t use self-hosted runners don’t need to take any action.

If you use self-hosted runners with Bitbucket Cloud repositories and your network restricts outbound traffic by IP, you may need to update your firewall allowlist. The new host (ssh.bitbucket.org) can resolve to different IP addresses than bitbucket.org.

What to do

If you have IP-based firewall rules for your runners, ensure that outbound SSH (port 22) to ssh.bitbucket.orgis allowed. At the time of writing, ssh.bitbucket.org resolves to IPs within the 185.166.140.0/22 range. Atlassian publishes their current IP ranges here: Bitbucket Cloud IP addresses. If you are already allowing the full CIDR blocks listed on that page, no changes should be needed.

The Xcode 27.2 Beta 2 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

Following our Xcode image retention policy, Xcode 14.3.1, 26.3.0, 26.2.0, and 26.1.1 have been marked as deprecated and will be removed on October 30th, 2026.

Following our Xcode image retention policy, Xcode 14.3.1, 26.3.0, 26.2.0, and 26.1.1 have been marked as deprecated and will be removed on October 30th, 2026.

We will be performing 24 hour brownouts from 00:00:01 to 23:59:59 UTC during which these images will be unavailable. The brownout and deprecation schedule can be found below.

You can opt-out of brownouts and continue using these images until they are removed on October 30th, 2026, by following our opt-out instructions.

Native GitHub Actions YAML Workflow Support — Open Preview

Native GitHub Actions YAML Workflow Support — Open Preview

CircleCI now supports running GitHub Actions YAML-defined workflows directly on CircleCI compute.

This is an open preview release. Some GitHub Actions features are not yet supported, and Linux runners are currently the only supported execution environment.

What works

• Checkout, cache save and restore, matrix builds, and test splitting
• Linux runners
• Job dependencies with needs:
• Service containers
• Public 3rd party GitHub Actions
• Most standard build and test patterns

Before you run your first build

• Secrets do not transfer automatically. Move your GitHub Actions secrets to CircleCI project environment variables or contexts before triggering a run.

What’s not supported

See the compatibility table for a full list of unsupported features and known limitations.

Get started

For setup instructions, the full compatibility table, and recommendations for running your GitHub Actions YAML workflows on CircleCI, see the https://circleci.com/docs/guides/orchestrate/use-a-github-actions-workflow-file-as-your-pipeline-configuration/.

CircleCI will end support for Bitbucket Data Center (BBDC) as a VCS integration on October 1, 2026.

CircleCI will end support for Bitbucket Data Center (BBDC) as a VCS integration on October 1, 2026.

Reason for change: BBDC adoption has remained minimal, and Atlassian’s recent licensing changes indicate reduced long-term commitment to the Data Center product line.

Impact: Pipelines connected to a Bitbucket Data Center instance will stop functioning after October 1, 2026.

Recommended action: Migrate to a supported VCS — GitHub, GitLab, Bitbucket Cloud, or Cursor Origin — before October 1, 2026.

Timeline:

• October 1, 2026 — BBDC support ends

The Xcode 27.1 Beta 1 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

API Change: Pipeline Error Response Format Update

We’ve updated how pipeline errors are returned in the CircleCI API.

API Change: Pipeline Error Response Format Update

We’ve updated how pipeline errors are returned in the CircleCI API.

What’s changing

Previously, related lines from a single config error were returned as separate objects in the errors array:

"errors": [
  { "type": "config-deprecated-syntax", "message": "Error calling workflow: 'build-test-deploy'" },
  { "type": "config-deprecated-syntax", "message": "Error calling job: 'buggy-orb/exhibit-bug'" },
  { "type": "config-deprecated-syntax", "message": "Referred to a variable that does not exist" }
]

Going forward, all lines belonging to the same error are consolidated into a single object, with lines separated by a newline character (\n):

"errors": [
  { "type": "config-deprecated-syntax", "message": "Error calling workflow: 'build-test-deploy'\nError calling job: 'buggy-orb/exhibit-bug'\nReferred to a variable that does not exist" }
]

Why we’re making this change

This consolidation lays the groundwork for returning multiple distinct errors in a single response. Soon, if your config has more than one unrelated issue, you’ll see each as a separate object in the errors array — so you can identify and fix all problems at once, rather than triggering your pipeline multiple times.

What you need to do

If your code parses the errors array, verify it handles multi-line message values correctly. The number of objects in the array will now reflect the number of distinct errors, not the number of individual error lines.

Affected APIs

v2:

• GET /api/v2/pipeline
• GET /api/v2/pipeline/{pipeline-id}
• GET /api/v2/project/{project-slug}/pipeline
• GET /api/v2/project/{project-slug}/pipeline/mine
• GET /api/v2/project/{project-slug}/pipeline/{pipeline-number}

v3:

• GET /api/v3/runs
• GET /api/v3/runs/search
• GET /api/v3/runs/{id}

The Xcode 27.2 beta image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

New

Machine Runner Orchestrator (previously Runner Provisioner), which automatically scales self-hosted machine runner VMs to match CI demand, is now generally available (GA).

New

Machine Runner Orchestrator (previously Runner Provisioner), which automatically scales self-hosted machine runner VMs to match CI demand, is now generally available (GA).

Machine Runner Orchestrator adds:

• Multi-resource-class support: CPU, GPU, and ARM workloads can all autoscale from a single deployment, removing the single-resource-class limit from the preview release.
• Support for GKE, AKS, and EKS, in addition to any KubeVirt-based Kubernetes cluster.

Machine Runner Orchestrator is included with self-hosted runners on every CircleCI plan, at no additional cost.

Breaking

The product was fully renamed from runner-provisioner to machine-runner-orchestrator: Helm chart name, container image repository, and Packagecloud package repository all changed to reflect that. Existing deployments must be uninstalled and reinstalled under the new name.

helm list -n <k8s_namespace>
helm uninstall runner-provisioner -n <k8s_namespace>
helm repo add circleci_machine-runner-orchestrator https://packagecloud.io/circleci/machine-runner-orchestrator/helm
helm repo update
helm install machine-runner-orchestrator circleci_machine-runner-orchestrator/machine-runner-orchestrator \
  --namespace <k8s_namespace> \
  --version 1.0.0 \
  --values my-values.yaml

Keep in mind that Runners for the configured resource classes will be offline between uninstalling the old chart and installing the new one.

Security

This version patches two high-severity gRPC-Go denial-of-service vulnerabilities: heap memory exhaustion via HTTP/2 frame fragmentation (CVE-2026-84304) and a crash on requests missing :authority/Host headers (CVE-2026-84445).

The Xcode 27.0 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

CircleCI now hosts an MCP server at https://mcp.circleci.com/v1/mcp. Point your AI assistant at that URL, sign in with OAuth2, and it can read and act on your CI. There is nothing to install and nothing to keep up to date — every client hits the same endpoint, and new tools appear the moment we ship them.

CircleCI now hosts an MCP server at https://mcp.circleci.com/v1/mcp. Point your AI assistant at that URL, sign in with OAuth2, and it can read and act on your CI. There is nothing to install and nothing to keep up to date — every client hits the same endpoint, and new tools appear the moment we ship them.

Every tool runs as the authenticated user and sees exactly what that user can see.

What it exposes

24 tools, grouped around the questions people actually bring to CI:

• Find the failure – list_runs is the entry point, and each id feeds the next level: get_run, list_run_workflows, get_workflow, list_workflow_jobs, get_job. With no project named, mine=true lists your own runs across every project, which is the short path to “what of mine is broken”.
• Explain the failure – get_job names the failed step and its exit code. list_job_tests returns only the failing tests by default. get_job_logs reads the failed steps automatically when you do not name one. get_job_resource_usage reports what the executor actually used, against the limits of its resource class — memory near 100% is what an OOM kill looks like. list_job_artifacts gives the files the job kept, with download URLs.
• Fix and move on – rerun_workflow (with from_failed=true to reuse the jobs that passed) and cancel_workflow.
• Work on config before you push – validate_config compiles a config and reports its errors, expanding orbs, parameters, and matrix jobs. get_orb shows whether a pin is stale and get_orb_source shows how to call an orb correctly. None of these need a project; they work on YAML you are holding.
• Track what shipped – list_deployments answers “what is live” and “when did X ship” from a project alone, with list_deploy_components, list_deploy_environments, and list_deploy_component_versions underneath it, plus rollback_deploy_component to go back to a known-good version.
• Account data – get_me and download_usage_data.

What we tuned for

An agent’s constraints are not a human’s, so the tools are built around them:

• Logs cost tokens, so we do not send you raw ones. Step output is replayed through a terminal model rather than run through an ANSI stripper — tools like Docker redraw progress with carriage returns, and stripping the escapes alone leaves a pile of stale, half-drawn lines. Redraws collapse to their final state. tail_lines then keeps only the end of each step, where errors surface, defaulting to 500 and capped at 5000.
• Reading a large log should not cost a large amount of memory. The tail is taken in a bounded ring buffer as the stream arrives, so peak memory is a function of the bounds, not of how big the log was.
• Knowing which tool to reach for matters more than having the tool. Five tools take a job id and answer different questions, so the server ships instructions describing the id chain, which tool answers which question, and what each one costs — enough for a model to try list_job_tests before reaching for logs.
• Results are typed. Every tool declares an output schema, so answers come back as structured content rather than prose to be re-parsed.
• Errors say what was wrong — the wrong kind of id, a missing project, an execution index out of range — so a model can correct the call instead of retrying it unchanged.

Connect it

The server is listed in both the Claude and Cursor MCP directories, so in those clients you can add it without editing a config file. Otherwise, add https://mcp.circleci.com/v1/mcp as a remote MCP server: claude.ai and Claude Desktop take it under Settings → Connectors → Add custom connector, and Claude Code, Cursor, VS Code, and Windsurf are covered in the connection guide below.

CircleCI MCP overview →

Connecting to the CircleCI MCP server →

CircleCI now integrates with Cursor Origin in beta, on CircleCI Cloud. Connect an Origin repository and your existing .circleci/config.yml runs unchanged - pipelines trigger on push and pull request, with status reported back to the Origin PR.

CircleCI now integrates with Cursor Origin in beta, on CircleCI Cloud. Connect an Origin repository and your existing .circleci/config.yml runs unchanged - pipelines trigger on push and pull request, with status reported back to the Origin PR.

No Origin-specific configuration There is no Origin-specific CI syntax, translation layer, or separate config to maintain. The jobs, workflows, executors, contexts, resource classes, and test configuration you already use work the same way they do on GitHub, GitLab, and Bitbucket.

Connect an Origin repository

1. Open the Apps tab in Cursor Origin.
2. Select CircleCI and authorize access to your Origin organization.
3. Select or create the corresponding organization in CircleCI.
4. Run through Project Setup and choose the Origin repository to connect.
5. Push a commit. CircleCI detects your .circleci/config.yml and runs the pipeline.

You can also connect from the CircleCI web app (see how in this 1-minute video walk-through) or with the CircleCI CLI.

For detailed setup instructions, see Set up VCS connections.

For the full list of features supported on Cursor Origin, see Version control system integration overview.

The Xcode 27.0 RC image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.

Update September 11, 2026 We are relaxing the requireents around JUnit Output for Smarter Testing. For the best experience when it comes to dynamic test splitting and test skipping we do recommend JUnit output, it is however, not a requirement.

Update September 11, 2026 We are relaxing the requireents around JUnit Output for Smarter Testing. For the best experience when it comes to dynamic test splitting and test skipping we do recommend JUnit output, it is however, not a requirement.

What’s changing

Starting September 14, 2026, CircleCI will strongly recommend that all testsuites using Smarter Testing produce valid JUnit output from their test runs. This is improves outcomes for Test Impact Analysis (TIA) and Dynamic Test Splitting.

If your testsuite does not produce valid JUnit output test selection and splitting will not have the timing and result data they need to function optimally.

Why we are communicated this change

Smarter Testing features like TIA and Dynamic Test Splitting rely on JUnit data to understand which tests ran, how long they took, and whether they passed. Without valid JUnit output, these features can’t optimally select or distribute your tests meaning you will not get the full value from Smarter Testing.

What to look for?

Thinks to watch for:

• The outputs.junit field is not set in your testsuite’s run command
• The JUnit XML file is missing or malformed (corrupt or empty XML)
• The JUnit results don’t include the test atoms that were run

What you can do to optimize

1. Ensure your testsuite’s run command uses outputs.junit

Every testsuite should declare a JUnit output path and pass it to your test runner. Here’s an example using Vitest:

name: ci tests
...
run: vitest run --reporter=junit --outputFile="<< outputs.junit >>" --bail 0 << test.atoms >>
outputs:
  junit: test-reports/junit.xml

The key parts:

outputs.junit tells CircleCI where to find your JUnit XML file

• –outputFile=”« outputs.junit »” (or equivalent flag for your test runner) ensures the results are written to the correct location
• –reporter=junit (or equivalent) enables JUnit output in your test runner

1. If you use Dynamic Test Splitting, ensure JUnit results include all test atoms

When Dynamic Test Splitting is enabled, your JUnit output should reference the test atoms (files, packages, etc,. depending on your test runner) that were run. The test file paths should appear in the name, classname, or file XML attributes of your JUnit results.

name: ci tests
discover: echo "tests/index.test.ts"
run: vitest run --reporter=junit --outputFile="<< outputs.junit >>" --bail 0 << test.atoms >>
outputs:
  junit: test-reports/junit.xml  # should include test atoms in name, classname, or file XML attributes
options:
  dynamic-test-splitting: true

Adapting for your test runner

The examples above use Vitest, but the same principles apply to any test runner.

You should:

• Enable JUnit output in your test runner (e.g., –reporter=junit for Vitest, –junitxml for pytest, –format RspecJunitFormatter for RSpec)
• Write the output to « outputs.junit » using your runner’s output file flag Declare the output path under outputs.junit in your testsuite config

Refer to your test runner’s documentation for the specific flags to produce JUnit XML output.

Build tool cache is now available in Open Beta

Build tool cache is now available in Open Beta on CircleCI Cloud, offering up to 90% faster clean builds vs. no cache for eligible Gradle, Bazel, and Turborepo workloads (and up to 29% faster for Xcode).

Build tool cache is now available in Open Beta

Build tool cache is now available in Open Beta on CircleCI Cloud, offering up to 90% faster clean builds vs. no cache for eligible Gradle, Bazel, and Turborepo workloads (and up to 29% faster for Xcode).

The new with_tool_cache step transparently backs a build tool’s own remote cache with a CircleCI-managed cache backend; no need to hand-roll a save_cache/restore_cache pair for tool-specific build outputs.

Supported tools: Gradle, Bazel, Turborepo, and Xcode.

See the Build tool cache documentation for setup details, quickstart examples, and Beta caveats.

Beta Release Notes:

• This is an Open Beta feature. It’s under active development and behavior may change without notice.
• There is no additional cost to use with_tool_cache beyond standard cache storage usage.
• You can opt in now by adding the with_tool_cache step to your config.

Summary

Summary

The CircleCI GraphQL Unstable API (https://circleci.com/graphql-unstable) will reach end of life on January 1, 2027 and will no longer be supported or accessible after that date. This change does not impact Server customers.

What’s changing

• Endpoint deprecated: https://circleci.com/graphql-unstable
• End of support date: January 1, 2027
• Impact: Any integrations, scripts, or tooling that call this endpoint will stop working after the EOL date.

What you should do

• Migrate to the CircleCI V3 REST API, which provides equivalent and expanded functionality with stable, versioned endpoints.
• Upgrade your CIrcleCi CLI to V1, if you are still using V0. V3 API documentation: https://circleci.com/docs/api/v3/

Migration steps

• Review your current usage of https://circleci.com/graphql-unstable.
• Identify the corresponding V3 REST API endpoints for each query or mutation.
• Update your integration to use the V3 endpoints.
• Test your integration before the January 1, 2027 deadline.

Why this change

The graphql-unstable endpoint was never intended as a stable, production API. The V3 REST API offers:

• Stable, versioned endpoints with a formal deprecation policy
• Improved performance and reliability
• Comprehensive documentation and support

Timeline

• January 1, 2027
• Endpoint shut down; all requests will fail

Need help?

If you have questions or need assistance migrating, contact CircleCI Support or visit our API documentation.

Smart Deployments is now available. It gates each release on signals from your monitoring tools and rolls back automatically when a release fails validation. No Kubernetes, Argo Rollouts, or CircleCI release agent required.

Smart Deployments is now available. It gates each release on signals from your monitoring tools and rolls back automatically when a release fails validation. No Kubernetes, Argo Rollouts, or CircleCI release agent required.

How it works

After a deploy completes, the release validation engine opens an evaluation window and listens for alert webhooks from your monitoring tool. If the alert meets your failure criteria before the window closes, the release is marked failed and your rollback pipeline is triggered automatically, targeting the last successful release. If the window closes without a failure, the release succeeds.

What’s included

• Release validation – define a validation policy in your .circleci/config.yml using a validation block. Set the evaluation window, failure criteria, and maximum failure count.
• Automatic rollback – when validation fails, CircleCI triggers your rollback pipeline and resets the target to the last healthy release.
• Deploy tracking – record when deploys start and finish without adding a validation policy. Upgrade to continuous validation at any time by editing your config.
• Monitoring integrations – built-in support for Datadog and Prometheus-compatible tools (Alertmanager). Any tool that can POST an HTTP webhook works as a custom provider.

Get started

Use the guided setup in the CircleCI web app (Projects → your project → Smart Deployments). When the CircleCI GitHub App is installed and AI features are enabled, CircleCI generates your configuration and opens a pull request. Otherwise, the wizard shows examples to copy into your repo.

Smart Deployments overview →

Set up Smart Deployments →

Android gen2 resource classes are now generally available on CircleCI.

Based on realistic workload benchmarking using the nowinandroid project, we found gen2 to be 47% faster than gen1 equivalents.

Android gen2 resource classes are now generally available on CircleCI.

Based on realistic workload benchmarking using the nowinandroid project, we found gen2 to be 47% faster than gen1 equivalents.

Android gen2 resource classes are priced the same as other gen2 resource classes and are available for users on paid plans.

See the Android machine image documentation for details.

The Xcode 27.0 Beta 6 image is now available to be used in CircleCI pipelines.

The full manifest of installed software can be found here.