cord.nvim and the question of what your editor tells Discord

The plugin drives a Rust server that talks to Discord

cord.nvim is a Discord Rich Presence plugin for Neovim, and the architecture is the first thing to understand. The Lua side is a plugin, and the work of talking to Discord is done by a separate server executable written in Rust, which the plugin drives over an IPC path.

That split exists for a reason that the README states plainly: the plugin does not require Rust to be installed on your machine. The server binary is fetched for you.

The repository reflects the split at the top level. There is a `lua/` directory for the plugin code, a `plugin/` directory for the Neovim plugin entry points, an `autoload/` directory, and a `src/` directory with the Rust sources, plus `build.rs` and a `Cargo.toml` and `Cargo.lock` describing the server. The Cargo manifest names the binary `cord`, with its entry point at `src/main.rs`:

[[bin]]
name = "cord"
path = "src/main.rs"

The `keywords` field in that manifest lists `discord-rpc`, `discord`, `rich-presence` and `neovim`, and the package is published on crates.io under the name `cord-nvim` at version 2.3.29, built with Rust edition 2024 and requiring rust-version 1.89.0.

For a reader deciding whether to install this, the presence of a native binary matters beyond the usual supply chain reasons. It is a process that runs alongside your editor, it needs a place on disk, and the README gives it a customisable IPC path, which implies a local socket or pipe between the two halves.

One connection to Discord, shared across every Neovim instance

Two features decide whether Cord feels smooth or feels like a stutter, and they are the same feature seen from two sides.

The first is that the plugin manages activities across all instances with a single connection to Discord. If you have three Neovim windows open, they do not each open a connection. One server process holds the connection and multiplexes the activities.

The second is that the architecture is rate-limit aware and event driven. Rich presence updates are not pushed on a timer regardless of whether anything changed. The FAQ entry the README links explains what happens when presence updates take a long time to appear in Discord, and the answer is that the design is built around Discord's rate limits rather than ignoring them.

This matters more than it sounds. Discord throttles presence updates, and a naive implementation that writes on every keystroke or every buffer change gets throttled, which then looks like the plugin is broken. An event driven design that reacts to meaningful changes, such as a file being opened or a project being switched, is both less noisy and less likely to hit a limit.

The plugin also reconnects automatically if the connection to Discord is lost, which is the failure mode you hit when Discord restarts, when you switch network, or when you suspend a laptop.

Presence strings are templates, and assets are per file type

The presence content is described as dynamic string templates with custom variables, and the assets are described as customizable for any file or buffer type.

So the presence line is not a fixed format. It is a template that gets filled with variables describing the current state, and you decide what those variables mean. The README also lists flexible configuration with a rich API, function-based fields, hooks, user commands and custom IPC paths, which is the vocabulary of a plugin that expects to be extended rather than merely configured.

The icon situation is unusually well covered. The README claims 140 plus icons for 200 plus file types and plugins, grouped into distinct themes and flavors. In practice this is the part that decides whether the presence is useful, because an icon that matches what you are actually editing is most of the value, and a generic icon is not much better than no icon.

The extension system is described as an extension system of its own, with many extensions out of the box, and the configuration wiki is linked separately from the README, which tells you the surface area is larger than the README covers.

It finds the project from VCS files instead of running git

One feature stands out among the list because it says something about how the plugin was written. Cord finds repositories and workspaces based on VCS files without relying on command-line tools.

The obvious implementation would be to shell out to `git` and ask it for the repository root. That approach costs a process spawn on every project change, breaks in environments where git is not on the path, and behaves differently inside containers, WSL and Snap sandboxes. Reading the VCS metadata directly avoids all three.

It is a small decision, and it is a good one, and it is also a hint about the rest of the codebase. The feature list mentions an async-first design with an async-aware configuration layer, which is the other structural choice worth knowing about. Anything that can block, such as talking to the server or resolving a project root, is pushed onto the async path so the editor stays responsive.

The idle handling is worth separate mention too. The plugin detects when you are idle and switches to the most recent active instance, which is a reasonable interpretation of presence. It is not a statement that you are away from the keyboard, which is a distinction worth keeping in mind if you care about what the presence says.

