Feature Requests

Today only actor values are captured in audit logs. It would be useful to link personal access tokens to the users that created them, and track usage from these tokens for auditing purposes. Currently, there is no way to track what user has used ssh-rerun on the platform (if accessed by PAT token); if a user account is compromised, audit logs will not surface what user initiated the rerun or what they did with it.

As title mentions, currently Chunk only supports 3 Bring Your Own Key models, ChatGPT, Claude and Bedrock. We know there's a CircleCI hosted option as well. Would like to see Google Vertex also supported.

We'd like to be able to point to a pre-existing secret for container-runner and have the token picked up from there. It should be simple to implement for this chart https://circleci-public.github.io/cci-k8s-release-agent This is the reference to the container-runner helm chart where it accepts the pre-existing secret secret: https://github.com/CircleCI-Public/container-runner-helm-chart/blob/main/values.yaml#L190

Currently it is possible to view jobs and workflows by branch but you can not specify further to show individual workflows. Users with multiple workflows may have trouble finding certain jobs that run less often when there may be many commits being made.An example would be a project (on any branch) with a workflow that runs per-commit and a secondary workflow that runs once per week. There would currently be no way to exclusively view the scheduled weekly workflow. CCI-I-757

When a CircleCI workflow kicks off async work — an external service, another pipeline, or any long-running process — there's no native way to get results back into the workflow and act on them. The only signal a workflow can receive today is a binary approve/reject on a hold job, with no data attached. This means you can't pass results back in, you can't make decisions based on what happened, and if you poll for a response you're burning credits on idle compute. Examples of where this comes up: security scans where you need to route based on severity rather than just pass/fail, ML model training that returns governance metrics and artifact locations, infrastructure provisioning where you need status before proceeding, and pipelines triggering other pipelines where context needs to carry back. Customers today work around this by building callback Lambdas, persisting results to external stores, and writing retrieval logic in downstream jobs — custom glue infrastructure that shouldn't be necessary. We'd love to hear from you on your use cases where you ran into this challenge: What async work are your pipelines waiting on? How are you getting results back into your workflow today? What decisions do your pipelines need to make based on those results? What workarounds have you had to build?

Summary Allow users to define and use custom, arbitrary labels when triggering CircleCI pipelines, beyond the current fixed set of standard labels (e.g., ci). Problem Statement Currently, pipeline trigger labels are limited to a predefined set of options. This restricts teams from implementing more granular or context-specific trigger logic, making it difficult to configure pipelines that behave differently based on custom conditions or workflows. Proposed Solution Enable users to define and pass arbitrary string labels when triggering a pipeline — either via the UI, API, or configuration file. These custom labels could then be used as conditions within pipeline configurations to control which jobs or workflows are executed. Example Use Cases Triggering a specific subset of jobs based on the type of change (e.g., hotfix, release-candidate, infra-only) Differentiating between automated triggers and manual triggers using custom identifiers Supporting complex branching strategies where different pipeline behaviors are needed for the same branch Expected Benefit Greater flexibility in pipeline configuration, enabling teams to implement more sophisticated CI/CD workflows without workarounds, and reducing the need for separate pipeline definitions to handle different trigger scenarios.

As part of the new CircleCI Slack integration, users need the ability to route different types of notifications from the same project to different Slack channels — for example, sending build notifications to one channel and chunk notifications to another. Problem Statement: The new Slack integration currently supports a single Slack channel per project for notifications. This creates friction in two distinct scenarios: Notification type separation — Teams want different notification categories (builds, chunks, etc.) to go to different channels for better signal-to-noise management. Cross-team pipeline ownership — When Team A owns a pipeline definition but Team B's work triggers failures in it, Team B currently has no way to route those failure notifications to their own channel. The only workaround is to make the pipeline never fail and post to Slack manually — which completely defeats the purpose of automated notifications. Proposed Solution: Within the new Slack integration, allow users to configure multiple Slack channel destinations per project, with the ability to filter/route by notification type (build, chunk, failure, success, etc.) and/or by pipeline definition. User Stories: As a platform engineer, I want build notifications and chunk notifications to go to separate channels so each team stays focused on relevant alerts. As a downstream team, I want pipeline failure notifications routed to my channel even when I don't own the pipeline definition, so I can act on failures that affect my work without relying on the pipeline-owning team.

Having improved support for caching would go a long way to help reduce restore times and eliminate the need to build offsite for bazel caching benefits.

We'd like the ability to lock-down (whitelist) what API permissions an API token has. For example, we want to have an API token solely for the purpose of creating environment variables in a project. We don't need it to do anything else and would like to be able to only grant this ability (to add environment variables) and nothing more. This way the security would be much improved instead of having a token that has full access. The API action in our case we'd like to have an explicit permission for is https://circleci.com/docs/api/v2/index.html#tag/Project/operation/createEnvVar I'm sure there'll be many other use-cases where it makes sense to only allow limited operations for improved security. Thanks!

Add OAuth support for MCP Server to reduce reliance on long-lived API keys