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

OpenAI o1-preview and o1-mini are now available to all users in GitHub Copilot Chat in VS Code, Visual Studio, and on github.com/copilot.

OpenAI o1 is a new series of AI models equipped with advanced reasoning capabilities, trained to think through complex tasks using an internal thought process. During our exploration of o1-preview with GitHub Copilot, we found the models better understood code constraints and edge cases, producing more efficient and higher quality results.

Now, you can test these models for yourself. You can power GitHub Copilot Chat with o1-preview, o1-mini, or the default GPT-4o model. By switching models during a conversation, you can quickly move from explaining APIs or generating boilerplate code to designing complex algorithms or analyzing logic bugs.

With this preview, we’re excited to bring OpenAI’s latest advancements to you, whether you’re developing software with Copilot or building the next great LLM-based product. We can’t wait to see what you build!

Join the discussion within GitHub Community.

See more

Code reviews and suggestions from colleagues, integrators, and AI agents like Copilot code review and Copilot autofix increase your code’s quality, but at times they can get overwhelming. You can now use Copilot Workspace directly in the context of your pull request to quickly refine, test, and incorporate code review feedback and suggestions from teammates and AI agents. Ship faster without compromising quality.

To get access, sign up for the waitlist here. This will also give you access to Copilot code review.

Copilot workspace with Copilot Review task

Using Copilot Workspace in your PRs, you can:

  • Review and incorporate code suggestions from teammates and AI agents in the context of the PR with an improved diff-viewing experience.
  • Refine and address merge-blocking feedback from directly within the PR with an improved code editing experience complete with language services and Copilot completions.
  • Build, test, and run proposed changes in the PR without affecting your personal build and test environment.

Validating an applied security autofix in Copilot Workspace

For more information see our documentation, or join the discussion within GitHub Community.

See more

In the latest versions of Visual Studio 2022, GitHub Copilot Completions now automatically considers semantically relevant C# files as additional context, even if those files are not open in your editor. This enhancement helps reduce hallucinations and provides more accurate, relevant suggestions.

GitHub Copilot provides autocomplete suggestions inline as you code. These suggestions are generated based on the content in your currently active file and any other open files in your editor. However, we’ve found that incorporating more relevant context leads to better suggestions.

To get started in Visual Studio 2022, ensure you’re using version 17.11 or later and have an active GitHub Copilot subscription. We hope this enhancement improves your experience with GitHub Copilot in Visual Studio. Our team is committed to improving Copilot support for C# developers in both Visual Studio and VS Code, with similar updates coming to VS Code soon.

For more details, visit the .NET team blog here.

Join our dedicated Community Discussions to discuss this update, share tips, and connect with other coders.

See more

Announcing the general availability of GitHub Enterprise Cloud with data residency in the EU

Today, GitHub Enterprise Cloud with data residency in the EU is generally available. GitHub Enterprise Cloud offers customers a robust, enterprise-grade development platform designed to enhance productivity, collaboration, and agility in software development, while providing the flexibility and control to choose where your code is stored, starting with the European Union (EU) and expanding to more regions in the future. Customers will also be able to monitor the status and availability of our services by region via the GitHub status webpage.

What is GitHub Enterprise Cloud with data residency?

GitHub Enterprise Cloud is a multi-tenant, enterprise SaaS deployment option of GitHub Enterprise with enhanced enterprise-grade capabilities and powered by Microsoft Azure. Customers experience a cloud-based unified platform that includes a suite of tools and capabilities to enhance the developer experience, so you can focus on building innovative software at scale without the complexities of having to manage updates and infrastructure.

GitHub Enterprise Cloud empowers you with the flexibility to choose where your code is stored, starting with the EU and expanding to more regions in the future. This enhanced control allows you to manage your data residency preferences to meet the unique needs of your business, whether for compliance, performance, availability, or other reasons. Powered by Microsoft Azure’s enterprise-grade infrastructure and security, GitHub Enterprise Cloud with data residency protects your code both in transit and at rest.

Who is this available for?

GitHub Enterprise Cloud is available to customers who need their code and repository data to reside in the EU. Support for data residency in additional regions will be released as they become available.

How can I access GitHub Enterprise Cloud with data residency?

Get started today by contacting our sales team. You can also learn more by visiting our docs.

Join our Community