Installing with a plugin manager, and the one dependency that trips people up

The plugin loads with defaults, and calling `setup()` is optional, so the minimum installation is a single spec line. With lazy.nvim:

{
  'vyfor/cord.nvim'
}

With vim.pack, which the README marks as for version 0.12 and later:

vim.pack.add { 'https://github.com/vyfor/cord.nvim' }

There is a LuaRocks route through rocks.nvim, and a plain git clone for Vim packages, where the Unix path is:

git clone https://github.com/vyfor/cord.nvim ~/.local/share/nvim/site/pack/plugins/start/cord.nvim

Each of these has a configuration snippet attached, and the pattern in all of them is `require('cord').setup { ... }`, with the `opts` form for lazy.nvim. The README points at the wiki for the default configuration, so the values you would normally look for in a README are in a separate page.

The important note is the one flagged as important. Cord does not require Rust to be installed, but it does require the server executable to be present. By default the plugin fetches it from GitHub, which means a dependency on `curl`. The alternative is to build the server from source, and the README gives a command for that, `:Cord update install` to install from crates.io, with a second option for the source build mentioned just after.

If you use Nix, the repository has a `flake.nix` and a `flake.lock` and an `.envrc`, and cross-compilation for the released binaries is set up through `Cross.toml`.

Discord on Linux means more than the desktop app

The list of supported environments is longer than the usual one, and the extra entries are where most installation problems come from.

Cord works with different Discord setups: the Snap package, Flatpak, WSL, and even Discord running in a browser, each with a page in the wiki under special environments. It runs on Windows, Linux, macOS and FreeBSD.

That is not gratuitous. Each Discord packaging has a different sandbox and a different IPC story. Flatpak and Snap confine the application, so a local socket has to be arranged in a way the sandbox permits. WSL is a different operating system boundary from Windows, so the server binary and the Discord client may not even be on the same side of it. A browser based Discord has no local client to talk to at all, and the plugin documents how to work with that case.

The customisable IPC path is the escape hatch for all of these. When the default connection does not work in your environment, being able to point the plugin at a different socket or pipe is what makes the difference between a working setup and an afternoon of reading wiki pages.

The binary itself is cross compiled, and the `Cross.toml` file at the repository root is what drives that, which is how a single project ships binaries for Windows, Linux, macOS and FreeBSD.

Releases move quickly, and the licence is permissive

The tagged releases are v2.3.29 from 2026-08-08, v2.3.28 from 2026-08-07 and v2.3.27 from 2026-08-05, and the repository is not archived with the last push on 2026-08-16. The Cargo manifest version matches the newest tag at 2.3.29, so the release numbering is consistent between the plugin and the server binary.

The cadence is worth noting for a plugin that installs a native binary. Three releases in three days means the server and the Lua side are updated together, which is convenient, and it also means an update can change what your editor reports to Discord. The repository has a `.releaserc.js`, so the release process is automated rather than manual, and `doc/` and `CHANGELOG`-style release notes live in the tree.

The licence is Apache-2.0, stated in the Cargo manifest and in the LICENSE file, and the plugin is published on LuaRocks as well, with the homepage for the rock on luarocks.org.

One last thing to weigh before installing. Rich presence is a broadcast. The plugin can report the file you are editing, the project, and the plugin you are using, and it is designed to make that report detailed and attractive. That is the point of the tool and also the thing to think about before you turn it on in front of a screen share.

Editorial conclusion

cord.nvim suits a Neovim user who wants a presence that reflects the file, project and plugin they are actually working in, and who is comfortable with a companion server binary and an IPC path between the two. It is the wrong choice if you do not want your editing activity visible to your Discord contacts, or if you need the presence to be accurate while you are idle, since idle detection switches to the most recent active instance rather than reporting inactivity. Verify first that the server executable can be fetched, since the default path downloads it from GitHub and needs `curl`, and read the configuration wiki page, because the default configuration is documented there rather than in the README.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. vyfor/cord.nvim on GitHub