GitHub Copilot Extensions
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.
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:
- copilot-pg - An experimental chat participant that uses Copilot to query your PostgreSQL database.
- vscode-mssql-chat - Get answers about your SQL tables when using Copilot Chat with the MS SQL extension. This extension uses the database functionality from SQL Server extension for Visual Studio Code (although it requires a patched version)
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.
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.