├── .github ├── CODEOWNERS ├── bug_report.md └── config.yml ├── CODE_OF_CONDUCT.md ├── LICENSE ├── README.md ├── SECURITY.md └── SUPPORT.md /.github/CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @github/copilot-editor-team 2 | -------------------------------------------------------------------------------- /.github/bug_report.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: Bug report for GitHub Copilot Language Server 3 | about: Create a report to help us improve the Copilot Language Server 4 | --- 5 | 6 | 7 | 8 | 9 | - Copilot Language Server Version: 10 | - OS Version: 11 | - Logs: 12 | 13 | Steps to Reproduce: 14 | 15 | 1. 16 | 2. 17 | -------------------------------------------------------------------------------- /.github/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled: false 2 | contact_links: 3 | - name: Questions for Copilot extensions 4 | url: https://github.com/orgs/community/discussions/categories/copilot 5 | about: Please ask and answer questions about using GitHub Copilot here 6 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, gender identity and expression, level of experience, 9 | nationality, personal appearance, race, religion, or sexual identity and 10 | orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at . All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at [http://contributor-covenant.org/version/1/4][version] 72 | 73 | [homepage]: http://contributor-covenant.org 74 | [version]: http://contributor-covenant.org/version/1/4/ 75 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2025 GitHub 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # @github/copilot-language-server 2 | 3 | The Copilot Language Server enables any editor or IDE to integrate with GitHub 4 | Copilot via [the language server protocol](https://microsoft.github.io/language-server-protocol/). 5 | 6 | **[GitHub Copilot](https://github.com/features/copilot)** is an AI pair programmer tool that helps you write code faster and smarter. 7 | 8 | **Sign up for [GitHub Copilot Free](https://github.com/settings/copilot)!** 9 | 10 | Please see [terms of use for GitHub Copilot](https://docs.github.com/en/site-policy/github-terms/github-terms-for-additional-products-and-features#github-copilot) 11 | 12 | ## Getting Started 13 | 14 | To integrate with the Copilot Language Server, download the latest release from npm: 15 | 16 | ```sh 17 | npm install @github/copilot-language-server 18 | ``` 19 | 20 | To run the language server, platform-specific binaries are available in the `native` directory of the npm package. For 21 | example, for macOS on arm64: 22 | 23 | ```sh 24 | ./node_modules/@github/copilot-language-server/native/darwin-arm64/copilot-language-server --version 25 | ``` 26 | 27 | Or you can use [Node.js](https://nodejs.org/en/download/) version 20.8 or later: 28 | 29 | ```sh 30 | node ./node_modules/@github/copilot-language-server/dist/language-server.js --version 31 | ``` 32 | 33 | If using the `language-server.js` distribution, it is necessary to retain the entire `dist` directory contents. 34 | 35 | Communication with the language server typically happens over stdio with `--stdio`. The `language-server.js` 36 | distribution additionally supports Node IPC with `--node-ipc`. 37 | 38 | ## Communication Protocol 39 | 40 | The [Language Server Protocol](https://microsoft.github.io/language-server-protocol/) (LSP) is used to communicate with 41 | the client. The base protocol is [JSON-RPC 2.0 with additional 42 | headers](https://microsoft.github.io/language-server-protocol/specifications/specification-current/#baseProtocol). 43 | 44 | The Copilot Language Server attempts to follow the LSP spec as closely as possible, but many custom messages are 45 | employed to support the unique features of Copilot. 46 | 47 | ## Initialization 48 | 49 | Per the LSP spec, the client is expected to send a 50 | [`initialize`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialize) 51 | request to the language server as a first message. Example parameters: 52 | 53 | ```json 54 | { 55 | "processId": 1234, 56 | "workspaceFolders": [ 57 | { 58 | "uri": "file:///home/user/project" 59 | } 60 | ], 61 | "capabilities": { 62 | "workspace": {"workspaceFolders": true} 63 | }, 64 | "initializationOptions": { 65 | "editorInfo": { 66 | "name": "GNU ed", 67 | "version": "1.19" 68 | }, 69 | "editorPluginInfo": { 70 | "name": "GitHub Copilot for ed", 71 | "version": "1.0.0" 72 | } 73 | } 74 | } 75 | ``` 76 | 77 | After receiving the response to `initialize`, the second message the client must send is an 78 | [`initialized`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#initialized) 79 | notification. 80 | 81 | ## Configuration Management 82 | 83 | After initialization, clients should send a 84 | [`workspace/didChangeConfiguration`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_didChangeConfiguration) 85 | notification to inform the language server about the initial configuration, and again each time the configuration 86 | changes. Example parameters: 87 | 88 | ```json 89 | { 90 | "settings": { 91 | "http": { 92 | "proxy": "http://localhost:8888", 93 | "proxyStrictSSL": true, 94 | "proxyKerberosServicePrincipal": "spn" 95 | }, 96 | "telemetry": { 97 | "telemetryLevel": "all" 98 | }, 99 | "github-enterprise": { 100 | "uri": "https://example.ghe.com" 101 | } 102 | } 103 | } 104 | ``` 105 | 106 | Pull based configuration on 107 | [`workspace/configuration`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_configuration) 108 | is also supported. 109 | 110 | ## Workspace Folders Synchronization 111 | 112 | Workspace folders are optional but highly recommended as they greatly improve the quality of suggestions. See the LSP spec for 113 | [`workspace/didChangeWorkspaceFolders`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_didChangeWorkspaceFolders). 114 | 115 | ## Text Document Synchronization 116 | 117 | Per the LSP spec for 118 | [text document synchronization](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_synchronization), 119 | support for `textDocument/didOpen`, `textDocument/didChange`, and `textDocument/didClose` is required, using incremental 120 | sync. 121 | 122 | ## Text Document Focusing 123 | 124 | Additionally a custom `textDocument/didFocus` notification should be sent when the client focuses another document 125 | (e.g., changing tabs). Example parameters: 126 | 127 | ```json 128 | { 129 | "textDocument": { 130 | "uri": "file:///path/to/file" 131 | } 132 | } 133 | ``` 134 | 135 | If no document is focused, a request with no parameters (`{}`) may be sent. 136 | 137 | ## Status Notification 138 | 139 | The status is sent to the client as a `didChangeStatus` notification. Typically this would be conveyed to the user in a 140 | status bar icon or other UI affordance. 141 | 142 | Notification includes the following fields: 143 | 144 | - `message` - a string describing the status (can be empty) 145 | - `kind` - status of the language server: 146 | - `'Normal'` - When everything is working normally. 147 | - `'Error'` - When not authorized and authenticated. 148 | - `'Warning'` - When there is a temporary issue, such as a failed HTTP request. 149 | - `'Inactive'` - When the current file is ignored due to file size or content exclusions. 150 | 151 | ## Authentication 152 | 153 | To sign in, call `signIn`. This will return a response like the following: 154 | 155 | ```json 156 | { 157 | "userCode": "ABCD-EFGH", 158 | "command": { 159 | "command": "github.copilot.finishDeviceFlow", 160 | "arguments": [], 161 | "title": "Sign in" 162 | } 163 | } 164 | ``` 165 | 166 | Instruct the user to copy the `userCode` to their clipboard (and/or copy it programmatically). When the user is ready, invoke 167 | [`workspace/executeCommand`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_executeCommand) 168 | to execute the `command`. This will open a browser window that walks the user through the authentication process. 169 | Shortly (up to 10 seconds) after the user finishes signing in, you should see a status notification reflecting the new 170 | state. 171 | 172 | If available, the language server will use 173 | [`window/showDocument`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#window_showDocument) 174 | to open the URL. Otherwise, it will attempt to open the URL natively (e.g., with `/usr/bin/open` on macOS). 175 | 176 | To sign out, call `signOut`. 177 | 178 | ## Inline Completions 179 | 180 | The [`textDocument/inlineCompletion`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#textDocument_inlineCompletion) 181 | request from the draft version of the next LSP spec is used to retrieve inline ("ghost text") completions, with some 182 | non-standard additions (`textDocument.version` and `formattingOptions`) to the parameters: 183 | 184 | ```json 185 | { 186 | "textDocument": { 187 | "uri": "file:///path/to/file", 188 | "version": 0 189 | }, 190 | "position": {"line": 1, "character": 2}, 191 | "context": { 192 | "triggerKind": 2 193 | }, 194 | "formattingOptions": { 195 | "tabSize": 4, 196 | "insertSpaces": true 197 | } 198 | } 199 | ``` 200 | 201 | The result is an object containing an `items` array. 202 | 203 | ```json 204 | { 205 | "items": [ 206 | { 207 | "insertText": "a helpful suggestion", 208 | "range": { 209 | "start": {"line": 1, "character": 0}, 210 | "end": {"line": 1, "character": 2} 211 | }, 212 | "command": { 213 | "command": "github.copilot.didAcceptCompletionItem", 214 | "arguments": ["some id"] 215 | } 216 | } 217 | ] 218 | } 219 | ``` 220 | 221 | Newlines in `insertText` should be normalized as is appropriate for the editor before inserting into the document. 222 | 223 | The `command` field, per the LSP spec, is called via 224 | [`workspace/executeCommand`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_executeCommand) 225 | *after* the user accepts the completion. Copilot uses this for acceptance telemetry. 226 | 227 | The LSP spec does not provide an event for showing the completion, so a custom `textDocument/didShowCompletion` is used. 228 | Call it with an `item` parameter containing the full completion item: 229 | 230 | ```json 231 | { 232 | "item": { 233 | "insertText": "a helpful suggestion", 234 | "range": { 235 | "start": {"line": 1, "character": 0}, 236 | "end": {"line": 1, "character": 2} 237 | }, 238 | "command": { 239 | "command": "github.copilot.didAcceptCompletionItem", 240 | "arguments": ["some id"] 241 | } 242 | } 243 | } 244 | ``` 245 | 246 | Similarly, for partial acceptance, send a `textDocument/didPartiallyAcceptCompletion` notification with the full 247 | item, plus the length (in UTF-16 codepoints) of the completion that was accepted: 248 | 249 | ```json 250 | { 251 | "item": { 252 | "insertText": "a helpful suggestion", 253 | "range": { 254 | "start": {"line": 1, "character": 0}, 255 | "end": {"line": 1, "character": 2} 256 | }, 257 | "command": { 258 | "command": "github.copilot.didAcceptCompletionItem", 259 | "arguments": ["some id"] 260 | } 261 | }, 262 | "acceptedLength": 9 263 | } 264 | ``` 265 | 266 | Note that the `acceptedLength` includes everything from the start of `insertText` to the end of the accepted text. It is 267 | *not* the length of the accepted text itself. 268 | 269 | ## Panel Completions 270 | 271 | Panel completions are used for "Open Copilot" style completions. They are similar to inline completions, but are shown 272 | in a separate panel. They are retrieved using the custom `textDocument/copilotPanelCompletion` request, which has 273 | parameters closely modeled after `textDocument/inlineCompletion`: 274 | 275 | ```json 276 | { 277 | "textDocument": { 278 | "uri": "file:///path/to/file", 279 | "version": 0 280 | }, 281 | "position": {"line": 1, "character": 2}, 282 | "partialResultToken": "some token" 283 | } 284 | ``` 285 | 286 | If provided, the `partialResultToken` is used to stream 287 | [partial results](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#partialResults) 288 | back to the client. Both the return type and the partial result type are the same as for inline completions: an object 289 | containing an `items` array. These items have the same `command` that must be invoked with `workspace/executeCommand` 290 | after accepting to trigger acceptance telemetry. Partial acceptance and shown events are not supported here. 291 | 292 | ## Cancellation 293 | 294 | `textDocument/inlineCompletion` supports cancel-previous strategy for cancellation: If you send new completions 295 | request, the previous request is cancelled. 296 | 297 | Additionally the LSP `$/cancelRequest` method is supported to cancel any request. It is strongly encouraged to eagerly 298 | cancel completion requests as soon as possible. 299 | 300 | ## Logs 301 | 302 | Logs are sent to the client as 303 | [`window/logMessage`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#window_logMessage) 304 | notifications. 305 | 306 | ## Messages 307 | 308 | The client may be sent 309 | [`window/showMessageRequest`](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#window_showMessage) 310 | requests. Support for these messages is essential as they are used for important notifications including account and 311 | billing. 312 | -------------------------------------------------------------------------------- /SECURITY.md: -------------------------------------------------------------------------------- 1 | Thanks for helping make GitHub safe for everyone. 2 | 3 | # Security 4 | 5 | GitHub takes the security of our software products and services seriously, including all of the open source code repositories managed through our GitHub organizations, such as [GitHub](https://github.com/GitHub). 6 | 7 | Even though [open source repositories are outside of the scope of our bug bounty program](https://bounty.github.com/index.html#scope) and therefore not eligible for bounty rewards, we will ensure that your finding gets passed along to the appropriate maintainers for remediation. 8 | 9 | ## Reporting Security Issues 10 | 11 | If you believe you have found a security vulnerability in any GitHub-owned repository, please report it to us through coordinated disclosure. 12 | 13 | **Please do not report security vulnerabilities through public GitHub issues, discussions, or pull requests.** 14 | 15 | Instead, please send an email to opensource-security[@]github.com. 16 | 17 | Please include as much of the information listed below as you can to help us better understand and resolve the issue: 18 | 19 | * The type of issue (e.g., buffer overflow, SQL injection, or cross-site scripting) 20 | * Full paths of source file(s) related to the manifestation of the issue 21 | * The location of the affected source code (tag/branch/commit or direct URL) 22 | * Any special configuration required to reproduce the issue 23 | * Step-by-step instructions to reproduce the issue 24 | * Proof-of-concept or exploit code (if possible) 25 | * Impact of the issue, including how an attacker might exploit the issue 26 | 27 | This information will help us triage your report more quickly. 28 | 29 | ## Policy 30 | 31 | See [GitHub's Safe Harbor Policy](https://docs.github.com/en/site-policy/security-policies/github-bug-bounty-program-legal-safe-harbor#1-safe-harbor-terms) 32 | -------------------------------------------------------------------------------- /SUPPORT.md: -------------------------------------------------------------------------------- 1 | # Support 2 | 3 | ## How to file issues and get help 4 | 5 | This project uses GitHub issues to track bugs and feature requests. Please search the existing issues before filing new issues to avoid duplicates. For new issues, file your bug or feature request as a new issue. 6 | 7 | For help or questions about using GitHub Copilot, please see https://github.com/orgs/community/discussions/categories/copilot 8 | 9 | - The GitHub Copilot Language Server is under active development and maintained by GitHub staff. We will do our best to respond to support, feature requests, and community questions in a timely manner. 10 | 11 | ## GitHub Support Policy 12 | 13 | Support for this project is limited to the resources listed above. 14 | --------------------------------------------------------------------------------