Changelog

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.

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

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.

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 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.

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.

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

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/.

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).

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.

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.

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.

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 priced the same as other gen2 resource classes and are available for users on paid plans.

See the Android machine image documentation for details.

Gen2 x86 Docker resource classes, benchmarked at ~73% faster than gen1 equivalents, are now available to Free plan users.

See the x86 (gen2) Docker documentation and CircleCI price list for details.

New:

• Added support for SSH reruns on KubeVirt VM runners: you can now SSH directly into the exact VM that ran a job, over the public internet, for debugging. Off by default.

Improvements:

• runner-provisioner can now poll task counts using each resource class’s own token instead of a separate global CircleCI API token, so that token no longer needs to be provisioned as a secret. Existing configurations using the old token keep working.
• Added HTTP/HTTPS proxy support, so runner-provisioner and the VMs it provisions can operate in environments with restricted outbound internet access.
• Renamed the chart’s tokenProxy sidecar setting to sidecar for clarity; the old tokenProxy.enabled value is still honored.

Security:

• Patched a high-severity vulnerability in a bundled compression library (CVE-2026-63209).

IP ranges is now supported for x86 Docker Gen2 resources classes.

Pricing for IP ranges is unchanged and is the same across all executor generations: 450 credits per 1 GB of data used, for customers on a Performance or Scale plan, billed in addition to standard compute costs.

See the x86 (gen2) Docker documentation and IP ranges documentation for details.

You can now copy a failure-diagnosing prompt directly from the CircleCI UI and paste it into your preferred AI coding agent. Select the wrench icon on a failing workflow and choose Copy Fix Prompt to copy a ready-to-use prompt to your clipboard. Paste it into any AI coding tool to diagnose the failure and get a fix.

The prompt uses the CircleCI CLI command circleci run get <run-id> –failure-report to pull failure context. If the CLI is not installed, the prompt guides your agent through installation first.

The CircleCI CLI is now generally available.

Version 1.0 is a ground-up rewrite with a built-in MCP server, the ability to trigger and watch pipeline runs, and access to build output for jobs, all from your terminal. It is optimized for coding agents like Claude Code and Codex.

Install it at cli.circleci.com.

CircleCI Server customers should continue to use CLI v0.

You can now triage and fix failing workflows using Claude Code directly from the CircleCI UI.

Navigate to a pipeline run, click the wrench icon on a failing workflow, and select Fix with Claude Code. This opens Claude Code in your terminal with a pre-loaded prompt that pulls failure diagnostics using circleci run get --failure-report and produces a fix for the root cause.

You can now generate a condensed failure report for any pipeline run using circleci run get --failure-report. The report prints output for every failed step, formatted for AI agent consumption.

Pipe it to your local coding agent to diagnose and fix failing builds. By default, the CLI retrieves the latest run from your current git remote and branch. If the run did not fail, the report returns nothing. Pass a run ID to retrieve a specific run instead.

Link your Slack identity to CircleCI and get notified on builds you triggered in your Slack DMs — no more tab-hopping to check your build’s status.

You can set different status filters for Slack vs. email directly from your user settings page

To enable it:

Make sure your organization has the CircleCI Slack app installed (Org > Slack Integration). Link your Slack identity and set your notification preferences from User Settings > Notifications.

You can find more details in our docs here.

You can now manage code signing for iOS and macOS builds through the CircleCI API.

Upload your Apple signing certificate (.p12) and provisioning profiles, create a signing bundle, then reference it by name in your macos executor using the new code_signing key and the install_signing_bundle step. CircleCI installs the certificate and profiles into a temporary keychain on the runner at build time and removes them when the job finishes.

This is a native alternative to managing your own certificate store with Fastlane Match.

For setup steps, see Set up code signing for iOS and macOS projects.

This release lets a single provisioner deployment run many resource classes and ships a ready-to-use VM image so you can stand up a pool without building your own.

New:

• Multiple resource classes per deployment. One deployment now scales many resource classes at once, instead of needing a separate deployment per class.
• Default containerDisk image out of the box. Pool VMs boot from a maintained Ubuntu 24.04 image with Docker and common CI tooling pre-baked, so you get a working pool without building your own image first. An AlmaLinux image is also available for RHEL-family jobs.
• More flexible scaling. Time-based schedules to raise or lower capacity at set times of day, plus finer controls (headroom, scaleDownDelay, and maxSurge) grouped under a new scaling block.
• Hot-reload of resource-class config and secrets. Changes are picked up without restarting the pod.
• More per-class machine-runner options. workingDirectory, taskAgentDirectory, commandPrefix, useHomeSSHDirForCheckoutKeys, and maxRunTime are now configurable per resource class. See the machine runner 3 configuration reference.
• emptyDiskMounts to automatically format and mount extra disks on pool VMs.

