CircleCI OIDC tokens now include 3 new claims for enhanced authentication workflows:

• oidc.circleci.com/org-id
• oidc.circleci.com/pipeline-id
• oidc.circleci.com/pipeline-definition-id

These claims are available in both V1 and V2 token formats and provide more granular control when configuring trust policies with cloud providers.

For full details on all available OIDC claims and how to use them, see Using OpenID Connect tokens in jobs.

Runner Release 3.1.7

Both Machine and Container Runner:

Addressed CVEs in dependencies of the runner agent binary.

Container Runner:

The orchestrator init container’s resource requirements are now configurable via orchestrator.resources in the Helm values (chart version v101.1.6+).

For Ad-Hoc Tasks, Chunk now pushes changes to a branch and triggers your CI pipeline to validate them. If the pipeline fails, Chunk will attempt to fix the issues and push updated changes.

This helps ensure your code passes basic checks like linting and formatting, reducing frustration from broken code.

Note: Ad-Hoc Tasks currently update existing branches or apply changes to new ones, pull request creation functionality is coming soon.

We’ve updated schedule triggers for the GitHub App integration to use standard CRON format instead of our CircleCI-specific scheduling format.

With CRON syntax, you can now schedule pipelines down to specific minutes, giving you more precise control over when your workflows run. The interface displays your CRON string translated into plain English, and includes template buttons for common scheduling patterns.

The minimum scheduling interval remains 5 minutes, and a random delay of up to 10 minutes continues to be applied to all scheduled pipelines for load spreading.

All existing GitHub App schedule triggers have been automatically converted to CRON format. No action is required.

This change applies only to GitHub App schedule triggers. GitHub OAuth and Bitbucket schedule triggers are not affected.

Coming soon:

Natural language translation to CRON syntax will be available in an upcoming release.

Chunk will now attempt to automatically create a cci-agent-setup.yml file if one doesn’t exist in your repository.

You can also manually generate one by navigating to Organization Settings → Chunk Tasks, selecting the […] menu for your desired task, then going to Chunk Environment and clicking “Create File in GitHub”.

We just shipped an update to Active Versions.

What’s new: Active Versions is now prominently displayed at the top of the timeline view, making it effortless to see what’s deployed where.

Why it matters: Previously this was buried in nested menus. Now it’s front and center where teams need it most.

How it works: 3 active version cards appear by default at the top of the timeline. Click “See More” to expand and view up to 9 versions/environments at once.

You can now guide Chunk with a custom instruction file. Create a fix-flaky-test.md file in your .circleci directory to provide specific guidance about how you want the agent to approach fixing flaky tests in your project. This gives you fine-grained control over the agent’s behavior and lets you encode your team’s testing best practices directly into the fix generation process.

Example .circleci/fix-flaky-test.md file:

## Command Restrictions

- You MUST NOT use the `sleep()` command or `setTimeout()` for delays in any scripts
- You MUST NOT use `eval()` as it poses security risks
- Avoid using shell wildcards in destructive operations (e.g., `rm -rf *`)

## Code Style Preferences

- Prefer functional components over class components in React
- Favor explicit error handling over try-catch-all patterns
- Use async/await syntax over Promise chains for readability

## Security Considerations

- Always flag use of `dangerouslySetInnerHTML` in React components
- Highlight any potential SQL injection vulnerabilities
- Point out hardcoded credentials or API keys
- Flag any use of `eval()` or `Function()` constructors

## Documentation Standards

