GitHub Copilot Extensions

6 minute read

On September 17, GitHub announced the public preview of GitHub Copilot Extensions, enabling developers to extend Copilot's capabilities by creating and installing extensions for use in IDEs and on GitHub's web interface. These extensions integrate with tools like Visual Studio, VS Code, GitHub.com, and GitHub mobile app, allowing developers to interact with databases, testing frameworks, deployment tools, and their own data—without leaving their preferred environment. This minimizes context switching and keeps developers in the flow.

This means you can use GitHub Copilot as a platform and extend it to fit your needs by leveraging Copilot's Gen AI capabilities, infrastructure, and available models while honoring configured policies. You can also access your own data or internal knowledge through a natural language interface.

But this is not the whole story. I intend to write a series of posts on how to write extensions, but in this first post I will show you how to create extensions.

GitHub Copilot extension types

There are two types of extensions: client-side and server-side. Client-side extensions are installed on the user's machine and are available in IDEs. Server-side extensions run on a server and are available in all Copilot-supported IDEs as well as on GitHub.com and the GitHub Mobile app.

As with everything, each type has its own pros and cons, and the choice depends on your requirements.

Client-side extensions

When is it beneficial to use a client-side extension?

Client-side extensions are ideal when your extension's purpose is to help the developer write code and be part of their daily workflow, leveraging the capabilities of the IDE (e.g., code completion, code navigation, other extensions). The extension has access to an up-to-date version of the local workspace, including uncommitted or unpushed changes.

It can manipulate workspace contents and use transient context relevant to the task but not part of the code, such as terminal output or machine state (processes, disk, etc.), or leverage locally installed tools. Additionally, these extensions can utilize capabilities from other extensions to avoid reimplementing the same functionality.

Not only can these extensions act as any other IDE extension, but they can also transparently use Copilot's Gen AI capabilities without worrying about authentication, managing API calls, or interfacing with the UI. They integrate directly into the Copilot Chat canvas and can also be called from other IDE mechanisms like the command palette or the editor context menu.

In summary, if you want to augment developer capabilities by leveraging Gen AI with in-house knowledge or data, need to work with unfinished code, manipulate and transform the code in the workspace, or want to leverage the capabilities of the IDE, then you should opt for a client-side extension.

Currently, the only IDE that supports Copilot Extensions is Visual Studio Code.

GitHub Copilot VS Code extension running

Sometimes you will also hear the term Chat Participant instead of extension, which is the capability that allows extensions to interact with Copilot Chat.

Read more about Copilot extensibility in Visual Studio Code in GitHub Copilot extensibility in VS Code

Examples

Some examples of VS Code Copilot extensions

VS Code copilot extensions that interact with other extensions:

VS Code copilot extensions that levarage installed software:

Data Analysis for Copilot - This tool extends the LLM's capabilities by allowing it to run Python code for a wide range of computational tasks and data manipulations that it cannot perform directly. It is an example of an extension that integrates with Copilot and uses installed software to execute code.

VS Code copilot extensions that interact with internal resources:

  • MongoDB for VS Code - Besides the MongoDB capabilities, it also implements a Copilot chat participant that uses natural language to interact with your clusters and generate MongoDB-related code with GitHub Copilot Chat in VS Code.

Server-Side extensions

Server side, on the other hand, means your extension will execute on your own backend. When a user interacts with your extension in any of the Copilot Chat supported clients (IDEs, Github.com or GitHub Mobile app), the client will call GitHub API which in turn will call your extension. The data that you return will be sent back to the client (via GitHub) and presented to the user.

You have access to the identity of the user interacting with your extension, as well as a token you can use to make calls against Copilot Gen AI capabilities and/or any GitHub API call on behalf of the user to read/modify GitHub Data (as long as extension is allowed to make those calls and the user also has permissions on the underlying data).

The extension has no access to the user local data (the local workspace) and cannot make changes to it (even when called from an IDE). Currently, it cannot receive data from the client in the form of references, so the perfect use cases are when you don't need read or modify the local workspace, want a unified experience across all clients, and/or you need to access internal resources without opening them directly to the clients so data can be accessed by the extension without being concerned where the clients are connecting from.

As a feature that is currently in Technical Preview, it still has some limitations while it is maturing. They are fully usable though, which means it's a great time to experiment with them and provide feedback to the team.

example of the Docker extension running in github.com chat

Note: Currently not all clients support server-side extensions, but the list is growing, and the goal is to have a unified experience across all clients. (list of supported clients and IDEs)

Pros and Cons

Both options have advantages and disadvantages. You'll need to choose the one that makes the most sense given your requirements, and while some invariants will (most likely) never change, the gap between client-side and server-side will tend to disappear in the future.

Client-side Server-side
Pros Can read and manipulate local workspace Single implementation runs on any client where Copilot is supported (supported IDEs, GitHub.com)
Supports Slash Commands Can access internal resources with a centralized access and control policy
Can integrate with other installed extensions May access resources in a consistent fashion (e.g., GPUs) for all users
Can leverage local machine resources (disk content, CPU, hardware, network) Easier to implement access control to your own data
Can execute locally installed tools (e.g., compilers, linters)
Supports use of references
Easy to allow users to configure the extension individually or per repo
Support for voice interactions
Cons Requires a separate implementation for each client (currently only supported in VS Code) You need to provide compute resources to execute the extension
To access internal company resources, may require network connectivity (e.g., via proxy or VPN) Doesn't support Slash Commands (although you can implement then, there are no UI helpers for users like in VS and VS Code)
May need to implement authentication and authorization for accessing internal resources Currently no support for references
Cannot access local resources or unpushed state
Harder to support configuration per user or per repo

Getting Third Party extensions

You can see the list of publicly available server-side extensions in the GitHub Marketplace.

VS Code extensions are available on the VS Marketplace or directly in VS Code extensions section.

Thank you note

Special thanks to Mickey Gousset for the review and feedback on this post.

Next In Series

Next up: Creating a VS Code Client-Side Copilot Extension

You May Also Enjoy