Improvements:

• Runner token kept off pool VMs. A token-proxy sidecar, on by default and optional, holds the resource-class token and attaches it only on the task-claim call, so the token never reaches the VM and a job can’t read it from the machine it runs on. Jobs run as the unprivileged circleci user by default. A resource class can opt into elevated privileges with grantSudo, which relies on the proxy so even a root task still can’t reach the token.
• New operability, hardening, and log-level chart options.
• Config split into a ConfigMap and a Secret so non-sensitive settings and secrets are managed separately.
• Tuned default resource class and resized the Docker-baked containerDisk images.

See the runner provisioner guide for full setup and configuration details.

Understand how your team is using CircleCI with the new Project Usage dashboard. Get a per-project view of pipeline activity and usage over time, so you can see what’s running, how often, and where your capacity is going.

To access it: open any project and click Usage in the navigation.

A few things to keep in mind during preview:

• Available on CircleCI Cloud only
• Credit summary data is available starting July 18
• Trend data will be available starting August 18 — you’ll see a banner on the page until it’s ready
• Data is directional — great for understanding patterns and trends, but not a substitute for your billing statements

We’d love your feedback. Share it via the in-app survey or or on our Discuss post!

You can now get notified by Slack or email when a workflow is paused on an approval job. Each notification includes a link that takes you straight to the approval job in CircleCI, where you can approve or cancel it.

This works for:

• Slack — via project-level Slack notifications
• Email — via your existing notification preferences

These notifications are opt-in. To start receiving them, see the setup steps in the Notifications guide.

A new version of the CircleCI CLI is in Beta.

The new CLI has several enhancements including a built in MCP server, the ability to trigger and watch pipeline runs, and access build output for jobs. The new CLI is also optimized for agents like Claude Code and Codex to use.

Visit https://cli.circleci.com for installation instructions and full release notes.

We now have a consistent way to validate if your config is impacted by any of the upcoming breaking changes before they take effect on September 21, 2026.

CLI: Run circleci config validate --next

Config editor: Enable the “config next” toggle in your config editor

For more info on how to utilize the config editor or the new CLI flag, see the Discuss post.

New:

• The provisioner now supports high-availability deployments: with multiple replicas, one is elected leader and standbys take over automatically on failover.
• Uninstalling the Helm release now scales the VM pool down to zero before deletion, so runner VMs are cleaned up automatically.
• Runner logs are now forwarded to each VM’s serial console, making runner output visible through the virtualization layer for troubleshooting.
• AWS EKS now supports nested virtualization, and runner-provisioner has been validated against it. Bare metal nodes are no longer required to run runner VMs.

Improvements:

• Pool VMs now install the circleci-runner packages from a bundled containerDisk image at boot instead of fetching from packagecloud each time. This speeds up boots once the image is cached and enables air-gapped clusters, since the bundle can be rehosted on an internal registry. Configurable via runnerBundle.image; enabled by default.
• Provisioned VMs now default to masquerade networking.
• The container image pull policy now defaults to Always.
• imagePullSecrets is no longer set by default on the provisioner deployment.

Dependency updates: routine dependency and security bumps, including a moderate-severity HTTP/3 fix in quic-go (CVE-2026-40898).

When creating or editing an automated task, you can now add a custom MCP server instruction directly from the task form. MCP servers give Chunk additional context and information to act upon, making automated tasks more powerful and precise.

To create an automated task, navigate to Chunk → Automations (top right corner), then select New automated task.

Chunk now has a dedicated Automations page where you can create, view, and manage your automated tasks in one place. The page includes a task creation form, an automations list, and the ability to edit or force-run automations from a contextual menu.

Use the Automations page to set up recurring tasks like fixing flaky tests on a schedule, keeping dependencies up to date, or running custom prompts against your repositories automatically.

To get started, navigate to Chunk → Automations (top right corner).

Runner Provisioner, a new Kubernetes controller that automatically scales CircleCI runner VMs using KubeVirt, is now available in preview. The controller polls the CircleCI API for pending and running tasks and adjusts a VirtualMachinePool replica count to match demand — giving teams elastic, on-demand self-hosted runner capacity inside their own Kubernetes clusters.

Preview version 0.1.0 includes:

• A Helm chart for installation into any Kubernetes cluster with KubeVirt v1.8+
• Automatic scaling of runner VMs based on real-time CircleCI task demand
• Support for CircleCI Cloud and Server v4+
• Setup guidance for GKE, AKS, and EKS, including nested-virtualization and tainted-node-pool configurations
• Externally managed secrets via provisioner.existingSecret (e.g., Vault, Sealed Secrets)
• Customizable VirtualMachineInstanceSpec per resource class

Configuration schema and APIs may change before GA.

Read the docs →