Skip to content


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

Enterprise accounts now have a new root navigational experience, landing all users on an Enterprise Overview. Within this new page, GitHub Enterprise owners can create a README for their enterprise, which will be visible internally to all enterprise members. The Organization page still exists and can be found within the left-hand navigation of the enterprise account. This new experience is available on today and will be included in GitHub Enterprise Server 3.13.

To learn more, read our documentation on creating a README for an enterprise. To provide feedback about what you’d like to see on this new page, you may do so at anytime by clicking Give Feedback on the right-hand side of the new overview page, above the README.

See more

⏫ Copilot Code Completion model updated with more improvements

We’re excited to announce a new update to the model powering Copilot Code Completion across all IDEs! This update includes improved instruction following and performance improvement for our users. Here are the details:

  • Improved instruction following: Copilot can better understand and follow instructions given by the user. This means that Copilot is now better at generating code that matches the user’s intent and requirements.
  • Performance improvement: Finally, this model update includes a performance improvement for Copilot users. While this may not be noticeable in all cases, it can help make Copilot even faster and more efficient for certain tasks.
See more

Configuring merge queue in your repo rulesets is now available in public beta!

Screenshot showing the configuration of merge queue inside a ruleset

Merge queue & rule insights

Until now, rule insights would only list one pull request as merged even when multiple pull requests were merged by the queue at the same time. Also in this beta, each pull request in a merge queue will have an individual record in rule insights, linked to the actor that added the pull request to the merge queue.

Example screenshot showing rules insights and all PRs from a queue

Within the additional data of a rule insight dialog you can now see all the pull requests that merged in the same group along with the checks needed for the queue.

Example screenshot of details of a queue in rule insights


  • The merge queue rule cannot be configured via an API. This feature will be available in the near future.
  • Merge Queue for branch protections and repository rules do not support wildcard patterns
  • Not supported in organization rulesets.
  • Multiple merge queues configured against a single branch will prevent merging.

Join the discussion within GitHub Community.

See more

GitHub Copilot Enterprise is now generally available

GitHub Copilot Enterprise, our most advanced AI offering to date, is now generally available. With GitHub Copilot Enterprise, you can:

  • Gain a deeper understanding of your organization’s unique codebase: Copilot Chat in understands your code and streamlines code navigation and comprehension for developers.
  • Quickly access organizational knowledge and best practices: By letting developers attach knowledge bases (formerly known as docsets) to conversations, Copilot Chat in can answer questions based on your Markdown documentation stored on GitHub.
  • Review pull requests faster: With pull request summaries generated by GitHub Copilot and the ability to chat about changes in a pull request, reviewers can get up to speed on a pull request quickly and spend more time providing valuable feedback.

Following on from our limited public beta, we are bringing the following improvements to GitHub Copilot Enterprise today to make Copilot even smarter:

  • GitHub Copilot can now search Bing within chat conversations in to answer questions and find information outside of its general knowledge or your codebase (public beta).
  • You can now access your knowledge bases (formerly known as docsets) from any Copilot Chat conversation in with the “Attach knowledge” button. Organization owners can create knowledge bases from an organization’s settings.
  • GitHub Copilot knows about code as you browse, so you no longer have to be explicit about exactly what file, symbol or snippet you want to chat about.

Example conversation demonstrating how GitHub Copilot can access the code you are currently looking at

  • GitHub Copilot generates pull request summaries that are now more structured, with a “Summary” section that gives a high-level overview, and an “Outline” section that walks through the code.
  • GitHub Copilot can now analyze and explain any pull request diff, making it easier for pull request reviewers to understand changes and share great feedback.

Example conversation demonstrating how GitHub Copilot can explain and improve pull request diffs

Ready to give Copilot Chat in a try? Here are some suggested prompts to get you started:

  • Ask a question about recent events to trigger a Bing search: What updates were there in Node.js v20?
  • Open GitHub Copilot Chat on a repository and ask a question about the repository: Where is the turnOn function defined?
  • Open a file on and ask a question about that file: Draft unit test cases for each of the functions in the file I’m currently viewing