Discuss this and other updates and swap tips with other Github Enterprise customers in our dedicated Community Discussions.

See more

A list of the GitHub Copilot Chat updates in the October VS Code release.

In the latest Visual Studio Code release, you will find a suite of enhancements to GitHub Copilot Chat, designed to streamline your coding, debugging, and testing processes. These features are now available for you to try out in the latest version of Visual Studio Code.

Start a code editing session with multi-file editing (Preview)

Setting: github.copilot.chat.edits.enabled

With multi-file editing, currently in preview, you can start an AI-powered code editing session where you can quickly iterate on code changes. Use multi-file editing to prompt GitHub Copilot to propose code changes across multiple files in your workspace. These edits are applied directly in the editor, so you can quickly review them in place, with the full context of the surrounding code.

Multi-file editing is great for iterating on large changes across multiple files. It brings the conversational flow of Copilot Chat and fast feedback from inline chat together in one experience. You can have an ongoing, multi-turn chat conversation on the side, while benefiting from inline code suggestions.

Get started with multi-file editing with these steps:

  1. Start an edit session by selecting Open Copilot Edits from the Chat menu.

Screenshot showing the Copilot menu in the Command Center, highlighting the Open Edit Session item

  1. Add relevant files to the working set to indicate to GitHub Copilot which files you want to work on.
  2. Enter a prompt to tell GitHub Copilot about the edit you want to make! For example, Add a simple navigation bar to all pages or Use vitest instead of jest.

Get more details about multi-file editing in the VS Code documentation. Try it out now and provide your feedback through our issues!

A new place to chat: Secondary Side Bar

The new default location for GitHub Copilot Chat view is the Secondary Side Bar. By using the Secondary Side Bar, you can have chat open at any time, while you still have other views available to you like the File Explorer or Source Control. This provides a more integrated AI experience in VS Code. You can quickly get to chat by using the Chat menu in the Command Center.

Chat view in its new location after having moved

With the introduction of the new Chat menu next to the Command Center, bringing up the Secondary Side Bar with chat is just a click away:

The Chat menu gives you access to the most common tasks for Copilot Chat. We provided a new setting, chat.commandCenter.enabled, that you can use to hide this menu if you wish.

Chat Menu

Note: If you had previously installed GitHub Copilot, a view will show up at the location you had Copilot Chat before that enables you to restore the Chat view to the old location.

Chat view in its old location after having moved

Code review (Preview)

With Copilot-powered code review in Visual Studio Code, you can now get fast, AI-powered feedback on your code as you write it, or request a review of all your changes before you push. Code review in Visual Studio Code is currently in preview. Try it out and provide feedback through our issues.

There are two ways to use code review in VS Code:

  • Review selection: For a quick review pass, select code in the editor and either select Copilot > Review and Comment from the editor context menu, or use the GitHub Copilot: Review and Comment command from the Command Palette. (This feature is in preview.)
  • Review changes: For a deeper review of all uncommitted changes, select the Copilot Code Review button in the Source Control view, which you can also do in your pull request on GitHub. (Join the waitlist, open to all Copilot subscribers)

Request review of uncommitted changes

Copilot’s feedback shows up as comments in the editor, attached to lines of your code. Where possible, the comments include actionable code suggestions, which you can apply.

Screenshot showing a comment reviewing a code selection

Head to the code review documentation to learn more.

GitHub Copilot’s quick review on code selection can provide feedback that matches the specific practices of your team or project, provided you give it the right context. When reviewing selections with custom review instructions, you can define those specific requirements via the github.copilot.chat.reviewSelection.instructions setting. Similar to code-generation and test-generation instructions, you can either define the instructions directly in the setting, or you can store them in a separate file and reference it in the setting.

The following code snippet shows an example of review instructions:

"github.copilot.chat.reviewSelection.instructions": [
{
"text": "Logging should be done with the Log4j ."
},
{
"text": "Always use the Polly library for fault-handling."
},
{
"file": "code-style.md" // import instructions from file `code-style.md`
}
],

Here is an example of the contents of the code-style.md file:

Private fields should start with an underscore.

A file can only contain one class declaration.

Sort by relevance in semantic search (Experimental)

Setting: github.copilot.chat.search.semanticTextResults

