Feature Requests

Background Standalone CircleCI organizations already have the concept of "Groups" in Organization Settings ( https://app.circleci.com/settings/organization/<org-slug>/groups/<group-id> ). Today, however, there's no way to scope project access to specific Groups. The ability to restrict projects by Group within an organization would simplify management greatly. This should be a many-to-many relationship: a single project can be assigned to multiple Groups, and a single Group can be assigned to multiple projects. What's the value add? Being able to assign projects to one or more Groups gives organizations fine-grained access control over who can see and act on which projects. Because the relationship is many-to-many, teams can model real-world access patterns without duplication (for example, a shared orb project or a centralized config repository can be exposed to several Groups at once). This makes onboarding and ongoing management significantly easier, since access is defined at the Group level rather than project by project. How would this let customers manage orgs efficiently? For enterprise organizations with a large number of projects and teams, manual per-project permission management doesn't scale. Group-based restrictions let teams inherit the right access automatically. This becomes especially powerful when Groups are mapped to an existing SSO group, so access can be governed by the customer's existing identity provider rather than managed separately in CircleCI, keeping permissions consistent and reducing the chance of drift. Exposing this configuration through the Terraform provider would make it fully manageable as code, so large organizations can provision, audit, and update project/Group assignments alongside the rest of their infrastructure rather than clicking through the UI.

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.

I like the fast navigation to My Pipelines, but it's quite tedious to get to an actual log of a failed test. I've recorded a video on my full screen (in Arc/Chromium) how to get there - I may be getting it wrong, but it's tedious UX: https://drive.google.com/file/d/1Zw8dm57pLGOyqUNZEs7We0yYIuDPfoq-/view?usp=sharing You can see I need to click/drag the handle quite a few times to get to the failure, and the fullscreen view is not really doing it (but if, instead of a modal, it would just open the detail it would be better IMHO, but I'm an engineer, not a designer). Compare to existing flow that is basically 2 clicks: https://drive.google.com/file/d/1le7w6pQ1lq9QgTpCKkd7EzggDf_1JALd/view?usp=sharing I like the overall design, just please make the most common user flows just a click away, thanks!

We've been using CircleCI to support deployments for an eCommerce website with highly visual product pages like Camp Hollow( https://camphollow.com ), where handcrafted porcelain collectibles, cake toppers, and product imagery are a major part of the customer experience. One challenge we've noticed is that a deployment can technically succeed while unintentionally affecting image layouts, responsive styling, or visual components that aren't caught by standard automated tests. It would be incredibly helpful if CircleCI offered a built-in way to generate visual deployment previews or integrate lightweight visual regression checks directly into the pipeline. Being able to quickly compare the appearance of key pages before production would help catch layout shifts, image rendering issues, and styling regressions earlier in the release process. For brands where presentation is just as important as functionality, this would improve confidence in every deployment while reducing the need for manual visual QA before publishing updates.

Currently machine executors favour memory increases over CPU. For many jobs more CPU power is required but not a large amount of more memory. It would be useful for CircleCI to offer resource classes that favoured a higher CPU share over high memory for jobs that are not memory intensive but still compute intensive.

Brands such as Rooh London would benefit from even more powerful cloud-based automation and workflow features that simplify website management and deployment. As a growing e-commerce business focused on handcrafted products and exceptional customer experience, reliable CI/CD processes, faster deployments, and seamless integrations can help ensure website updates, product launches, and performance improvements are delivered efficiently. Continued enhancements to cloud features, scalability, and developer workflows would make it easier for brands like Rooh London( https://www.roohlondon.co.uk/ ) to maintain a high-quality online shopping experience while supporting future growth.

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!

Description: We make heavy use of the dynamic config feature and trigger several different workflows based on pipeline parameters (for example, an "action" parameter that controls whether a run is a build, expire, or release). Today, pipeline parameters aren't available as filter options in the pipeline filters UI. What we'd like: Add pipeline parameters as filterable fields in the pipeline filters UI, alongside existing filters like branch or workflow name. Why it matters: Teams that drive workflow behavior off pipeline parameters have no easy way to group or filter their pipeline/workflow history by those parameter values in the UI. This makes it harder to quickly find or group related runs (e.g. all "release" runs) without digging into individual pipeline details. Source: Customer feedback from Josh Wilson (BreachRx), July 2026.

Add the ability to record and stream shell commands and outputs from "Rerun job with SSH" sessions to customer-owned S3 buckets for SIEM ingestion and forensic analysis. THE SECURITY CONCERN When someone initiates "Rerun job with SSH," they gain access to the build environment where environment variables (secrets, API keys, credentials) may be accessible. If an account is compromised or a bad actor gains access, they could dump credentials using printenv or env, exfiltrate sensitive data, or take actions that wouldn't be logged or detected. Without session recording, security teams have no forensic trail to understand what occurred during an incident. CUSTOMER SCENARIO Customer (enterprise SaaS company) has flagged SSH rerun as a security risk. Their infosec team wants to stream session activity to S3 for SIEM ingestion (Sumo Logic/Datadog), create alerts for suspicious commands, have forensic evidence for incident response, and meet compliance requirements for audit trails. CURRENT WORKAROUNDS AND GAPS Context Expression Restrictions (not job.ssh.enabled) can block sensitive credentials during SSH sessions, but this reduces debugging utility and doesn't provide visibility. Audit Log Streaming captures session metadata but not session content. Disabling SSH entirely eliminates the risk but removes a valuable debugging tool. REQUESTED CAPABILITY Ideal: Native session recording similar to AWS Session Manager. Capture all shell input (commands typed) and stdout/stderr output. Stream to customer-owned S3 bucket in near real-time. Structured format (JSON) for easy SIEM ingestion. Alternatives: JIT approval workflow for SSH sessions, webhook notifications when SSH sessions start, or integration with third-party session recording tools.

Enable a setting to restrict the "Rebuild with SSH" action to only administrators (role on Github Team) CCI-I-823