See more

Enterprise Managed Users can now enable secret scanning on their user namespace repositories. Owners of user repositories will receive secret scanning alerts when a supported secret is detected in their repository. User namespace repositories can also enable push protection.

In the enterprise level list of secret scanning alerts, enterprise owners can view all secrets detected in user namespace repositories. Enterprise owners can temporarily access user namespace repositories to view the secret details.

User namespace repositories are included in the security risk and coverage pages.

Secret scanning will also be supported on Enterprise Server personal repositories starting on GHES 3.13.

See more

As a proactive measure to protect availability, GitHub Apps that attempt to create high-complexity scoped installation tokens will receive failures if they would individually reference too many repositories. At the time of release, no GitHub App is above these limits – the limit is approximately 8 times higher than what any app is consuming. See below for details on how complexity is calculated.

Scoped tokens allow a GitHub App to create an installation token that has just a subset of the privileges that the app has within an organization – both a reduced set of repositories, as well as permissions.
In this way, an application with many permissions and access to many repositories can still safely request a token that’s good for just the access that’s currently required, a useful least-privilege feature.

When requesting a scoped token, applications can indicate both the permissions and repositories that are desired. Both parameters are optional, and if either is omitted the full corresponding access will be given to the token, either all granted permissions or all accessible repositories.

The first limit being added is when the repositories are included in the token request – now, no more than 500 individual repositories can be listed.

The second limit is if the repositories are not listed but permissions are, and the application is installed on some repositories in the organization – as in, it has not been explicitly granted access to all repositories in the organization.
In that case, the limit is based on the number of permissions being requested and the number of repositories the application has access to. If the complexity limit is exceeded, the application will recieve an error: Too many repositories for installation, and provides the maximum number of repositories the application can have access to in order to succeed, as well as other options to reduce the complexity of your token, which are provided here as well.

To reduce the complexity of your token request, you can do one of the following:
1. Reduce the number of repositories that the application has access to in the organization.
2. Reduce the number of permissions requested for the token.
3. Set the application to have access to “all” of the organization’s repositories.
4. Not request a scoped token at all, and instead request a standard installation token.

Any of these options will reduce the complexity of the token and allow the application to fetch tokens for that organization once again.