Last milestone, we introduced the ability to perform a semantic search using GitHub Copilot to get search results that are semantically relevant to your query. We have now improved the search results by sorting them by their relevance. Keyword matches from more relevant snippets are deemed more relevant overall.

File-based custom instructions enabled by default (Preview)

Setting: github.copilot.chat.codeGeneration.useInstructionFiles

The newly introduced .github/copilot-instructions.md file lets you document code-specific conventions for GitHub Copilot in your workspace or repository. With this release, the setting is enabled by default in VS Code, so chat conversations automatically include this file if it is present in the workspace. You can verify which instructions are added to a chat request in the Used references list. Learn more about customizing Copilot with instructions.

Intent detection in Copilot Chat

Setting: chat.experimental.detectParticipant.enabled

GitHub Copilot has several built-in chat participants, such as @workspace, which also contribute commands to the Chat view. Previously, you had to explicitly specify the chat participant and command in a chat prompt. To make it easier to use chat participants with natural language, we’ve enabled Copilot Chat to automatically route your question to a suitable participant or chat command.

Screenshot of Chat view that shows how the '@workspace' participant is automatically detected.

If the automatically selected participant is not appropriate for your question, you can select the rerun without link at the top of the chat response to resend your question to GitHub Copilot.

Control current editor context

Copilot Chat has always automatically included your current selection or the currently visible code as context with your chat request. Large Language Models (LLMs) are generally good at understanding whether a piece of context is relevant. But sometimes, when you ask a question that is not about your current editor, including this context might affect how the model interprets your question.

We now show a special attachment control in the chat input that gives a hint about the editor context. It also enables you to toggle whether or not to include the editor context.

The current editor context control in the chat input, which shows that the context is not included.

There are no changes to the behavior of the editor context. When the active editor has a selection, then just the selection is included. Otherwise, just the code that is scrolled into view is included. You can still attach other files or the full file by using the paperclip button or by typing # in the chat prompt.

A common use case of Copilot Chat is asking questions about the code in your workspace, such as using /tests to generate new unit tests for the selected code or asking @workspace to find some specific class or function in your project. This milestone, we added enhanced links for any workspace symbols that GitHub Copilot mentions in chat responses. These symbol links can help you better understand Copilot responses and learn more about the symbols used in them.

Symbol links are rendered as little pills in the response, just like the file links we added last milestone. To learn more about a symbol, select the symbol link to jump to that symbol’s definition:

You can also hover over the symbol link to see which file the symbol is defined in:

Hovering over a symbol link to see the file it's defined in

To start exploring a symbol in more detail, right-click on the symbol link to bring up a context menu with options, such as Go to Implementations or Go to References:

Using the context menu on a symbol link to learn more about a symbol

Basic symbol links should work for any language that supports Go to Definition. More advanced IntelliSense options, such as Go to Implementations, also require support for that language. Make sure to install language extensions to get the best symbol support for any programming languages used in GitHub Copilot responses.

Workspace indexing

@workspace lets you ask questions about code in your current project. This is implemented using either GitHub’s code search or a smart local index that VS Code constructs. This milestone, we added a few more UI elements that let you understand how this workspace index is being used.

First up, the new GitHub Copilot: Build Local Workspace index command lets you explicitly start indexing the current workspace. Normally, this indexing is automatically kicked off the first time you ask a @workspace question. With the new command, you can start indexing at any time. The command also enables indexing larger workspaces, currently up to 2000 files (not including ignored files, such as the node_modules or out directories).

While the index is being built, we now show a progress item in the status bar:

A status bar item showing the progress of indexing the current workspace

Indexing workspaces with many hundreds of files can take a little time. If you try to ask an @workspace question while indexing is being constructed, instead of waiting, GitHub Copilot will try to respond quickly by using a simpler local index that doesn’t take as long to build. We now show a warning in the response when this happens:

A warning showing on a response telling the user the Copilot user

Notice that Copilot was still able to answer the question in this case, even though it used the simpler local index. That’s often the case, although more ambiguous or complex questions might only be answerable once the more complex index has been constructed. Also keep in mind that if your workspace is backed by a GitHub repository, we can instead use GitHub’s code search to answer questions. In this case, GitHub Copilot uses code search instead of the simpler local index.

Fix using Copilot action in the Problem hover

