Changelog

Subscribe to all Changelog posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

A new REST API endpoint lists the secret scanning scan history for a repository, giving you visibility into when different types of secret scanning scans have occurred in your repository. This information can be helpful for auditing purposes and troubleshooting.

To get your repository’s scan history, call the /repos/{owner}/{repo}/secret-scanning/scan-history endpoint. The following table lists the responses returned by the API:

Response Description
incremental_scans The latest scan for all patterns on new git content committed to a repository
backfill_scans The latest scan for all patterns on the entire contents of a specific type (git, issues, pull-requests, discussions, wiki)
custom_pattern_backfill_scans The latest scan for a specific custom pattern on the entire contents of a specific type (git, issues, pull-requests, discussions, wiki)
pattern_update_scans The latest scan for a new or updated native pattern on git content in a repository

Secret scanning covers multiple scan sources, triggers, and methods of scanning. Scans listed in the API are not an exhaustive list of all scans for a repository. The following scans are not included:
– incremental scans and pattern update scans for non-git content types
– non-git backfills for custom patterns set at the repository level
– any pattern update scans completed before September 2024
– scans for passwords detected with Copilot Secret Scanning

A repository must have a GitHub Advanced Security license to get the scan history.

Learn more about how to secure your repositories with secret scanning.

See more

For organization owners, managing the security manager role is now easier and more flexible. These updates empower you to tailor security responsibilities and streamline role assignments to fit your needs:

  1. Assign the security manager role to individual users: The security manager role can now be assigned directly to individual users, in addition to teams. This added flexibility ensures security responsibilities are allocated precisely where needed.
  2. Streamlined role management in organization settings: Security manager assignment and configuration is now part of Settings > Organization roles at the organization level. This relocation centralizes and simplifies role management, making it intuitive to oversee security managers alongside other organizational roles.

Security manager assignment modal on the Organization roles - Role assignments page

Building on recent improvements

The addition of custom organization roles with repository permissions takes flexibility to the next level. With these updates, you can customize security roles to balance the right level of responsibility and access for your team. Here’s how you can leverage these features to meet your specific requirements:

  1. Craft a security manager role with fewer permissions: The addition of repository permissions to custom organization roles means you can build custom security roles with a subset of security manager permissions, such as:
    • View secret scanning
    • Dismiss secret scanning
    • View code scanning
    • Dismiss code scanning
    • Delete code scanning analyses
    • View Dependabot alerts
    • Dismiss Dependabot alerts

    This lets you assign security responsibilities without granting the full access of a security manager role.

  2. Expand the security manager role with additional permissions: Using custom organization roles, you can enhance the security manager role by adding additional organization-level or repository-specific permissions. For example, you can grant audit log access or other highly requested capabilities to create a tailored role that fits your team’s specific needs.

User with security manager role and custom auditor role assigned

These updates are now generally available on GitHub Enterprise Cloud and will be included in GitHub Enterprise Server 3.16.

Learn more about the security manager role, custom organization roles and send us your feedback

See more

You can now export security data for offline analysis, reporting, and archival purposes on the enterprise-level security overview pages. This includes:

  • Enterprise-level overview dashboard: Export alert-level data for all your scanning tools—including third-party scanning tools.
  • Enterprise-level risk page: Export repository-level data with aggregated counts of security alerts per repository for code scanning, Dependabot, and secret scanning.
  • Enterprise-level coverage page: Export repository-level data showing the enablement state for all Dependabot, code scanning, and secret scanning features.

New Export CSV button highlighted on the overview dashboard on the Security tab at the enterprise level

Just like at the organization level, exports will respect all filters you’ve applied to the page, making it easy to for you to tailor downloads to your specific needs. Whether you’re focused on enterprise-wide insights or repository-level details, the data is now at your fingertips.

You can download all data where you have an appropriate level of access.

Learn more about security overview and send us your feedback

See more

The image has a dark background, and two gradient-filled squares positioned off-canvas from the top-right. The foreground text says "What's New in GitHub Mobile" followed by a description of the November Update.

This update includes several key improvements: Copilot Chat on Mobile now includes beta supports for Copilot Extensions, iOS users can enjoy three new app icons in celebration of Universe, and Android users can pin their favorite repositories to the home screen.

With Copilot Extensions on Mobile, developers can extend Copilot’s capabilities on the go, integrating third-party tools, automating tasks, and receiving personalized code suggestions.