To learn more about GitHub App scoped token issuance and installation, see our documentation:

  • “Generating an installation access token for a GitHub App”
  • “Reviewing and modifying installed GitHub Apps”
  • REST API: “Create an installation access token for an app”
  • See more

    CodeQL 2.16.2 is now available to users of GitHub code scanning on, and all new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.

    Important changes in this release include:

    We added two new Java / Android queries (java/android/sensitive-text and java/android/sensitive-notification) to detect sensitive data exposure via text fields and notifications.

    We have improved the precision of several C/C++ queries.

    We now recognize collection expressions introduced in C# 12 (e.g. [1, y, 4, .. x]).

    For a full list of changes, please refer to the complete changelog for version 2.16.2

    See more

    Secret scanning is extending validity check support to Mailgun (mailgun_api_key) and Mailchimp (mailchimp_api_key) API keys.

    Validity checks indicate if the leaked credentials are active and could still be exploited. If you’ve previously enabled validation checks for a given repository, GitHub will now automatically verify validity for alerts on supported token types.

    Validity checks are available for repositories with GitHub Advanced Security on Enterprise Cloud. You can enable the feature at both organization and repository levels from the “Code security and analysis” settings page by checking the option to “automatically verify if a secret is valid by sending to the relevant partner.”

    Learn more about secret scanning or our supported patterns for validity checks.

    See more

    The GitHub Enterprise Server 3.12 release candidate is here

    GitHub Enterprise Server 3.12 gives customers more fine-grained control over deployment requirements, enhanced security controls, and some . Here are a few highlights:

    • Restrict your deployment rollouts to select tag patterns in Actions Environments.
    • Enforce which Actions workflows must pass with organization-wide repository rulesets.
    • Scale your security strategy with Dependabot Alert Rules. This public beta allows customers to choose how to respond to Dependabot alerts automatically by setting up custom auto-triage rules in their repository or organization.
    • Automate pull request merges using Merge Queues. Previously developers needed to manually update their pull requests prior to merging, to ensure their changes wouldn’t break the main branch. These updates would initiate a round of continuous integration checks that needed to pass before a pull request could be merged. But with merge queues, this process is automated by ensuring each pull request queued for merging is tested with other pull requests queued ahead of it.
    • Enhance the security of your code with a public beta of Secret Scanning for non-provider patterns, and an update to Code Scanning’s default setup to support all CodeQL languages.
    • GitHub Project templates are available at the organization level as a public beta, allowing customers to share out and learn best practises in how to set up and use projects to plan and track their work.
    • Updated global navigation to make using and finding information better, as well as improve accessibility and performance.
    • Highlight text in markdown files with accessibility aspects in mind with the alerts markdown extension, which gives you five levels to use (note, tip, important, warning, and caution).

    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.

    Read more about GitHub Enterprise Server 3.12 in the release notes,
    or download the release candidate now.
    If you have any feedback or questions, please contact our Support team.

    See more

    Developers with free accounts on GitHub could enable secret scanning’s push protection at the user level since last August. This automatically protects you from accidentally committing secrets to public repositories, regardless of whether the repository itself has secret scanning enabled. On February 27, this feature will be start to be enabled automatically for all free accounts across GitHub.

    If a secret is detected in any push to a public repository, your push will be blocked. You will have the option to remove the secret from your commits or, if you deem the secret safe, bypass the block.

    You can enable this feature now in your user settings. After February 27, you can opt out of push protection and disable it. Disabling push protection may cause secrets to be accidentally leaked.

    See more

    repository custom properties banner image

    We’re excited to announce the general availability of Repository Custom Properties, a major enhancement to how repositories are managed and classified across GitHub organizations.

    Properties offer a flexible way to add meaningful metadata to your repositories that simplifies repository classification, enhances discoverability, and seamlessly integrates with rulesets.

    Check out this video from our own Jon Peck for a walk through of a common scenario.

    New organization repositories list public beta

    Starting today the new repositories list view moves to public beta.

    Improvements to Repository Rulesets

    Repository Rules now support adding Dependabot to bypass lists. This enables you to let Dependabot merge changes to a repository’s protected branch.

    Learn more about managing custom properties for your organization and managing rulesets for your organization.

    Head over to community discussions for feedback.

    See more

    On December 14, 2023, GitHub Actions released v4 of the actions to upload and download artifacts. This version improves upload/download speeds by up to 98%, addresses long-standing customer feedback requests, and represents the future of artifacts in GitHub Actions.

    With the introduction of v4, we will be deprecating v1 and v2 of actions/upload-artifact, actions/download-artifact, and related npm packages on June 30, 2024. We strongly encourage customers to update their workflows to begin using v4 of the artifact actions.

    In order to prevent issues for customers using GitHub Connect, the tags for v1 through v2 will not be removed from the actions/upload-artifact and actions/download-artifact project repositories. However, attempting to use a version of the actions after the announced deprecation date will result in a workflow failure. This deprecation will not impact any existing versions of GitHub Enterprise Server being used by customers.

    This announcement will also be added to actions/upload-artifact and actions/download-artifact. Please visit the documentation to learn more about storing workflow data as artifacts in Actions.

    See more

    If you use private hosted pub repositories or registries to manage your Dart dependencies, Dependabot can now automatically update those dependencies. By adding the details of the private repository or registry to dependabot.yml, Dependabot will be able to access and update these dependencies.

    See more

    The secret_scanning_alert webhook is sent for activity related to secret scanning alerts. Secret scanning webhooks now support validity checks, so you can keep track of changes to validity status.

    Changes to the secret_scanning_alert webhook:

    • A new validity property that is either active, inactive, or unknown depending on the most recent validity check.
    • A new action type, validated, which is triggered when a secret’s validity status changes.

    Note: you must enable validity checks at the repository or organization level in order to opt in to the feature. This can be done from your secret scanning settings on the Code security and analysis settings page by selecting the option to “automatically verify if a secret is valid by sending it to the relevant partner.”

    Learn more about which secret types are supported or the secret scanning webhook.

    See more

    We’re excited to announce an important upgrade to the Codespaces connection infrastructure. Our team has been working to enhance the security, reliability, and overall performance of both the main connection and port forwarding features.

    What’s Changing

    To support these enhancements, we require the addition of * to be allowlisted for your firewall rules. This is a crucial step to ensure a seamless and secure experience with Codespaces.

    Release Plan

    Today we are going to enable you to opt into this new connection system through the Feature Preview section on This feature flag will be an opt-in flag for two weeks to enable you to test these changes against your own firewalls.

    In two weeks we will turn on these changes as a default. Users can opt out of using this new connection system for 30 days under the same feature flag. Customers who need more time will be able to request extra time through GitHub Support.

    After 30 more days we will move everyone over to our new connection system.

    Your Action Needed

    Ensure that * is allowlisted under your firewall rules.

    Enable the feature flag under to test these changes out yourself, as well as to ensure these domains are added to your firewall rules promptly to maintain uninterrupted access and optimal functionality of Codespaces.

    If you’re having any issues, read our firewall troubleshooting guide.

    We appreciate your cooperation and understanding as we continue to improve your experience with Codespaces. If you have any questions or need assistance, our support team is here to help.

    Thank you for being a valued member of the Codespaces community.

    See more

    When we first introduced GitHub Projects, we set a limit of 1,200 items per project to keep projects snappy and encourage tracking of only active work. Your feedback over the years has been invaluable, and we heard you loud and clear – sometimes, 1,200 items just isn’t enough for those growing, scaling projects. That’s why today, we’re excited to announce the private beta of Projects without Limits, which will enable unlimited issue limits on your projects.

    While this feature is still under development, the private beta currently supports the table, board, and roadmap layouts. Stay tuned for upcoming support for other beloved features such as slice by, swimlanes, mobile support, Projects API, and insights.

    If you’re a project admin and your project is nearing the item limit while exclusively using our supported features, this banner will appear over your project.

    To join the private beta waitlist, click the Join waitlist button. If space is available, your project will be granted beta access.

    For questions and feedback, please visit our Community Discussion.

    See more

    Copilot enhancements in Visual Studio Code

    We have introduced several features to the Copilot Chat extension in Visual Studio Code. These updates, available in Visual Studio Code 1.86 and the latest Copilot Chat extension 0.12, aim to provide a more streamlined and interactive coding experience. From new context variables that offer more control over the context you provide to Copilot, to expanded voice control capabilities, these updates are designed to improve your interaction with Copilot. Let’s take a closer look at these new features.

    Context variables

    You can use context variables to provide additional context to your questions in chat by using the # symbol. We have introduced two new context variables: #file and #editor to give you more control to specify that context.

    The #file variable lets you reference specific files from your workspace in your chat prompt. This helps make the answers from Copilot Chat more relevant to your code by providing context about the file you are working with. You can ask questions like “Can you suggest improvements to #file:package.json?” or “How do I add an extension in #file:devcontainer.json?”. By using the #file variable, you can get more targeted and accurate responses from Copilot.


    With the #editor context variable, you have control over whether to include the visible code of the active editor in your prompt to Copilot Chat. Previously, this information was automatically included when you hadn’t selected text in the editor. Now, you can choose to explicitly add the visible code to the context or omit it for more general questions.


    The #selection context variable already enabled you to focus Copilot’s suggestions on the specific code you select in the editor. By combining the #file, #editor, and #selection variables, you have full control over the context you provide to Copilot Chat, ensuring that you receive the most relevant and helpful answers.

    Inline chat

    We also added several features, such as Copilot Code Actions and an updated live mode, to make your Copilot inline chat experience more productive.

    As you’re writing and iterating over your code, you can now invoke Copilot through Code Actions (light bulb) on a specific line in the editor. This functionality gives you direct and targeted access to Copilot to improve your code. When there is an error in the code, you can use the sparkle Code Action to let Copilot explain the error or propose a fix.


    With the updated inline chat live mode, you can now see and evaluate the suggested code modifications in-place in the editor. Additionally, you have the option to drill through to the inline diff editor to compare the proposed changes against the original code.

    Responsible AI

    We emphasize responsible usage of AI, especially when it comes to source code. We’ve added a new setting that asks users for confirmation before saving code that was generated by Copilot. This ensures that users have control over the code generated by Copilot and can review it before saving.

    This setting, inlineChat.acceptedOrDiscardBeforeSave, is enabled by default. When the setting is enabled, a file save will wait for the user to accept or discard any pending inline chat session. This also applies when Auto Save is enabled, which will be temporarily turned off until inline chat has ended.


    Enhancing voice interactions

    We have further enhanced voice interactions in VS Code by giving you more flexibility and options for initiating voice interactions.

    Now, you can use the “Hey Code” voice command to start a voice session with Copilot Chat. You can choose whether you want this voice command to open the Chat view, inline chat in the editor, quick chat, or choose dynamically based on where the focus is.

    To enable this voice command, make sure to install the GitHub Copilot Chat and VS Code Speech extensions. Once installed, you can enable the “Hey Code” voice command in the accessibility.voice.keywordActivation setting.

    In addition, you can accelerate voice input for chat by using the “hold to speak” mode: press and hold the keybinding for inline chat and voice recording automatically starts. As soon as you release the keys, the request is sent to Copilot.

    Besides these main features, you can also explore our other exciting new preview features.

    See more

    We are excited to announce the GA release of Copilot in GitHub Support, a faster way to find answers to your GitHub-related questions! Copilot in GitHub Support is an AI-powered assistant that answers questions based on our official GitHub documentation.
    It will help you get instant answers to some of your basic questions without needing to create a support ticket.

    This tool is part of our ongoing efforts to make GitHub the best place for all developers to collaborate, innovate, and ship great software. We believe that Copilot in GitHub Support will enhance your experience and productivity.

    We look forward to hearing from you and learning from your feedback. Try out Copilot in GitHub Support today!

    See more

    Secret scanning is extending validity check support to several additional token types.

    Validity checks indicate if the leaked credentials are active and could still be exploited. If you’ve previously enabled validation checks for a given repository, GitHub will now automatically verify validity for alerts on supported token types. In addition to token types announced in our previous changelogs, you will now see validity checks for the following token types:

    Provider Token
    Dropbox dropbox_short_lived_access_token
    Notion notion_integration_token
    OpenAI openai_api_key
    OpenAI openai_api_key_v2
    SendGrid sendgrid_api_key
    Stripe stripe_api_key
    Stripe stripe_test_secret_key
    Telegram telegram_bot_token

    Validity checks are available for repositories with GitHub Advanced Security on Enterprise Cloud. You can enable the feature at both organization and repository levels from the “Code security and analysis” settings page by checking the option to “automatically verify if a secret is valid by sending to the relevant partner.”

    Learn more about secret scanning or our supported patterns for validity checks.

    See more

    Code scanning can now be enabled on repositories even if they don’t contain any code written in the languages currently supported by CodeQL. Default setup will automatically trigger the first scan when a supported language is detected on the default branch. This means users can now enable code scanning using default setup, for example on empty repositories, and have confidence that they will be automatically protected in the future when the languages in the repository change to include supported languages.

    This also takes effect from the organization level so you can bulk-enable code scanning on repositories without CodeQL supported languages.

    Enabled on repo without supported languages

    This change is now on and will be available in GitHub Enterprise Server 3.13. For more information, see “About code scanning default setup.”

    See more