The Problem hover now includes the action to fix the problem using GitHub Copilot. You can use this action with problems that have a fix available, and the fix is generated by Copilot.

The Problem hover showing a fix using Copilot action

Chat settings updates

As we continue to add new features to GitHub Copilot, we want to make it easier to check out what’s new and ready to try out. We’ve restructured our settings and added support for tagging preview and experimental settings.

New features may go through the following early access stages, which are described in the settings editor as follows:

Experimental: This setting controls a new feature that is actively being developed and may be unstable. It is subject to change or removal.

Preview: This setting controls a new feature that is still under refinement but is ready to use. Feedback is welcome.

You can check out all of GitHub Copilot’s preview features using @tag:preview in the Settings editor and all of the experimental features using @tag:experimental.

Discuss this and more in our dedicated community discussion.

See more

To reduce hallucinations, improve contextually-relevant suggestions, and provide a consistent C++ experience across Visual Studio and Visual Studio Code, related files such as headers are now automatically considered when gathering additional context for Copilot completions, even if they’re not open in the editor.

This is available to C++ users with an active GitHub Copilot subscription on Visual Studio 2022 17.12 or greater.

Discuss this update and swap tips with other developers in our dedicated Community Discussions.

See more

Secret scanning now supports delegated bypass controls for repository file uploads from the browser.

If delegated bypass is configured for an organization or repository, anyone without bypass permissions will need to submit a bypass request to approved reviewers in order to upload a file that contains a secret. This helps ensure that secrets are not accidentally committed to a repository.

For more information, see “About secret scanning” and “About delegated bypass for push protection.”

See more

Public leak and multi-repository indicators are now included in webhook and audit log event payloads for secret scanning alerts.

What are public leak and multi-repo labels?

To help you triage and remediate secret leaks more effectively, GitHub secret scanning indicates if a secret detected in your repository has also leaked publicly with a public leak label on the alert. The alert also indicates if the secret was exposed in other repositories across your organization or enterprise with a multi-repo label.

These labels provide additional understanding into the distribution of an exposed secret, while also making it easier to assess an alert’s risk and urgency. For example, a secret which has a known associated exposure in a public location has a higher likelihood of exploitation. Detection of public leaks is only currently supported for provider-based patterns.

The multi-repo label makes it easier to de-duplicate alerts and is supported for all secret types, including custom patterns. You can only view and navigate to other enterprise repositories with duplicate alerts if you have appropriate permissions to view them.

Both indicators currently apply only for newly created alerts.

Learn more

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

See more

GitHub Enterprise Cloud enterprise and organization administrators can now configure policies to restrict the usage of deploy keys across all the repositories of their organizations, giving you more control and greater security over your deploy keys.

Deploy keys provide SSH access to a single repository and are often used by integrations with external servers to a repository without using a personal GitHub account. However, this makes it hard to track the lifecycle of deploy keys across your repositories, as they exist outside of a user context and have no timed expiration capability. Now with the ability to set deploy key policies, you can more easily track and manage your deploy keys across your repositories.

All new enterprises and organizations will have the deploy key policy disabled by default.

For compatibility reasons, the deploy key policy will be enabled by default for all existing enterprises and organizations. You may want to explicitly disable the setting after evaluating and replace your deploy key usage with more secure alternatives like GitHub Apps.

For more details, learn more about the new policy for managing deploy keys.

See more

Now, verified nonprofits can access the GitHub Team plan for free or receive 25% off the GitHub Enterprise Cloud plan through GitHub for Nonprofits. This includes nonprofit organizations that are 501(c)(3) or equivalent and are non-governmental, non-academic, non-commercial, non-political in nature, and have no religious affiliation.

You can sign up here to get exclusive discounts automatically applied to your account. Join GitHub for Nonprofits, where technology meets purpose, and together, let’s create a more sustainable and equitable future for all.

Join the discussion within GitHub Community.

See more

Secret scanning bypass privileges for push protection are now generally available.

These controls allow you to choose who is allowed to bypass push protection, and introduce a review and approval cycle for pushes containing secrets from all other contributors. This can ensure push protection blocks are not accidentally bypassed and prevent secrets from being committed to your repositories.