Image

iOS

What’s new

  • GitHub Copilot Extensions are in beta.
  • In celebration of Universe this year, we added 3 new app icons: Copilot, Nova Mona, and Quack. Head to Settings to choose your favorite.

Bug fixes

  • The more button in Copilot chat shows the three most recent conversations.
  • See contributors of a repository in the Explore tab with keyboards.
  • Select multiple code lines to add a review comment with keyboards.
  • Voiceover announces file status when jumping to a file while reviewing a pull request.
  • Entering the required inputs of a dispatched workflow correctly enables the Run Workflow button.
  • The settings button on iPad maintains its aspect ratio when the username is long.
  • Links to relative images within Markdown which include query parameters render the image without error.

Android

What’s new

  • GitHub Copilot Extensions are in beta.
  • Pin your favorite repositories directly to your device’s home screen.

Bug fixes

  • Checkboxes in the Files Changed screen now show the correct state when scrolling.
  • Relative images within Markdown files are now rendering correctly in all cases.
  • Longer Discussions now indicate page loading.
  • Improving accessibility for Feed headers.
  • More accurate TalkBack descriptions in trending repositories.
  • Color contrast improvements for Pull Request merge options.
See more

Based on customer feedback, we have updated how the created_at timestamp works in the Copilot seat details portion of responses from the following REST API endpoints:

  • /organization/{org}/billing/copilot/seats
  • /enterprises/{enterprise}/billing/copilot/seats
  • /organization/{org}/members/{username}/copilot

The created_at timestamp now shows when a user received Copilot access, rather than when their team, enterprise team, or organization was granted access. This matches the timestamp of the seat’s corresponding seat_added event in the Audit Log.

See more

Audit logs play a critical role in keeping enterprises secure and auditing enterprise activity for compliance. Since becoming generally available in January 2022, audit log streaming has been used by over 2000 enterprises to transmit audit logs to Enterprises’ preferred streaming endpoints. We are excited to announce three new features that will help you programmatically configure audit log streaming to multiple endpoints of your choosing. In doing so, we aim to empower you to select and employ tools that best support your security and compliance objectives.

Audit log steaming to a user defined HTTPS event collector

You can now enroll in a private preview that allows you to stream your audit logs to a user defined HTTPS event collector. This allows audit logs to written to any endpoint capable of accepting an HTTP post and meets our requirements for streaming GitHub audit logs. By introducing a user defined HTTPs event collector, you are empowered to stream your audit logs to the tool you feel best supports your enterprise’s needs.

Configure audit log streaming to a HTTPS Event Collector in the log streaming settings page for your Enterprise audit log

This private preview is only available to GitHub Enterprise Cloud customers. Enterprise administrators interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Let us know what you think by providing feedback on our community discussion post.

Enterprise audit logs can be streamed to two endpoints

You can participate in a public preview to stream your Enterprise’s audit log to two of GitHub’s supported streaming endpoints. You can stream your audit log to two endpoints of the same type, or you can stream to two different providers.

Log streaming settings page showing two configured streams. One to Datadog and the other to Splunk

This update allows you to use your preferred choice of tools for log storage and analysis. When managing your Enterprise, you may need to employ multiple tools to ensure compliance and maintain a strong security posture. This can involve different teams, requiring different levels of access, employing different technology to accomplish their objectives in supporting your Enterprise’s security and compliance requirements. By streaming your audit logs to two endpoints, you can employ multiple log storage and analysis tools without the need for a complex log routing architecture or dealing with increased latency.

This public preview is available to all GitHub Enterprise Cloud customers. We plan to ship this feature to GitHub Enterprise Server when this feature is released as generally available. To set up multiple streams, follow the instructions for each provider for setting up audit log streaming.

Configure audit log streaming via GitHub’s REST API

You can now configure audit log streaming via the REST API. This private beta grants access to new API endpoints for the following audit log streaming actions:

  • GET Endpoint Configuration: Retrieve the audit log streaming configuration for your Enterprise.
  • Stream Key Endpoint: Provide the customer with an audit streaming key. This key is essential for our customers to encrypt their secrets before sending them via an API call.
  • POST Endpoint: Create new audit log stream configurations.
  • PUT Endpoint: Update existing audit log stream configurations.
  • DELETE Endpoint: Delete existing audit log stream configurations.

