apps

Subscribe to all “apps” 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

Copilot Extensions GA

Your tools. Your workflows. All within Copilot Chat.

GitHub Copilot Extensions are now generally available for users across all Copilot license tiers. With Copilot Extensions, you can integrate and prompt your favorite tools directly in Copilot Chat using natural language wherever you develop, including Visual Studio Code, Visual Studio, JetBrains IDEs, and GitHub.com. Copilot Extensions on GitHub Mobile will be generally available in the coming weeks.

Copilot Extensions help you stay in your workflow, with context-aware assistance from your favorite tools right at your fingertips. Today’s marketplace is home to a wide range of extensions, from Perplexity to Stack Overflow, to Docker and Mermaid Chart. Developers can unlock productivity gains with extensions in minutes. For example, Arm’s extension streamlines cloud adoption and migration, enabling developers to build, test, and deploy software on Arm-based servers while seamlessly leveraging Arm’s efficient, scalable, and high-performance architecture.

Explore these extensions and more on the GitHub Marketplace to bring new contexts and capabilities into the chat. All you need is access to GitHub Copilot to get started. 🚀

Building GitHub Copilot Extensions

Our platform also empowers you to build your own public or private extension depending on your requirements. This flexibility allows you to develop extremely customized extensions for your enterprise or organization, or develop general applications that can serve thousands of developers. The comprehensive Copilot Extensions toolkit provides you with centralized code samples and tools to help you build high quality extensions.

Alongside General Availability, we’re introducing OpenID Connect (OIDC) support for builders. This replaces the X-Github-Token auth model with native third-party tokens, reducing API round trips, and improving security. Instead of verifying GitHub tokens on every request, integrators receive pre-exchanged tokens tailored to their system, enabling direct authentication and authorization. This lowers latency, simplifies identity mapping, and aligns with GitHub’s existing OIDC workflows for Actions.

Builders have several ways to develop customized extensions, including:

  • Copilot skillsets, a faster, lightweight implementation option
  • Context passing, a capability that helps extensions benefit from a user’s local editor context for more tailored responses

Ready to contribute to our growing ecosystem? Get started with our Copilot Extension builder docs.

👀 What’s next?

Our general availability is only the starting point for agentic capabilities. We’re continuing to reimagine AI assisted workflows, with recent releases like agent mode and explorations around Project Padawan. These innovations only scratch the surface of what is possible with GitHub and AI agents. Continue being a part of the conversation by providing feedback as you try out extensions. ⭐

See more

We’re thrilled to announce the launch of a new category on GitHub Marketplace: Sustainability.

This new category is designed to highlight GitHub Actions and apps that focus on optimizing workflows to minimize environmental impact. Whether it’s by reducing resource consumption, streamlining builds, or enabling green practices in software development, this is a space for creators to showcase tools that contribute to a more sustainable future.

If you’re a creator, we encourage you to tag your listings with Sustainability if you believe your app or action aligns with this mission. Publishing to the Marketplace is straightforward — here’s how you can get started:
Publish your GitHub Action
Publish your GitHub App

For users, this category provides a dedicated space to discover and explore tools that aim to make software development workflows more environmentally friendly. While GitHub doesn’t verify the claims made by creators in this category, we encourage you to do your own research and find tools that align with your values and needs.

Currently, the Sustainability category is a blank slate, but we’re excited to see it come to life as creators tag their listings. Visit github.com/marketplace to explore the category and check back as new tools become available.

We can’t wait to see what the community shares! 🚀🌍

See more

GitHub Marketplace will be deprecating the “Featured Customers” section from app listing pages. This change will not cause any breaking changes. Here’s what publishers need to know:

Timeline:

  • January 27, 2025: Featured Customers sections will no longer be visible on public Marketplace listings
  • March 3, 2025: The Featured Customers section in publisher dashboards will be completely removed

Publishers can continue showcasing customer success stories directly in their app listing descriptions. However, GitHub will not review or approve customer lists provided in listing descriptions. Publishers are responsible for:

  • Obtaining explicit permission from customers before featuring them
  • Ensuring all customer usage claims are accurate and truthful

If a customer reports that they are falsely listed as a user of an app/extension, GitHub may review the authenticity of these claims. Listings found to be making false claims about customer usage will be notified, and may be removed from GitHub Marketplace.

Publishers with existing Featured Customers sections should save this information from the publisher settings before March 3rd if they wish to migrate it to their listing description.

This change helps streamline the Marketplace experience and aligns with our ongoing improvements to listing pages.

See more

On March 31, 2025, GitHub Copilot Extensions will require an updated header format for agent requests. Both updated and previous versions of the request headers will be supported until then. These headers denote requests that come from GitHub and enable your extension to communicate with GitHub.

Updated headers:
X-GitHub-Public-Key-Identifier
X-GitHub-Public-Key-Signature

Previous headers, to be deprecated on March 31, 2025:
Github-Public-Key-Identifier
Github-Public-Key-Signature