Controls for bypass privileges can be set as part of your organization’s security configurations or at the repository level in your code security settings. You can add specific roles or teams to your bypass list. The individuals in these roles and teams will be able to bypass push protection themselves, and will act as reviewers for any bypass requests submitted by another contributor. The requests can be approved or denied, determining whether the commit can proceed into the repository.

screenshot of bypass privileges within security configurations

Reviewers can view the requests under the Security tab at either the organization level or repository level. Requests can also be accessed through audit log and webhook events.

Learn more about secret scanning and push protection, or join the discussion in the GitHub Community.

See more

Enterprise owners can now create GitHub Apps owned by their enterprise, with access restricted to just the organizations and members in the enterprise. Previously, if you wanted to share an app across multiple organizations within your enterprise, you had to either:

  • Duplicate the app for each organization, leading to management overhead and potential inconsistencies, or
  • Make the app public, potentially exposing it to users outside your enterprise.

With this update, you can now safely share an app across your entire enterprise without exposing it to the rest of GitHub.com, and manage your critical apps in a more secure and centralized location.

This also simplifies distribution and management for Copilot Extensions. You can now build custom extensions and share them across your enterprise without making them public – allowing you to create tools specific to your company’s needs and workflows, while keeping them private. Use of a single app across your enterprise ensures consistency and makes it easier to update extensions across all of your teams.

A screenshot of the GitHub app creation page, showing a single visibility option that reads "Only avocado-corp-owned organizations"

These apps can only be installed on organizations in your enterprise, and only members of your enterprise can sign in to them. To ensure the security of your app, user accounts cannot install these apps, only sign in to them. When users or organizations leave your enterprise, they immediately lose access to enterprise-owned apps, and the apps lose access to those users and organizations.

Besides the limitations on where they can be installed and who can sign in, these are standard GitHub Apps. Organization and repository administrators can install them depending on the permissions requested, and they have access to all of the organization and repository APIs that other apps do. Like other apps, they support Copilot Extensions and can be used in Copilot Chat.

Today, only enterprise owners can create and manage these applications. In the future we’ll add support for the App Manager role that exists for organization-owned applications as well, to make it easier for administrators to delegate access to apps in a secure manner.

To learn more about this public beta, see our documentation on GitHub Apps and the enterprise.

See more

You can now view exact locations of known public leaks for a secret scanning alert, as well as any repositories with duplicate alerts across your enterprise. Public leak and duplicate alert labels are now also surfaced via the REST API.

What are public leak and multi-repo labels?

To help you triage and remediate secret leaks more effectively, GitHub secret scanning now indicates if a secret detected in your repository has also leaked publicly with a public leak label on the alert. The alert also indicates if the secret was exposed in other repositories across your organization or enterprise with a multi-repo label.

These labels provide additional understanding into the distribution of an exposed secret, while also making it easier to assess an alert’s risk and urgency. For example, a secret which has a known associated exposure in a public location has a higher likelihood of exploitation. Detection of public leaks is only currently supported for provider-based patterns.

The multi-repo label makes it easier to de-duplicate alerts and is supported for all secret types, including custom patterns. You can only view and navigate to other enterprise repositories with duplicate alerts if you have appropriate permissions to view them.

Both indicators currently apply only for newly created alerts.

Learn more

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

See more

Copilot secret scanning is now generally available. Copilot secret scanning, which detects generic passwords using AI, offers greater precision for unstructured credentials that can cause security breaches if exposed. Over 350,000 repositories have already enabled this password detection.

To enable Copilot secret scanning, select “Scan for generic secrets” within your code security and analysis settings at the repository level, or the code security global settings at the organization level. You can also use the Update a repository API endpoint for enablement at the repository level. Support for enablement through your organization’s code security configurations, as well as enablement for organizations and enterprises with the API, will come in a future release.

Password detection is backed by the Copilot API and is available for all repositories with a GitHub Advanced Security license. You do not need a Copilot license to enable generic secret detection. Passwords found in git content will create a secret scanning alert in the “Experimental” tab, separate from regular alerts.

In effort to reduce false positives and detections of secrets that are used in tests, Copilot secret scanning will not:
– detect more than 100 passwords per push
– detect secrets in media files (.svg, .png, .jpeg)
– detect secrets in language files (.js, .py, .ts, .java, .cs, or .rb) that contain test, mock, or spec in the filepath
– detect additional secrets in files where five or more alerts have been marked as false positive