With the introduction of these new REST API endpoints, enterprise owners can programmatically create, update, delete and list their Enterprise’s audit log streams. By allowing programmatic updates to the audit log streaming configuration, customers can automate tasks like rotating your audit log streaming secrets.

These new audit log streaming endpoints will impose a rate limit of 15 API requests per hour protect the availability of the audit log streaming service. For the time being, these endpoints are only accessible via personal access token (PAT) classic and OAuth token with admin:enterprise scope.

This feature is generally available on GitHub Enterprise Cloud (GHEC) and will be included in the release of GitHub Enterprise Server (GHES) version 3.16. To learn more, check out our documentation for the REST API endpoints for enterprise audit logs

See more

You can now enroll in a private preview to use GitHub-owned storage when migrating repositories to GitHub Enterprise Cloud using GitHub Enterprise Importer (GEI). This means that you no longer need to provide GEI with access to a customer-owned storage account via shared access keys to perform repository migrations. Instead, migrations can now be performed with repository archives uploaded directly to GitHub.com.

Once enrolled in the preview, repository migrations can be initiated to use GitHub-owned storage via the gh gei and gh bbs2gh command line extensions by passing in the --use-github-storage flag.

Repository migrations using the gh gei command line extension and passing in the --use-github-storage flag

If you’re interested in participating in this private preview, please reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. For additional technical details, instructions for running repository migrations with GitHub owned storage, or to provide feedback on this feature, please check out our community discussion post.

See more

Enterprise settings page with the selected option to enable two-factor authentication for all organizations within the enterprise. An option to enforce only secure methods of authentication is also been selected. There is a warning informing the admin that members without two-factor authentication will need to add it to re-gain access.

Enterprises now have more control over their two-factor authentication (2FA) policies for all members of their organization through an enhanced 2FA enrollment experience in GitHub.
With this update, enterprise and organization administrators can ensure that users are maintaining secure 2FA methods when accessing enterprise and org resources. Currently, GitHub defines SMS/text message as an insecure method of 2FA, and TOTP authentication applications, the GitHub Mobile app, security keys, and passkeys as secure methods. Members without a secure method of 2FA configured, or who have insecure 2FA configured, will be prompted to configure secure 2FA before being allowed to access resources.

Enterprises can enable this new 2FA policy alongside a general 2FA requirement for their members, and current enterprises with a 2FA requirement can update their 2FA settings to add this secure methods enforcement. Members who are non-compliant with the new 2FA policy will no longer be removed from organizations, lessening a historical friction around enforcing 2FA policies at an enterprise or organization level, and instead be prevented from accessing enterprise or organization resources while non-compliant.

This new policy enables enterprises to protect their resources by only allowing access for users who meet the required security standards, without compromising organization membership integrity.

Learn more about the new enterprise policy for requiring only secure methods of two-factor authentication and about how GitHub is securing developer accounts using 2FA.

See more

New accessibility enhancements to the security overview data visuals make it easier and more inclusive for everyone to interact with and understand code security insights.

Graph showing open alerts by severity on the security overview dashboard, with enhanced accessibility

What’s new?

  • Improved visual accessibility: Enhanced color contrast and better support for users with low vision, making it easier to interpret data visuals.
  • Keyboard navigation enhancements: Full keyboard-only navigation, including a clearly visible focus indicator, for smoother interactions without a mouse.
  • Assistive technology support: Improved compatibility with screen readers for better navigation and understanding of content.

These updates are now generally available on GitHub Enterprise Cloud and will be included in GitHub Enterprise Server 3.16.

Join the discussion in the GitHub Community and read more about GitHub’s commitment to accessibility

See more

Dependabot can now keep you up to date with the latest version of the .NET SDK by updating the global.json file in your repository. You can enable updates for the .NET SDK by adding a dotnet-sdk entry to your dependabot.yml file. At this time, Dependabot will not create security alerts for the .NET SDK, although performing regular version updates will ensure you’re always using the latest .NET SDK.

See our documentation to learn more about configuring Dependabot.

See more

Skillset header image

Today we’re introducing skillsets, a new lightweight way to build GitHub App-based Copilot Extensions alongside our existing agents approach. While agents offer full control over the user interaction, skillsets make it easy to integrate external tools and services into Copilot Chat by defining simple API endpoints – no AI expertise needed!