- Public APIs MUST include JSDoc comments
- Complex algorithms MUST include explanatory comments
- Do NOT proactively create markdown documentation files unless explicitly requested```

Changes

• Active user session timeout reduced from 1 year to 30 days
• Inactive user session timeout reduced from 2 weeks to 3 days

Effective November 30, 2025, CircleCI will reduce the inactive user session timeout from 2 weeks to 3 days and active user session timeout from 1 year to 30 days to align with NIST cybersecurity standards and enhance platform security.

What This Means

Active user sessions will be required to re-authenticate after 30 days (previously 1 year). Inactive accounts will be required to re-authenticate after 3 days (previous 2 weeks). SSO customers can still set custom session timeouts via their IdP provider. This change applies to all CircleCI web interface sessions.

Why We’re Making This Change

This update brings CircleCI in line with NIST (National Institute of Standards and Technology) recommended security practices and reduces the risk of unauthorized access from dormant sessions.

Action Required

No immediate action is required. Users who access CircleCI regularly may notice they need to re-authenticate more often.

Timeline

November 30, 2025: New 30-day session timeout takes effect. Existing active user sessions longer than 30 days will be invalidated on this date. In-active user sessions longer than 3 days will be invalidated on this date.

To streamline the setup of a Chunk environment file, you can now run ad-hoc commands in the environment defined by your cci-agent-setup.yml file and see instant feedback on whether they are working as expected.

Navigate to Organization Settings → Chunk Tasks → Select the gear symbol. Then follow the instructions on our community forum.

CircleCI regularly publishes new images and deprecates older ones used for execution environments. As part of the deprecation process, we run brownouts—short time windows where a soon-to-be retired image is temporarily unavailable. Brownouts help notify users that the image is reaching end-of-life and needs to be upgraded.

To give organizations more control, we’ve added a setting in the CircleCI web app: Organization Settings → Advanced → Enable image brownouts

On (default): Brownouts apply as usual.

Off: Brownouts are disabled for your organization, allowing continued use of the image until it is fully retired.

Note: Changes to this toggle may take up to 10 minutes to take effect. Only organization admins can change this setting.

Users can now specify a checkout method when using the checkout step. In addition to a traditional full clone, we now support blobless clones. Blobless clones reduce the amount of data fetched from the remote by asking the remote to filter out objects that are not attached to the current commit, resulting in faster checkouts for most projects.

You can perform a blobless clone by setting the method key in your checkout step:

jobs:
  build:
    steps:
      - checkout:
          method: blobless

Learn more about the new method key in our documentation.

Customers will no longer see configuration errors when all workflows in their pipeline are intentionally filtered out using when conditions.

Previously in the pipelines page, customers saw this error when all workflows were filtered out:

Here is the updated experience:

Added @latest tag to all NPX and Docker installation commands across multiple IDE integrations to ensure users always get the current version and prevent compatibility issues.

We’ve also added a troubleshooting section to help resolve common installation issues.

To see the full list of IDE integrations or for troubleshooting support, see our MCP server documentation.

Users can now set cache retention periods at the job level using the retention key in CircleCI config. Job level retention overrides the retention period set in plan usage controls, allowing users to optimize cache storage for their individual jobs. Flexible cache retention periods are useful for workflows with varying cache needs, such as short-lived feature branch jobs or jobs with frequently changing dependencies.

Set cache retention at the job level

jobs:
 hello-world:
   machine:
    image: ubuntu-2404:current
   steps:
    - run:
      name: Hello World
      command: echo "hello-world"
   retention:
    caches: 5d  # Keep caches for 5 days instead of default

Job-level settings can only reduce retention - not extend beyond plan limits. If retention is not set at the job level, caches will be stored for the period set in plan usage controls.

Learn more about CircleCI retention settings in our documentation.

Runner Release 3.1.5

Container Runner:

• Version 3.1.5 introduces Windows support for container runner in open preview. For detailed setup instructions and configuration guidance, visit our Windows container runner documentation.
• Container runner now filters for pods specifically managed by each replica, rather than watching all task pods with the managed-by: circleci-container-agent label. This optimization reduces API load when running multiple container agent instances within the same cluster.
• Added support for running the primary container under a custom user ID (UID). You can now specify a valid UID using the docker.user key in your CircleCI configuration, which will be mapped to the task pod container user.

New and improved docs site

We’re excited to launch our revamped documentation site at https://circleci.com/docs with better navigation, organization, and layout.

What’s new:

• Improved navigation structure
• Version switching for CircleCI Server docs
• Cleaner visual layout

Behind the scenes: We’ve migrated from our custom-built platform to Antora, which brings a number of benefits

• Improved organization of our source files
• Enhanced collaboration opportunities. Once our repo is public (coming soon) anyone can contribute including building the site in their local environment
• A more stable site with lower upkeep requirements
• Significantly faster publishing pipeline

Share your feedback: Try out the new site and let us know what you think on our community forum.

Known issues

• The docs repo (from which this new site is built) is not yet public. This means that all links from our docs to the repo are currently broken. This will be fixed in the coming days.
• Our 404 page is currently broken.

You can now delete your own Standalone and VCS organizations directly from the CircleCI web app.

How to delete your organization:

Navigate to Organization Settings > Overview and scroll to the bottom of the page.

What to expect:

• Deletions may take up to 24 hours to process completely.
• Standalone organizations: Will be removed entirely after a few hours.
• VCS organizations: All projects and data will be removed, but the organization will remain visible.

Requirements:

• Organization must be on the Free plan.
• You must be an organization admin.

This self-service feature eliminates the need to contact support for organization deletions.

For customers who are using rollback via pipeline, you can now add an optional rollback reason when triggering your rollback.

What’s Changed

Status checks for skipped jobs are no longer reported to GitHub when using the GitHub App integration. Previously, we reported skipped jobs as “pending” before they were skipped.

Why This Matters

• Improved PR workflow: Prevents situations where required checks could be bypassed when jobs are skipped
• Consistent behavior: Aligns with our existing behavior in the CircleCI GitHub OAuth integrations
• Better security: Ensures all required checks must actually run and pass before PRs can be merged

Who This Affects

This change only applies to users who have connected CircleCI to GitHub using the GitHub App integration. Users of our GitHub OAuth integration already experience this behavior.

What You Need to Do

No action is required. This change has been applied automatically to all pipelines using the GitHub App integration.

We’ve updated the CircleCI VS Code extension to support a new set of pipeline values used by the Rollbacks feature.

You can now view and work with these deployment-specific values directly within your development environment.

Newly supported pipeline values:

• pipeline.deploy.component_name
• pipeline.deploy.environment_name
• pipeline.deploy.target_version
• pipeline.deploy.current_version
• pipeline.deploy.namespace

For customers using CircleCI’s release-agent, the CircleCI web app now lets you invoke a rollback from the Project Overview Page. We’ve removed other rollback options from the Project Overview page for simplicity in these cases.

Based on user feedback, we have added the ability see your component’s current version in the deploys card on the project overview page. This is available for all who use manual deploy markers.

We’ve expanded the Project settings > Project Setup page with new editing capabilities. Previously view-only, this page now allows some management of pipelines and triggers in one unified location.

What’s new:

Users can now use this page to:

• View all pipelines integrated with GitHub (both OAuth app and GitHub App integration) and their trigger
• Add GitHub App and Custom Webhook triggers
• Edit existing GitHub App, GitHub OAuth and Custom Webhook triggers
• Delete Custom webhook triggers

Coming soon:

• Add and delete GitHub OAuth triggers. The “delete” functionality will ensure that OAuth pipelines stop building, without the need to manually remove the webhook from GitHub
• Add, edit and delete schedule triggers for OAuth pipelines
• Add, edit and delete pipelines
• Delete GitHub App triggers

For pipelines connected to Bitbucket or GitLab, please continue using the existing Pipelines and Triggers tabs.

This unified experience will eventually replace the separate Pipelines and Triggers tabs.

Questions or feedback? Reach out to benedetta@circleci.com.