Note that passwords will not be detected in non-git content, like GitHub Issues or pull requests. Passwords are also excluded from push protection, another feature of secret scanning designed to prevent sensitive information from being pushed to your repository.

Learn more about secret scanning and generic secret detection or join our community discussion.

See more

Enterprise and organization administrators can now set limits on token lifetimes for the personal access tokens (PATs) used against their resources. These policies mandate token rotation on a regular basis and reduce how long a compromised token is good for, while also providing a lever to reduce the use of less-secure PATs in your company. This public preview is available for all enterprises and organizations, and will be included in GHES 3.16.

Administrators can choose a maximum lifetime between 1 and 366 days for fine-grained PATs and PATs (Classic).
The policies for each token type are distinct, so you can promote the use of fine-grained tokens with a longer lifetime while driving down PAT (Classic) usage with a very short lifetime requirement.

Screenshot of the policy UI for fine-grained PATs, showing that fine-grained PATs must expire within 90 days and that enterprise administrators are exempt

The policies apply when tokens are created, regenerated, or used.

If you want to create a PAT for a specific organization, but that organization or enterprise has a lifetime policy, your lifetime options will be restricted. Additionally, if you try to use an already-created PAT in an organization or enterprise with a policy, the call will fail if the token has too long a lifetime.

If your enterprise has audit log streaming enabled, you’ll be able to track when this policy has blocked a PAT from being used.

Allowing infinite-lifetime fine-grained PATs

With this change, developers can now create fine-grained tokens with no expiration for personal projects, an option that developer feedback said was needed to migrate from PATs (Classic) to more secure fine-grained PATs.

Enterprises and organizations have a 366 day expiration policy for fine-grained tokens by default, so developers still can’t create infinite lifetime fine-grained PATs for use against an organization they’re a member of, unless the administrator relaxes the policy.

For more information, see our documentation on Enterprise and Organization PAT policies.

Join the discussion within GitHub Community for feedback and questions.

See more

As part of our commitment to improving your experience at GitHub, we’re simplifying the terminology we use to refer to products that are in testing and validation stages. Starting on October 18, 2024, you’ll start seeing the word “Preview” instead of “Alpha” or “Beta” to describe our features that are not yet generally available.

What’s Changing?

Our goal with this update is to create a more consistent, clear process that helps our customers understand the state of new features and how they fit into their development workflows.

  • As shown in the table below, we’re reducing the number of terms we’re using but keeping the same flexibility for giving early access and gathering customer feedback before a General Availability (GA) launch.
  • The key difference between “Private” and “Public” previews is whether the release is publicly announced.

What to Expect

These changes are now live in customer-facing documentation as of today.

Here’s an overview of the changes:

Previous Terminology New Terminology Details
Alpha Private Preview
  • Not publicly announced
  • Limited number of customers
Private Beta
Technical Preview Technical Preview
  • Used for experiments and research projects primarily from GitHub Next
  • Limited number of customers
Limited Public Beta Public Preview
  • Publicly announced on the GitHub Changelog and includes GitHub Docs
  • May be open to all, or limited to selected customers behind a waitlist
Public Beta
General Availability General Availability
Deprecation Closing Down
  • Signals that a product or service is being phased out
Sunset Retired
  • Marks the official end of a product or feature’s life
  • No longer available, supported, or maintained

Thanks for being part of the GitHub community! These updates are designed to provide clearer communication and a smoother experience as we roll out new features.

See more

Now you can simplify the rollout of GitHub security products within your organization. Code security configurations now allow you to define collections of security settings and apply those settings to groups of repositories. Configurations help you maintain security settings for important features like code scanning, secret scanning, and Dependabot.

As previously announced in August, starting today, you can no longer enable or disable GitHub security features from the organization-level security coverage view, which has been deprecated and replaced with code security configurations for managing these settings.

Learn more about code security configurations and send us your feedback.

See more

Starting today, organizations on all plans, including the Free plan, can now utilize GitHub Actions runner groups with self-hosted runners. Runner groups enable you to manage runner permissions and control access to these runners across your organization.

Please note that GitHub-hosted larger runners are not available to free organizations and therefore cannot be included in runner groups. For more details about managing access to self-hosted runners using runner groups, please refer to our documentation.

See more