What’s new ✨

  • Let Copilot handle all AI interactions and response formatting
  • Define up to 5 skill endpoints that Copilot can call
  • Simple JSON schema configuration
  • Quick setup with minimal code

Benefits for builders ⚡️

  • Faster Development: Focus on your core functionality instead of AI interactions
  • Simple Implementation: Just define API endpoints, without managing LLM logic
  • Minimal Setup: No complex server infrastructure required, with the option to use existing APIs
  • Consistent Experience: Copilot maintains natural chat interactions automatically

Choosing your integration path 🛠

  1. Skillsets: Perfect for straightforward integrations like data retrieval and basic actions. You provide the API endpoints, and Copilot handles workloads like prompt crafting and response generation.
  2. Agents: Ideal for complex workflows needing custom logic, flexible prompt crafting, or specific LLM models. You control the entire interaction.

How it works 🏗️

End users interact with skillset-based extensions just like any other Copilot Extension. Just type @ followed by the extension name and ask in natural language. Behind the scenes, Copilot:

  • Analyzes the query to determine which skill to call
  • Structures the API request based on your JSON schema
  • Calls your endpoint to get the data
  • Formats and generates the response in chat

Architecture

architecture diagram

Requirements for extension builders

  • Access to GitHub Copilot
  • For organizational builds: Free, Team, or supported Enterprise Cloud organization types
  • Skillsets only apply to extensions built as GitHub Apps, and not VS Code chat participants

Getting started 🚀

Check out our documentation to learn how to build your first skillset.

Already built a Copilot Extension as an agent? Existing agent extensions can be converted into skillsets, but one extension cannot be both a skillset and an agent.

We want to hear your feedback!

See more

We’re excited to introduce persistent commit signature verification, a powerful new feature designed to elevate the security and reliability of your repository’s commit history.

Starting today, GitHub verifies commit signatures when they are first pushed, and once a commit’s signature is verified, it remains verified within its repository’s network. This supports organizations in maintaining a secure and accurate record of contributions without constantly rechecking the validity of every signature. You can view these persistent verifications directly on GitHub, where a quick hover over the Verified badge displays the timestamp of the original verification.

Efficient, Secure, and Transparent Verification

Previously, commit signatures were verified on demand, via a process that was not performant and had risks of previously verified signatures becoming “unverified” due to various reasons like service outages or key rotations.

Persistent commit signature verification solves these issues by validating signatures at the time of the commit and storing the verification details permanently. This also brings consistency to the commit history as git commits are immutable and they do not natively support key rotation.

Managing commit signatures can be a challenge, but persistent records ensures that verified commits remain verified over time, even if signing keys are rotated, revoked, or contributors leave the organization.

How to tell if the verification has a persistent record?

When a commit’s signature is verified upon being pushed to GitHub, the verification record is stored alongside the commit. This record is immutable, ensuring that the verified status is maintained permanently.

You can view the verification timestamp by hovering over the Verified badge on GitHub or via the GitHub REST API which now includes a verified_at field.

Learn more about commit signature verification on GitHub.

Designed for Real-World Key Rotation and Contributor Management

For organizations managing signature verification – whether GPG, SSH, or X.509 keys using S/MIME – persistent commit signature verification provides a robust way to ensure signature integrity across the board. Now, any commit with a verified status can retain that status, even when the signing key is rotated or removed.

Persistent commit signature verification is applied to new commits only. For commits pushed prior to this update, persistent records will be created upon the next verification, which happens when viewing a signed commit on GitHub anywhere the verified badge is displayed, or retrieving a signed commit via the REST API. This ensures that your repository remains secure while providing flexibility in managing your verification practices.

This approach lays the groundwork for future improvements aimed at enhancing repository integrity and authenticity of contributions within GitHub.

Key Management Caveat: Revocation and Expiration

Persistent commit signature verification ensures that verified commits retain their status indefinitely, it’s important to note this records the state of the signature at the time of the commit. If a signing key is later revoked, expired, or otherwise changed, GitHub will not re-verify previously signed commits or retroactively modify the verification status.

For organizations using S/MIME keys, this does introduce a minor change: revoked S/MIME keys will not verify new commits or those without an existing persistent record. Since git commits are immutable, persistent commit signature verification aligns with this concept by maintaining the original verification status without change. Organizations may need to manage key states directly to align with their security policies, especially in cases involving frequent key rotation or revocation.