Please update your relevant checks to the correct headers by March 31, 2025 for a consistent experience and to avoid breaking changes. To learn more, visit this page.

See more

As a GitHub Enterprise Cloud organization owner, you and your designated users can now use API insights to visualize REST API activity for your entire organization or specific apps and users. This new feature helps you understand the sources of your REST API activity and manage against your primary rate limits—giving you visibility into the timeframe, apps, and API endpoints involved.

Who can access it

The API insights feature is available only at the organization level. By default, only organization owners can access it. However, organization owners can grant access to non-owners by creating a custom role at the organization level, assigning the permission named View organization API insights to the custom role, and then assigning the custom role to an organization member or team. See the documentation for managing organization custom roles.

Where to find it

The API insights feature is available to all GitHub Enterprise Cloud organizations. To access it on your organization home page, select Insights near the top of the page, and then select REST API on the left side of the page.

An image of an organization homepage where selecting Insights and then REST API will navigate to the new API insights feature.

How to use it

Use the Period and Interval drop-downs to choose the range of time displayed in the chart and how granularly to display REST API requests on the chart. These drop-downs also set the time range for the “Total REST requests,” the “Primary-rate-limited requests,” and the Actors table below the chart.

An image of the API insights feature page showing the Period drop-down expanded for selecting the time period of REST API activity to include.

The Actors table displays the GitHub Apps and users that made REST API requests in the current organization within the selected time period. Select a GitHub App to display its REST API activity and any primary rate-limiting. Select a user to display their personal REST API activity from personal access tokens (PATs) and OAuth apps acting on their behalf.

An image of the API insights feature page showing a table of actors, including GitHub Apps and users, that created REST API activity in the selected time period.

Tell us what you think

We welcome your feedback in the Enterprise community discussions.

Refer to the documentation for API insights for more details about understanding your organization’s REST API activity and investigating primary rate-limiting.

See more

Free Tier Support for GitHub Copilot Now Available on JetBrains IDEs

We’re excited to introduce the Free Tier for GitHub Copilot, now available for JetBrains IDEs! Starting today, you can enable GitHub Copilot in your JetBrains IDE with just a GitHub account—no trials or subscriptions required.

What’s included in the Free Tier?

The Free Tier provides everything you need to get started with GitHub Copilot:
* 2000 code completions/month
* 50 chat requests/month
* 64k context window for a seamless development experience

If you reach the limits, you can explore additional tiers to continue using GitHub Copilot’s powerful features.

Why it matters

GitHub Copilot in JetBrains IDEs empowers you to write code faster, focus on creative problem-solving, and enhance productivity—all with an AI assistant right in your IDE. With the Free Tier, more developers than ever can access these tools and start improving their workflows today.

Get started

We’d love for you to try the GitHub Copilot Plugin for JetBrains IDEs and share your thoughts. Your feedback plays a crucial role in helping us improve the product.

Join the discussion

Connect with the developer community in the GitHub Community Discussion to share your experiences, ask questions, and provide feedback.

See more

context passing example

GitHub Copilot Extensions can now access local context in your editor and github.com to provide you with richer and more tailored responses.

As a developer, you can benefit from context passing when interacting with extensions. Passing context to extensions will continue to maintain security through permission controls set by your administrators and content exclusion rules.

Available contexts by development environment

Local context is not passed to extensions by default.

Requirements for developers

  • Access to GitHub Copilot Extensions
  • Admin authorization to install on organization-owned repos

Requirements for builders

  • Explicit requests to receive editor context, configured in your GitHub app settings
  • Update your APIs to handle new reference types and account for certain references only being available in certain contexts

Connect with our community in our Discussion Forum, or relay your feedback here.

See more

GitHub Copilot plugin now available for JetBrains IDEs version 2024.3

The GitHub Copilot plugin for JetBrains IDEs now fully supports version 2024.3 for you favorite IDEs, including IntelliJ IDEA, PyCharm, and more! This update allows you to take advantage of the latest features and improvements in your development environment, making your coding experience even more seamless and efficient.

What’s new ✨

  • Full compatibility: Use GitHub Copilot with the latest version of JetBrains IDEs.
  • Enhanced authentication: Enjoy a more efficient and secure authentication process.

Benefits for developers ⚡️

  • Stay updated: Leverage the newest features and enhancements in your preferred JetBrains IDE.
  • Improved security: Benefit from a streamlined and secure authentication process.
  • Seamless integration: Experience better compatibility and performance with your development tools.

Get Involved 🛠

If you use version 2024.3 of a JetBrains IDE, we encourage you to try the updated GitHub Copilot plugin and share your feedback. Your input is invaluable in helping us refine and improve the product.

Join the Discussion 🚀

Connect with us and other developers in the GitHub Community Discussion to share your experiences, ask questions, and provide feedback.

See more

Copilot Extensions on JetBrains