In the landscape image, a dark red gradient shape is positioned partially off-canvas from the top-right. The text "What's New in GitHub Mobile" is centered in the foreground and followed by a description of the October update.

August and September contained a number of improvements to GitHub Mobile, including Focused Notifications for those high-priority items in your Inbox, a contribution graph widget on Android, and a continued focus on accessibility.

Introducing Focused Notifications

View important notifications first with the new Focused filter in the Inbox.

A screenshot of the GitHub Mobile app showing certain notifications filtered down by priority

Learn more about Focused Notifications in the Changelog blog post.

iOS

What’s new

  • When accessing content protected by SAML single sign-on (SSO) login, authenticate directly with your organization without logging out.
  • Achievement badges rotate in your palm, just as it would in real life.

Bug fixes

  • Activate filters in Explore via keyboard navigation.
  • Assistive technologies iterate through reviewer information in the pull requests.
  • Confirm saving draft or deleting content before dismissing modal forms.
  • Description of a forked repository isn’t cut off when using large text sizes.
  • Dismiss triage sheet view with mouse on iPadOS.
  • Dismiss user status update, repository watch settings or the edit “My Work” view using the Escape key on a connected hardware keyboard.
  • Filter bar doesn’t clip at large accessibility sizes.
  • Font sizes respect the user’s Dynamic Type preference when composing comments.
  • Hide “Read More” button when Explore item doesn’t include truncated content.
  • Hovering over Copilot button with trackpad or mouse on iPadOS shows a pointer effect.
  • Improved support for large accessibility sizes within user profiles, account lists, pull request review line numbers, repository headers, the Explore view, code review view, comment author usernames, and editing Home “My Work” items.
  • Items in the Explore feed no longer truncate when using large text sizes.
  • Merge confirmation dialog appears as a modal on iPadOS.
  • Merging or marking a pull request as ready for review updates the pull request state in the Inbox and Recent Activity list.
  • Moving an item from one project group to another updates the title of the group.
  • Project pickers for a repository shows projects owned by the repository owner.
  • Repositories in lists no longer truncate their content when using large text sizes.
  • Scale badge icons on repository profile with font size.
  • Tapping a user avatar or username within comments navigates to the user profile.
  • Tapping on links to issue and pull request comments scrolls to the destination comments.
  • The area next to floating elements no longer blocks scrolling.
  • Toast messages no longer overlap with other floating elements on the screen.
  • Toolbars for user input fields scale with font size.
  • User and organization details no longer truncate when using large text sizes.
  • Username in a comment doesn’t disappear when using large text sizes.
  • VoiceOver announces “Jump to file” and “Dismiss line selection” buttons when reviewing file changes.
  • When sharing an issue or pull request, assistive technologies distinguish between the two types of content.
  • When viewing a list of workflow runs that have no runs yet, an empty state displays on the screen.

Android

What’s new

Bug fixes

  • Actions workflow logs show clearer error messages.
  • Editing a file opened via permalink no longer shows an endless spinner.
  • Filtering notifications by repository is more accessible for TalkBack users.
  • Improved accessibility for bulk selection of notifications.
  • Improved keyboard accessibility when reordering shortcuts.
  • Improved keyboard navigation on Home tab.
  • Pull request review suggestions are accessible via keyboard navigation.
  • Releases are more accessible via keyboard navigation.
  • Replying to and resolving comments is more accessible with large fonts.
  • Subscribing or unsubscribing to an issue or pull request considers custom repository watch settings.
  • The code options screen is more accessible with large fonts.
  • When viewing a list of workflow runs that have no runs yet, an empty state displays on the screen.
See more

The GitHub Advisory Database now features the Exploit Prediction Scoring System (EPSS) from the global Forum of Incident Response and Security Teams (FIRST), helping you better assess vulnerability risks.

EPSS scores predict the likelihood of a vulnerability being exploited, with scores ranging from 0 to 1 (0 to 100%). Higher scores mean higher risk. We also show the EPSS score percentile, indicating how a vulnerability compares to others.

For example, a 90.534% EPSS score at the 95th percentile means:

  • 90.534% chance of exploitation in the next 30 days.
  • 95% of other vulnerabilities are less likely to be exploited.

Learn more in the FIRST’s EPSS User Guide.

This feature will be available in GitHub Enterprise Server version 3.16 and later.

See more