This approach ensures that once a commit is verified, it remains trusted based on the record at the time, bringing consistency and long-term reliability to your commit history.

Moving Towards a Future with Secure and Authentic Contributions

With this launch, we’re addressing a key issue: commit verification that isn’t fragile or temporary. Teams can now implement signing key policies, without worrying about losing the verified status of past work.

Stay tuned for more updates as we continue to enhance commit verification. If you have feedback or suggestions, please let us know through our GitHub Discussions forum.

See more

The GitHub Enterprise Server 3.15 release candidate is here

You can now download the GitHub Enterprise Server 3.15 release candidate to try out the new features in this latest version. Version 3.15 gives customers enhanced deployment requirements and security controls. Here are a few more highlights in the 3.15 release:

  • We have updated root disk size requirements. New installations of GitHub Enterprise Server version 3.15 and upgrades to 3.15 now require a root disk size of at least 400GB. System will not boot otherwise. For more information on how to increase the root disk size in the appliance, see increasing storage capacity.
  • We have also updated minimum server specs recommended to run GHES. For more information, see minimum recommended requirements.

  • You can now interact with project status updates using GraphQL and webhooks. This unlocks new ways to automate how you provide and gather project status update information. For more information, see GitHub Projects.

  • Custom properties now support new property types: multi select and true/false. Organization repositories can now be queried and filtered via properties. Both the UI and API are supported. Read about filtering repositories.

  • Code security configurations are now available in GHES. These configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories. We have retired the old organization-level code security settings UI experience along with the API parameters that complemented it. For more information, see code security configurations.

  • Secret scanning push protection is now supported for content upload REST API endpoints – create a blob and create or update file contents. Push protection blocks you from pushing secrets to a repository and generates a secret scanning alert whenever you bypass the block.

  • CodeQL‘s support for Swift and Kotlin is now generally available. CodeQL is the static analysis engine that powers GitHub code scanning.

  • Organization owners can now grant a user or team access to all of the repositories in their org with a single click. New pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them. These can be further customized as well to grant specific repository permissions across your organization. For more information, see organization roles.

Release Candidates are a way for you to try the latest features early, and they help us gather feedback to ensure the release works in your environment. They should be tested on non-production environments. Read more about the release candidate process.

To learn more about GHES 3.15, check out release notes, or download the 3.15 release candidate now.

If you have any feedback or questions about the release candidate, please contact our Support Team.

See more

To remediate and triage alerts more effectively, you can now add an optional comment when reopening a secret scanning alert. Comments will appear in the alert timeline. Previously, you could only add a comment when closing the alert.

Learn more about how to secure your repositories with secret scanning. Let us know what you think by participating in a GitHub community discussion or signing up for a 60 minute feedback session.

See more

Secret scanning alerts resulting from an approved push protection bypass request will now show relevant details in the alert information surfaced in the REST API, webhooks, and audit logs. This allows information currently visible in the UI to be used in automated workflows.

Secret scanning alert REST API endpoints and webhook events now include the following fields:
push_protection_bypass_request_reviewer
push_protection_bypass_request_comment
push_protection_bypass_request_html_url

Audit log events for push protection bypasses now include the following fields:
push_protection_bypass_request_reviewer
push_protection_bypass_request_reviewer_id

Learn more about secret scanning and bypass controls for push protection.

See more

We’re excited to announce that content exclusion for Copilot is now generally available for all Copilot Business and Copilot Enterprise users! This feature, previously available only in beta, allows you to control which code Copilot can access to generate suggestions. When you exclude content from Copilot:

  • Code completion will not be available in the affected files.
  • The content in affected files will not inform code completion suggestions in other files.
  • The content in affected files will not inform GitHub Copilot Chat’s responses.

How to exclude content using content exclusions for Copilot?

Enterprise, organization, and repository admins can set up exclusions through their settings, as outlined in our documentation: Excluding content from GitHub Copilot

For availability across surfaces, please check the information here: Availability of content exclusion

Enterprise admin Copilot Content Exclusions

For users previously in beta:

Previously Used Enterprise-Level Rules:

  • If you already had enterprise-level exclusion rules set up (as described in previous changelog), you won’t experience any changes. These rules will continue to function as intended.

