Error pipelines now correctly display their pipeline name in the “Pipeline” column on the pipelines page. Previously, these pipelines appeared as “unnamed pipeline”, making them harder to identify.
You can now view detailed information about your GitHub App installation directly in CircleCI under Organization Settings > VCS Connections. This includes when the app was installed or last updated, which permissions have been granted, and what repository access level has been configured.
You can now view detailed information about your GitHub App installation directly in CircleCI under Organization Settings > VCS Connections. This includes when the app was installed or last updated, which permissions have been granted, and what repository access level has been configured.
This information is visible to all users in your organization and can help you troubleshoot common issues:
Installation timestamps help identify when your GitHub App was installed and updated
Permission details let you verify whether newly requested permissions have been accepted in GitHub
Repository access level shows whether the app has access to all repos or only selected ones, which can help diagnose issues with repository visibility in CircleCI
Previously, this information was only available on the GitHub installation page and required GitHub admin access. Having it in CircleCI makes it easier to diagnose configuration issues without leaving the platform.
We’ve added a new organization setting called “Enable minor AI-powered features” (under Organization Settings > Advanced) that gives you granular control over smaller AI-powered features across the platform.
We’ve added a new organization setting called “Enable minor AI-powered features” (under Organization Settings > Advanced) that gives you granular control over smaller AI-powered features across the platform.
This setting currently controls access to our natural language to cron translation feature for GitHub App schedule triggers, and will be used for similar AI-powered convenience features as we add them.
This allows you to manage your AI feature preferences at the organization level, separate from our larger AI capabilities like intelligent build failure summaries and Chunk.
CircleCI OIDC tokens now include two additional claims:
oidc.circleci.com/workflow-id
oidc.circleci.com/job-id
These claims provide unique identifiers (UUIDs) for the specific workflow and job, enabling more precise access control policies when authenticating with cloud providers.
MFA is now required for all CircleCI accounts that use email and password Authentication. Customers with active sessions will be prompted to setup MFA when their session expires.
MFA is now required for all CircleCI accounts that use email and password Authentication. Customers with active sessions will be prompted to setup MFA when their session expires.
Active user session timeout reduced from 1 year to 30 days
Inactive user session timeout reduced from 2 weeks to 3 days
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).
Email and password authentication users will be required to setup MFA on re-authentication.
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
The session length 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.
MFA required for all email and password authentication accounts improves overall account security and aligns with industry best practices.
Unregistered users that trigger builds are now listed individually in Plans > Usage > Users, rather than appearing under a single unregistered user entry.
Unregistered users that trigger builds are now listed individually in Plans > Usage > Users, rather than appearing under a single unregistered user entry.
An unregistered user is how CircleCI tracks users (including automated systems or bots) that trigger builds, but have not signed up for CircleCI. This includes tools or services that perform actions on your behalf, such as CI bots, automation scripts, or dependency update bots, like Renovate.
Each unique active unregistered user counts toward your monthly active user total. Pricing structure remains unchanged (5 free users on Free/Performance plans, then per-user pricing for additional users).
We’ve redesigned the navigation interface for improved usability and a more streamlined experience. The navigation bar now has a fixed width and is no longer collapsible. The top and left navigation have been unified into a single interface, with page content displayed in its own dedicated container.
We’ve resolved an issue where Chunk would sometimes open new PRs to modify tests that had already been successfully fixed in previous PRs, even when no new failures had occurred since the original fix was merged. Chunk now tracks which tests it has already fixed and will not attempt to fix them again.
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.
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.
The branch dropdown in Chunk ad-hoc tasks now includes a search filter. Instead of scrolling through all branches, you can type to quickly find the branch you need.
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 now automatically picks up guidance from agents.md, claude.md, and fix-flaky-tests.md files when running ad-hoc tasks and environment setup. Simply add these files to the root of your repository and Chunk will incorporate the guidance automatically
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”.
The Chunk Settings task configurations table now shows all projects with scheduled tasks across your organization, not just your followed ones. You’ll need Project Admin or Organization Admin permissions to delete tasks.
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.
In the CircleCI web app, navigate to Organization settings > Chunk settings > “…” > Submit ad-hoc task. From a branch that already exists, you can ask Chunk to accomplish any task you’d like (ie. “remove the outdated call-to-action from my web app’s home page”). It will push its changes to the branch that you select. For these tasks, Chunk runs in the environment that you define in your cci-agent-setup.yml file (read more about Chunk’s environment here).
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.
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```
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.
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.
We’ve resolved an issue where updating Chunk’s model provider API key in the circleci-agents Context would cause Chunk to incorrectly attempt to use a previously configured model provider with the newly updated API key.
You can now create an “agent environment” CircleCI YML file. This lets you copy the environment-setup parts of your existing CircleCI config into a dedicated file for the agent. Name the file cci-agent-setup.yml and ensure that it is present in your .circleci directory & on the default branch. It should contain a workflow named cci-agent-setup with one job named cci-agent-setup. Note that this is only the environment setup, you do not need to include the steps to actually run the tests in this file. Read more on our community forum in the “Unable to run verification tests” section.
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.
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.
Fixed an issue where policies would fail. Neither the UI nor the CLI showed logs as to why the workflow was denied due to builds-service not being able to connect to policy-service on the correct port binding.
Chunk’s flaky test fixing capability has been updated to prevent updating shell scripts, yml files, json files, etc. This includes upgrading/downgrading dependency versions.
Chunk relies on CircleCI’s dynamic configuration feature for its flaky test fixing capability. When setting up a Chunk task configuration, if the CircleCI project setting for using dynamic configuration is not on already, CircleCI will enable the setting before running the first Chunk task.
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.
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.
We have changed the behaviour of pipelines triggered via custom webhook to ensure they always run, even if the commit they check out includes the keywords [skip-ci] or [ci-skip]. For more information about skip CI behaviour, visit the docs page.
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.
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.
Previously, pipelines configured with schedule workflow showed an incorrect trigger event in the pipelines page. Instead of displaying “Schedule”, these pipelines incorrectly showed “Push • Commit pushed” in the trigger event column.
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.
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.
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.
The find_underused_resource_classes tool is now available via the CircleCI MCP server, helping you identify underutilized resource classes to optimize compute costs and right-size your infrastructure. For setup instructions and usage details, see our MCP server documentation.
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.
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.
RDS is now compatible with server 4.7.6. We have removed the permissions checks that previously blocked full support.
In server-terraform, the included Nomad images are now based on Ubuntu 22.04 with CgroupsV1 enabled. CgroupsV2 is currently unsupported. These nomad AMIs are built automatic security updates enabled.
CVE fixes
Bug Fixes
Fixed an issue that caused a lag between when jobs finished and when they were marked as complete
Image Updates
frontend (underlying container is now circle-www-api)
The work on the page Project Settings > Project Setup is now complete. This page now provides complete control over GitHub pipelines and triggers from a single interface, regardless of how they’re integrated - whether through GitHub OAuth app or GitHub App integration.
All organizations that integrate with GitHub OAuth (recognizable by the segment /github/ or /gh/ in the URL) no longer have access to the Project setting tabs Pipelines and Triggers. Instead, Project settings > Project setup now consolidates both GitHub pipelines and triggers in one place.
The login page has been simplified by removing unnecessary steps. Users now see all available login options (Email, GitHub, and Bitbucket) immediately on the login page, eliminating the need to click an additional “Login” button. Messaging that previously restricted GitHub and Bitbucket login options based on signup dates has also been removed. Users should continue to log in with the same method they created their account with.
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.
