# sg.nvim: an experimental Neovim bridge to Sourcegraph and Cody

> sg.nvim is a Neovim plugin that pulls Sourcegraph code search and Cody chat and completion into the editor, with a Rust core behind the Lua plugin. The README states plainly that the plugin is experimental and not actively being maintained, which is the first thing to weigh before installing it.

**sourcegraph/sg.nvim** — Experimental Sourcegraph + Cody plugin for Neovim

- Repository: https://github.com/sourcegraph/sg.nvim
- Stars: 778 · Forks: 51
- Language: Lua
- License: Apache-2.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/sourcegraph-sg-nvim

## The README opens by calling the plugin unmaintained

The first thing in the sg.nvim README is a callout box that says the plugin is currently experimental and is not actively being maintained. Everything else in the document reads like the notes of a project that works but is not being carried forward.

The version history supports that reading. The most recent GitHub release is v1.1.0 from 2024-03-12, preceded by v1.0.8 and v1.0.7, both dated 2024-01-12. The last push to the repository was on 2026-09-16, so the code still receives commits, but those commits have not produced a tagged release in more than two years.

That combination matters when you plan the adoption. A plugin you install once and never touch will be fine. A plugin your team's dotfiles depend on, or a plugin you intend to file issues against and wait for a fix, is a different proposition. The pragmatic use for sg.nvim today is a personal tool that you can fork and patch yourself.

What the plugin does is worth stating, because it is more than a search wrapper. The README describes it as focused on bringing many of the features of sourcegraph.com and Cody into Neovim, and the feature list is concrete: a chat interface with associated commands, prompted and suggested autocompletions, reading files from Sourcegraph links and from buffer names in a custom scheme, folder expansion and collapsing, a built-in LSP client connected to Sourcegraph, and search with literal, regexp and structural support.

## Three login paths, including environment variables for enterprise instances

Authentication offers three routes, and the third is the one that matters for self-hosted Sourcegraph.

The first is `:SourcegraphLogin`, which follows the installation instructions for sourcegraph.com usage. The second is `:SourcegraphLogin!`, which prompts for an endpoint and an access token to be stored. The third is to manage tokens yourself with the `SRC_ENDPOINT` and `SRC_ACCESS_TOKEN` environment variables, which the README recommends for enterprise usage and points at the src-cli documentation for details on logging into a Sourcegraph instance.

That design choice is a good sign for anyone running their own Sourcegraph. Credentials can come from the environment rather than being entered in the editor, which is closer to how a CI job or a remote machine would supply them, and it means the plugin does not need its own credential store for that case.

The README also says the plugin ships a `:help sg.auth` topic with more information, and that you can check your login state by running `:checkhealth sg`. That health check is the first thing to run after installation, and it is the quickest way to tell whether the plugin can reach your Sourcegraph instance and whether the runtime dependencies are present.

The repository's `Cargo.toml` shows the credential and networking stack in use: the `keyring` crate at version 2.1.0 for system keychain access, `whoami` at version 1.4.1 for identity, `reqwest` with `native-tls-vendored` for HTTP, and `graphql_client` for talking to the Sourcegraph GraphQL API.

## A Rust core sits under the Lua plugin, and cargo-dist ships the binaries

Despite the Lua file layout, this is not a pure Lua plugin. The repository contains a Cargo workspace with a `Cargo.toml`, a `Cargo.lock`, a `rust-toolchain.toml`, a `rustfmt.toml` and a `crates/` directory, and the top-level entries include `src/`, `lua/`, `plugin/`, `build/`, `dist/` and `scripts/`.

The workspace root package is named `sg` and the internal crates are `sg-gql`, `sg-types` and `jsonrpc`, the last of which confirms that the plugin speaks JSON-RPC, which is how it connects to Sourcegraph through the built-in LSP client.

```toml
[package]
name = "sg"
version.workspace = true
edition.workspace = true
repository = "https://github.com/sourcegraph/sg.nvim"
```

The dependency list also includes the `gix` crate at version 0.66.0 for Git repository access, `lsp-server` at version 0.7.2 and `lsp-types` at version 0.94.0 for the language server side, `tiny_http` for a local HTTP server, and `regex` at version 1.9.1 for the literal and regexp search support the feature list advertises.

Distribution is handled by cargo dist. The workspace metadata names the installers, sets the target platforms, and lists the Rust target triples the project builds for: `aarch64-unknown-linux-gnu`, `x86_64-unknown-linux-gnu`, `aarch64-apple-darwin`, `x86_64-apple-darwin` and `x86_64-pc-windows-msvc`. The README explains the practical consequence: by default sg.nvim downloads released binaries from GitHub, and building the plugin yourself requires `cargo`.

That is why the install snippets for every plugin manager include a build step. lazy.nvim runs `nvim -l build/init.lua`, and the vim-plug snippet uses the same command as its `do` action.

## Installing means a plugin manager, a build step and a mandatory setup call

The installation section states one requirement that is easy to miss: regardless of the installation method, you must call `require("sg").setup { ... }` in your config. The plugin does not work merely by being present.

For lazy.nvim, the README's snippet looks like this.

```lua
-- Use your favorite package manager to install, for example in lazy.nvim
--  Optionally, you can also install nvim-telescope/telescope.nvim to use some search functionality.
return {
  {
    "sourcegraph/sg.nvim",
    dependencies = { "nvim-lua/plenary.nvim", --[[ "nvim-telescope/telescope.nvim ]] },

    -- If you have a recent version of lazy.nvim, you don't need to add this!
    build = "nvim -l build/init.lua",
  },
}
```