Previously Used Organization-Level Rules:

  • If your exclusions were previously set at the organization level but not the enterprise level: Org-level rules will no longer apply enterprise-wide. They will be limited to users who are assigned Copilot seats from your org, regardless of whether enterprise-level rules are applied.

Join the discussion within GitHub Community.

See more

Currently, you are able to query back up to 90 days worth of events from data tables you have access to when reviewing or utilizing specific events features: Events API (including push events), Atom feed, /timeline, or /dashboard-feed. On January 30th, 2025, we will be modifying the window of data retention for these features from 90 days to 30 days.

Why are we making changes?

We are making this change to help GitHub continue to scale for all our users, while continuing to provide existing customers of these features with the ability to still query and view recent important event information.

Which APIs will be impacted in this change?

The relevant APIs that will be affected are:
– /events : List public events
– /networks/{owner}/{repo}/events : List public events for a network of repositories
– /orgs/{org}/events : List public organization events
– /repos/{owner}/{repo}/events : List repository events
– /users/{username}/events : List events for the authenticated user
– /users/{username}/events/orgs/{org} : List organization events for the authenticated user
– /users/{username}/events/public : List public events for a user
– /users/{username}/received_events : List events received by the authenticated user
– /users/{username}/received_events/public : List public events received by a user
– /feeds : Get feeds

When can you expect the changes to occur?

On January 30th, 2025, we will be reducing the window that can be queried across those specified events features from 90 days to 30 days. In advance of that, we will test this change for 24 hours on December 3rd, 2024.

Additional support

As part of this change, we are adding an additional event (DiscussionEvent) as a new EventType for the Events API. This will allow you to query for an event related to Discussions that was not previously available.

We recommend leveraging a workflow that uses weekly or daily exports if you require further historical access.

Where can I learn more?

If you have concerns, comments, or feedback, please join us in this Discussion in the GitHub Community.

See more

GitHub Apps are now subject to a limit of 25 private keys per application and can create scoped tokens with access to more repositories. These changes support safer key management and access practices in your applications.

25 key limit for GitHub Apps

There is now a limit (25) on the number of private keys a GitHub App can have registered at one time. 99.99%+ of apps are below this limit – the ones above this limit will be unable to create more keys until they have deleted all but 24 of their keys.

Use of multiple keys for zero-downtime key rotation is encouraged. However, sharing keys among multiple parties is not recommended, which an unlimited number of keys lead developers towards. This new limit should help app developers look for safe alternatives earlier in the development lifecycle.

See our documentation on GitHub App key management for more details and best practices.

No limit on repositories for permissions-scoped tokens

In February 2024, GitHub placed a limit on the complexity of the scoped tokens that apps could request. Now, part of this limit no longer applies. Apps can now be installed on any number of repositories in an organization and request a scoped token for all those repositories. The limitation on tokens that request a subset of both permissions and tokens remains.

To learn about scoped tokens, and how they can improve the least-privilege access of your App’s tokens, see our GitHub App authentication documentation.

See more

Enterprises can now broadly roll out two-factor authentication (2FA) to all members of their organization through an enhanced 2FA enrollment experience in GitHub. With this update, non-compliant users will no longer be removed from organizations when an organization begins enforcing 2FA.

2FA will be enforced via conditional access policies, which means members who have not yet enabled 2FA will continue to have their organization membership, but be blocked from visiting any organization resources until they enable 2FA.

This enables organizations to enable a broader 2FA enrollment without disrupting the membership status of their members who are yet to enable 2FA. This also enables members without elevated privileges to enable or disable 2FA on their accounts without losing organization membership.

Learn more about how GitHub is securing developer accounts using 2FA, and why we’re urging more organizations to join us in these efforts.

See more

Screenshot showing the empty state of the new Copilot immersive experience with a number of suggestions how to get started and an a message in the input that reads - Who contribute to those files - with a repository and two files selected for context.

We’ve enhanced the fullscreen Copilot chat experience on github.com/copilot with a streamlined UI and an even easier way to handle context:

  • Effortlessly see and navigate previous conversations with a new collapsible sidebar
  • Dynamically set and remove repository context to suit your workflow
  • Manage all your resources seamlessly in a unified attachment menu

These updates are available in preview for Copilot Business and Copilot Individual users. Check out the updates, and let us know what you think using the in-product feedback option.

See more