GitHub Copilot Extensions are now available in public preview for JetBrains IDEs! With Copilot Extensions, you can expand GitHub Copilot’s capabilities and context directly within your preferred JetBrains IDE environment. Use extensions to query third-party tools or private data using natural language, all without leaving your favorite editor.

What’s new ✨

  • Full Copilot Extensions support across JetBrains IDEs
  • Seamless integration with IntelliJ IDEA, PyCharm, WebStorm, and more
  • Access to the complete GitHub Marketplace extensions ecosystem
  • Natural language interactions with your development tools

Key features 🚀

  • Query external tools and services in natural language, without context switching
  • Access private data securely through extensions
  • Customize your Copilot Chat experience in JetBrains IDEs

Getting started 🔧

  • Update to the latest version of the GitHub Copilot plugin for JetBrains IDEs
  • Enable Copilot Extensions in your IDE settings
  • Browse and install extensions on the GitHub Marketplace
  • Start using an extension with ‘@’ followed by the extension name, then type in your prompt

Developers can also build custom extensions for internal use or publish them to the GitHub Marketplace. For more information, see our documentation on building Copilot Extensions.

Requirements 📋

  • Access to GitHub Copilot
  • Compatible JetBrains IDE
  • Latest GitHub Copilot plugin version for JetBrains IDEs
  • One or more Copilot Extensions installed (VS Code chat participants are not supported)

To learn more, see our docs on using and installing Copilot Extensions.

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

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

As a GitHub Enterprise Cloud organization owner, you and your designated users can now use API insights to visualize REST API activity for your entire organization or specific apps and users. This new feature, currently in public preview, helps you understand the sources of your REST API activity and manage against your primary rate limits—giving you visibility into the timeframe, apps, and API endpoints involved.

Who can access it

The API insights feature is available only at the organization level. By default, only organization owners can access it. However, organization owners can grant access to non-owners by creating a custom role at the organization level, assigning the permission named View organization API insights to the custom role, and then assigning the custom role to an organization member or team. See the documentation for managing organization custom roles.

Where to find it

The API insights public preview feature is enabled for all GitHub Enterprise Cloud organizations. To access it on your organization home page, select Insights near the top of the page, and then select REST API on the left side of the page.

An image of an organization homepage where selecting Insights and then REST API will navigate to the new API insights feature.

How to use it

Use the Period and Interval drop-downs to choose the range of time displayed in the chart and how granularly to display REST API requests on the chart. These drop-downs also set the time range for the “Total REST requests,” the “Primary-rate-limited requests,” and the Actors table below the chart.

An image of the API insights feature page showing the Period drop-down expanded for selecting the time period of REST API activity to include.

The Actors table displays the GitHub Apps and users that made REST API requests in the current organization within the selected time period. Select a GitHub App to display its REST API activity and any primary-rate-limiting. Select a user to display their personal REST API activity from personal access tokens (PATs) and OAuth apps acting on their behalf.

An image of the API insights feature page showing a table of actors, including GitHub Apps and users, that created REST API activity in the selected time period.

Tell us what you think

We welcome your feedback in this community discussion.

Refer to the documentation for API insights for more details about understanding your organization’s REST API activity and investigating primary-rate-limiting.

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

The client_id field is now included in all API responses that describe a GitHub App. We are shifting to use the client ID as the primary identifier for an app, as client IDs are globally unique while application IDs and names are not.

Historically GitHub has used the app_name (aka slug) or the app_id (a database ID) to identify applications in our APIs. However, the app name is not immutable and the app ID is not sufficiently globally unique. We are gradually moving all App-related APIs to support the use of the client_id of an application as their primary identifier instead of the name or database ID – this was first seen in our change to support using the client ID to mint JWTs used for installation tokens.

We are making this change to prepare for upcoming features that allow programmatic management of applications in your enterprise. This additional data will make it easier to find the client ID of an application that you are interested in.

For more information about how to get application information, see our REST API documentation.

See more

Today, we’re releasing a beta version of an open source GitHub App that manages private mirrors of public upstream repositories. The Private Mirrors App (PMA) enables organizations with regulatory or policy code review requirements to conduct their reviews in private, before contributing changes upstream. The app manages the lifecycle and synchronization of these private mirrors and automatically configures rulesets to manage PRs made to the mirrors.

The main benefits of working on private mirrors through PMA are:

  • Branch protection rules can enforce PR reviews by people on particular teams to ensure proper signoffs
  • If commits include code/keys/docs that should not be made public, there’s the opportunity to remove them and squash merge without leaking history
  • Initial development can happen inside an Enterprise Managed Users (EMU) organization, whose users ordinarily can’t interact with public GitHub repos. Once the app syncs a change, the public fork and upstream PR use normal github.com identities.

If this is interesting to you, check out the Private Mirrors App repo. If you’ve got questions or feedback, feel free to file an issue in the repostitory or join the conversation in the GitHub Community Discussions.

See more