LSP-copilot: GitHub Copilot inside Sublime Text's LSP plugin

Copilot as another language server

LSP-copilot provides GitHub Copilot support for the Sublime Text LSP plugin, and it does so through the official Copilot language server package, @github/copilot-language-server, which is distributed on npm. The plugin description in the repository metadata calls it support provided through Copilot.vim, and the README makes the same point about the distribution it uses.

The mechanism is worth being precise about, because it determines everything else about how the plugin behaves. Copilot is not embedded in the editor as a proprietary binary with its own key handling. It is a language server that the LSP plugin starts and talks to, over the same LSP machinery the plugin already uses for completion of every other language. The Copilot distribution that this uses runs on OpenAI Codex to suggest code and entire functions in real time, in the editor.

The user facing surface has four parts, and the README lists all four as shipped features. There is an inline completion popup, which is the conventional suggestion box. There is an inline completion phantom, which is the grey inline text you can cycle through. There is a panel completion, which puts the suggestion in a panel rather than a popup. And there is a chat, which is a conversation view.

The two prerequisites are short and hard: a public network connection and an active GitHub Copilot subscription. There is no offline mode and no alternative model, which is worth stating plainly to anyone evaluating the plugin for a restricted network.

One piece of lineage is visible in the README. The screenshot images and the issue links for the phantom completion point at a repository under TheSecEng, which is the upstream project this one appears to track, while the package is published as LSP-copilot for Sublime Text users.

Installing the plugin and signing in from the editor

Installation is two steps through Package Control, the package manager for Sublime Text.

You install LSP and LSP-copilot via Package Control, and then you restart Sublime Text. Both packages are listed on Package Control, and the LSP plugin is the host that the Copilot plugin plugs into, so the order matters: the host has to be there first.

The first run has a sign in flow, and it is deliberately browser based rather than a token you paste into a settings file.

You open any file, execute the Copilot: Sign In command from the command palette, and follow the prompts to authenticate. The User Code is copied to your clipboard automatically, you paste that code into the pop-up GitHub authentication page, then you return to Sublime Text and press OK on the dialog. If a sign in OK dialog appears, LSP-copilot should start working from that point.

The copy to clipboard step is a small ergonomic detail that removes a class of friction, since a device code flow normally asks you to select and copy a string from a dialog, and misreading a character is a common failure. The command palette entry is the only piece of the interface you need to know, and it is named consistently with the other Sublime Text commands.

The settings that follow the sign in are equally short to reach. They live in the LSP-copilot.sublime-settings file, and the Preferences: LSP-copilot Settings command in the command palette opens it.

The settings decide how often it asks and what it reports

The settings table is the most informative part of the README, because it shows the plugin's defaults and, in two cases, admits where the author is not sure.

auto_ask_completions is a boolean that defaults to true, and it decides whether the server is asked for completions automatically or whether you have to trigger them manually. hook_to_auto_complete_command does the narrower version of the same thing, asking the server for completions when the auto_complete command is called. The first is the one that changes how the editor feels day to day, since with it on the request goes out without you asking and with it off you are in control of every request.

telemetry is a boolean that defaults to false, and it enables Copilot telemetry requests for Accept and Reject completions. That is, the plugin can report which suggestions you accepted and which you rejected, and it is off by default. Whether that matters depends on your organisation, but the setting is the one to look at first if code is sensitive.

local_checks is a boolean that defaults to false and enables local checks, and the description says this feature is not fully understood yet. That is an unusual line in a settings table, and it is worth treating as a warning: the setting exists, the author says the behaviour behind it is not fully understood, and it is off.

completion_style is a string that defaults to popup, with phantom described as experimental and carrying a link to known issues. The other values in the table are debug, which enables debug mode and enables all commands regardless of status requirements, authProvider, a string for the GitHub identity to use for Copilot, github-enterprise, an object for the configuration for GitHub Enterprise, and proxy, a string for the HTTP proxy to use for Copilot requests, in the form of username:password@host:port or just host:port.

The Tab key fight, and the certificate error behind a proxy