The same shape appears for packer.nvim and vim-plug, with the same `nvim -l build/init.lua` step, and plenary.nvim listed as a dependency in every variant because the plugin uses it for some features. Telescope is optional and only used for the search functionality.

The runtime requirements are nvim 0.9 or nvim nightly, and Node.js 18.17.0 or newer on the machine at runtime, because the plugin runs `cody-agent.js` from the sourcegraph/cody repository. Node being a runtime requirement for an editor plugin is unusual, and it is the one dependency that most often decides whether a given machine can use the plugin at all.

After installing, run `:checkhealth sg`.

## Completion works only with nvim-cmp, and several features are unfinished

The feature checklist in the README is the most honest part of the document, because the unchecked boxes are visible. Autocompletion currently supports nvim-cmp only, and the README asks you to open an issue if you want another completion source added. That is a hard coupling: the Cody completion features are unavailable if your editor setup uses a different completion engine.

The Sourcegraph browsing side is more complete but still partial. Reading files works from Sourcegraph links with `:edit <sourcegraph url>`, with the plugin adding protocols for `https://sourcegraph.com/*` links, and from buffer names in a custom scheme such as `:edit sg://github.com/tjdevries/sam.py/-/src/sam.py`. There is a `:SourcegraphLink` command to get a link for the location under the cursor. Folders can be expanded and collapsed and files opened from a folder, while repository roots are listed but not marked done.

The LSP integration is the sharpest limitation. Goto definition is supported, but goto references is not, with the only completed item being a note that it works for fewer than twenty references. Search supports literal, regexp and structural search, along with `type:symbol`, while repository level search is left unfinished.

The configuration is thin. The `on_attach` option takes your own custom attach function, and if you do not pass one, the plugin provides default mappings of `gd` for goto definition and `gr` for goto references. Telescope integration is a separate mapping, as shown in the README.

```vim
" Example mapping for doing searches from within neovim (may change) using telescope.
" (requires telescope.nvim to be installed)
nnoremap <space>ss <cmd>lua require('sg.extensions.telescope').fuzzy_search_results()<CR>
```

## Nix packaging needs a cpath fix and a maintained flake

The plugin is packaged as a Nix flake, and the README's Nix section shows a configuration that appends the package's shared object directory to `package.cpath`, which is the part that makes the Rust binary loadable from the Lua side.

```nix
sg = let
  system = "x86_64-linux";
  package = inputs.sg-nvim.packages.${system}.default;
in {
  inherit package;
  init = pkgs.writeTextFile {
    name = "sg.lua";
    text = ''
      return function()
        package.cpath = package.cpath .. ";" .. "${package}/lib/?.so"
      end
    '';
  };
};
```

The snippet is written for a single system, `x86_64-linux`, while the cargo dist configuration builds for five target triples including Apple targets and Windows, so a NixOS user on a Mac is not covered by the example as written. The README also notes that the package is consumed as a normal flake, and it asks Nix contributors to run `nix flake update` periodically to keep `flake.lock` current, which is a hint about how much attention that part of the project gets.

Two further items sit in an unchecked list in that section: a minimal sg.nvim integrated Neovim package for testing and example, and integration of sg.nvim and Cody into the nixpkgs vimPlugins set. Both are pending, so a Nix user today is assembling the package themselves rather than installing a supported one.

For developers, the README shows how to point a plugin manager at a local checkout with a `dir` key and how to switch between the local directory and the GitHub source using the `SG_NVIM_DEV` environment variable, so working on the plugin is a matter of running the local build rather than a released binary.

## Conclusion

Adopt sg.nvim if you want cross-repository Sourcegraph navigation and Cody completion inside Neovim today and you are willing to own the plugin. Do not adopt it as a dependency of anything you cannot rebuild yourself: the README states the plugin is experimental and not actively being maintained, and the last published release is v1.1.0 from 2024-03-12 even though the last push to the repository was on 2026-09-16. Before installing, check that your Neovim is 0.9 or newer, that Node.js 18.17.0 or newer is on PATH for cody-agent.js, and that the feature you actually need is checked off in the README, since goto references is limited to fewer than twenty references and repository level search is marked unfinished.

## FAQ

### Is sg.nvim still maintained?

The README states that the plugin is currently experimental and is not actively being maintained. The last published release is v1.1.0 from 2024-03-12, while the last push to the repository was on 2026-09-16.

### What do I need installed to run sg.nvim?

The README requires nvim 0.9 or nvim nightly, Node.js 18.17.0 or newer at runtime for `cody-agent.js`, and plenary.nvim, with telescope.nvim optional for search functionality. You must also call `require("sg").setup { ... }` in your configuration.

### How do I authenticate sg.nvim against a self-hosted Sourcegraph?

You can set the `SRC_ENDPOINT` and `SRC_ACCESS_TOKEN` environment variables, which the README recommends for enterprise usage, or run `:SourcegraphLogin!` and provide an endpoint and access token to be stored. `:checkhealth sg` shows whether the login works.

## Sources

- [Issues](https://github.com/sourcegraph/sg.nvim/issues)
- [License: Apache-2.0](https://github.com/sourcegraph/sg.nvim/blob/master/LICENSE)
- [README](https://github.com/sourcegraph/sg.nvim/blob/master/README.md)
- [Releases](https://github.com/sourcegraph/sg.nvim/releases)
- [sourcegraph/sg.nvim on GitHub](https://github.com/sourcegraph/sg.nvim)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sourcegraph-sg-nvim