Feature Requests

Problem: We have a large monorepo without a package manager, and we rely on path filtering to run the right jobs for the right parts of the codebase. Today, path filtering happens inside the pipeline YAML (via dynamic config and the path-filter orb), which means we end up with a single, long, complex pipeline. Suggested Solution: Allow path filters to be configured at the trigger level in project settings — alongside the existing branch and tag filters — rather than requiring them inside the pipeline YAML. This would let us define multiple triggers, each scoped to a specific directory or set of paths, with each trigger pointing to its own focused pipeline config. For example: services/auth/** → triggers the auth pipeline services/payments/** → triggers the payments pipeline libs/shared/** → triggers a shared-libs validation pipeline

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 it stands today, users and orgs simultaneously using Github OAuth and Github App cannot rename or delete a Github OAuth pipeline. This can lead to confusion when duplicating an OAuth pipeline to GH App as the names will be the same with no distinction in the UI. You can only delete the OAuth trigger under project settings: https://circleci.com/docs/guides/integration/using-the-circleci-github-app-in-an-oauth-org/#authorization-steps

When using an MCP, the agent must go through a decision tree to select and tool. During this process it can select the wrong tool or may miss an available tools if many MCPs are enabled. To work around this it is helpful to have agent skills provided by a CLI. Skill metadata is always loaded allowing the agent to more easily select the workflow it needs. This also reduces the context bloat that MCP tools contribute to.

Problem Today, CPU and RAM utilization data for individual jobs is only visible in the "Resources" tab of the job UI. There is no public API endpoint that exposes this data programmatically. The closest alternative — the Usage Export API — returns a full org-level CSV dump with no way to filter by project, branch, or pipeline ID. For teams that want to automate resource analysis (e.g. comparing resource consumption between a feature branch and main ), this means pulling and processing a large dataset for the entire organization just to get data on a small subset of jobs. --- Requested changes Expose per-job CPU/RAM usage via a public API endpoint — make the data powering the job "Resources" tab accessible programmatically, scoped to a single job ID. Add filtering to the Usage Export API — allow the org-level usage export to be filtered by one or more of: project_id , branch , pipeline_id , workflow_id , or job_name . This would make the API usable for targeted analysis without requiring consumers to download and process the full org dataset. --- Use case Engineering teams want to automate resource rightsizing — comparing CPU/RAM utilization of jobs on a feature branch versus the default branch to identify over-provisioned resource classes before merging. This is currently impossible without either scraping the UI or processing a full org-level export. --- Impact Enables automated resource optimization workflows and cost analysis scripts Reduces unnecessary data transfer for customers with large orgs who only need project- or branch-scoped data Unlocks use cases like pre-merge resource regression detection and per-team cost attribution

This is like a bug in the CircleCI release agent. This has been demonstrated with https://github.com/circle-makotom/playground-20260416-multi-deployments Repro: Configure a SCM repository, CircleCI project and the K8s release agent accordingly. Set up two (or more K8s if you want) resource deployment resource which has the same circleci.com/component-name: property value. For instance, the above repository has nginx and apache-httpd both of which has circleci.com/component-name: 20260416-multi-deployments-component in their labels. Run deployment (see the config.yml ) Expected results: There would be a single row appearing in the Deploy dashboard that represents the single components having multiple deployments. Actual results: Two rows actually appeared in the Deploy dashboard - one of them would be tagged as "redeploy" - in the Deploy dashboard.

The CircleCI release agent on K8s cluster requires MANAGED_NAMESPACES which basically opts in management by the agent. This is not scalable for environments with matured DevOps infrastructure, where namespaces can be introduced, modified or torn down by individual developers in a quite dynamic fashion. The situation would be eased by generating the list of namespaces to be managed by the CircleCI release agent with exception list. For example, if there's an option to specify like "please manage all namespace, except for kube-systems, default, etc", it'd become more scalable.

Currently no notification is sent to notify of a Scheduled Pipeline failing to trigger. A notification or email should be sent to notify the user/admin that this has occurred so that it can be addressed.

We have a ton of projects which use CircleCI and one bad actor can easily use up our concurrency limit and cause queuing across our entire org. It would be great if we could configure per-project specific concurrency limits so we can have finer grain control and limit the impact any one project could have on others.

Currently, approving an approval type job requires two clicks from the workflow page: one to go to the job details and one to approve it. Since the details of the job are just the two buttons to approve or cancel, consider displaying them directly in the workflow job popover in the workflow page.