Two problems in the FAQ are worth reading closely, because both are the kind of issue that looks like a broken plugin when it is not.

The first is the Tab key. If you do not want to use Tab for committing the Copilot completion, the reason is that the Copilot completion is likely to appear alongside the Sublime Text autocompletion, and both of them use Tab for committing the completion, which may cause a nondeterministic result. The advice is to let only one of them, or none, use the Tab key. To stop LSP-copilot from using it, you set the commit_completion_on_tab setting to false and add a custom keybinding.

{
    "keys": ["YOUR_OWN_DEDICATE_KEYBINDING"],
    "command": "copilot_accept_completion",
    "context": [
        {
            "key": "copilot.is_on_completion"
        }
    ]
},

The context key is the interesting part. The binding only fires when a Copilot completion is on screen, so the key does something different depending on the editor state, which is how it avoids stealing the key from the ordinary autocompletion.

The second is the certificate error. If you are working behind a VPN or a proxy, you may be required to add your CA file into the Node environment, and the error you see is UNABLE_TO_GET_ISSUER_CERT_LOCALLY. The fix is an env key in the plugin settings.

{
  "env": {
      "NODE_EXTRA_CA_CERTS": "/path/to/certificate.crt",
  },
  // other custom settings...
}

That is a Node specific environment variable, which makes sense once you know the Copilot language server is a Node program. The practical sequence for a corporate network is therefore: set the proxy setting, set the CA certificate path, and only then start debugging why completions are not arriving.

The Python side: uv, two type checkers, and a strict lint

The plugin code is Python, and the tooling around it is unusually complete for a Sublime Text plugin, which is a sign of a project that takes maintenance seriously.

The build is driven by uv, and the Makefile exposes the whole workflow. The install targets are uv sync with the dev group, without dev, and with all groups, plus an upgrade target that adds the upgrade flag. The continuous integration checks are run through uv run --dev and consist of three steps: mypy over the plugin package, ruff check in diff mode, and ruff format in diff mode, with a fix target and an unsafe fix target for the same three.

install-all:
	uv sync --all-groups

ci-check:
	@echo "========== check: mypy =========="
	$(ci-base-cmd) mypy -p plugin

The project metadata is specific about the supported floor, with requires-python of 3.8 or newer, and the type checking configuration is pinned to the same version, mypy with python_version 3.8 and pyright with pythonVersion 3.8. Both checkers run, which is unusual and deliberate: two checkers catch different things, and the configuration shows that the author expects them to agree.

The mypy configuration enables check_untyped_defs and strict_optional, and it has an overrides block that turns off error checking and missing import errors for the Sublime Text API modules, among them LSP.*, lsp_utils.*, mdpopups.*, and sublime_lib.*, plus a local typings directory that supplies stubs for them. That is the right way to handle an editor API that has no published type information, and the typings directory in the repository is where those stubs live.

The runtime dependencies are small and unsurprising: jinja2 for templating, jmespath for querying the JSON payloads that language servers send, more-itertools, requests for HTTP, typing-extensions, watchfiles for file system watching, and wcmatch for glob matching. The last two are what make a plugin that watches your project and filters files by pattern practical.

The ruff configuration is strict in a way that shows taste rather than caution. It runs in preview mode, with a line length of 120, and it selects a broad rule set including the pyupgrade rules and the refurb rules, with the isort configuration requiring from __future__ import annotations in every file, which is exactly what you want in a project that supports Python 3.8.

Editorial conclusion

LSP-copilot fits a Sublime Text user with an active GitHub Copilot subscription who wants assistant completions inside the editor they already use, and who is prepared to give up the Tab key to the plugin or to rebind it. It does not fit a user without a Copilot subscription, a user on a network that blocks the service, or a team with a policy against sending code to a hosted assistant without a proxy that is configured. Verify first that the Copilot language server package is reachable from your machine, that your proxy setting and any CA certificate are in place before you start debugging completions, and that the telemetry setting matches what you are willing to report about the completions you accept and reject.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. sublimelsp/LSP-copilot on GitHub