vscord: Discord Rich Presence for VS Code that you configure down to the variable

Presence for the file, the project and the branch you are in

vscord is a Discord Rich Presence extension for Visual Studio Code, and the feature list describes what it does in plain terms: it shows what you are working on.

The presence itself is assembled from the editor's own state, and the extension is careful about the details that make a status look right rather than generic. You can switch between five editor names, Code, Visual Studio Code, VSCodium, Antigravity and Cursor, or supply a custom one, which matters because the editor you run is often not the one people assume you run. The extension detects when you are debugging, detects when you are on the Insiders build, and detects when you are idling, so the status can change to match what is really happening in the editor rather than only naming a file.

The scale of the customisation is the other half of the pitch. There are more than 60 extension settings, a large number of variables you can use in your strings, support for over 130 of the most popular languages, custom images through an HTTP link, and a custom button link, which is how a presence points at a page of your choosing.

The language support has its own guide in the repository, in a file called ADDING_LANGUAGE.md, so the 130 languages are not a fixed promise but a list the project expects to keep extending.

The variable table is where the customisation actually lives

The configuration section is a table of variables that get replaced with the corresponding value in your custom strings, and it is the most useful part of the documentation.

The file and path variables cover {file_name}, {file_extension}, {file_size}, {folder_and_file}, {relative_file_path} for a path relative to the workspace folder, {directory_name} and {full_directory_name}. The workspace variables are {workspace}, {workspace_folder} and {workspace_and_folder}. The editor itself is {app_name}, and {app_id} is an editor name shaped for use inside a URL, which is what you need if the image or the button points at a link built from the editor name.

The language variables are worth a second look, because they handle the awkwardness of English articles. {lang}, {Lang} and {LANG} give the language name in lower case, capitalised and upper case, and {a_lang}, {a_Lang} and {a_LANG} give the same thing prefixed with a or an, so the string can read a Python file instead of the file Python.

The problem counters are the part that turns a status into a dashboard. {problems} is the problems text defined in the settings, {problems_pluralize} is the word problem pluralized by count, and there are separate counters for the total, the errors, the warnings, the infos and the hints. {line_count}, {current_line} and {current_column} cover the cursor.

The git variables are the largest group, and they cover everything from a readable branch name to a clickable link: {git_owner}, {git_repo}, {git_branch}, {git_protocol}, {git_resource} for a link such as github.com without the port, {git_host} for the same thing including the port, {git_port}, {git_href} and {git_url}. {git_resource} and {git_host} are separated so that a remote on a non standard port still produces a working link.

And there is {empty}, which is an empty space, for when you want a separator that collapses instead of leaving a gap.

Installing it, and the one build it refuses to run on

Installation takes one of two routes. You can open the VS Code Quick Open palette with Ctrl+P, paste the command and press enter:

ext install LeonardSSH.vscord

Or you install it from the Extension Marketplace, which is where most people will end up, since the extension is published as LeonardSSH.vscord and is also listed on Open VSX under the same identifier for editors that use that registry.

There is a disclaimer at the top of the documentation, and it is a real constraint rather than a formality. The extension does not work with the snap store or Flatpak version of VS Code, and the instruction is to use the official version from the VS Code website. The reason is structural: Rich Presence reaches the Discord client through a local interface, and the sandboxing in those packaged builds stands in the way.

The feature list also mentions support for the Flatpak or snap store version of Discord, which is a different thing and worth not confusing. The Discord client being sandboxed is handled; the editor being sandboxed is not.

The RPC client underneath, and the projects it grew out of

A Rich Presence extension does not talk to Discord directly. It talks to the local Discord client over the Discord RPC interface, which is why a Discord client has to be running for the status to appear.

The dependency list in the package manifest shows how that is done here. The RPC client is @xhayper/discord-rpc at ^1.3.4, which is a maintained fork of the client originally created by discordjs, and the contributor list in the manifest names xhayper. Alongside it sit discord-api-types, filesize at ^11.0.17 for the {file_size} value, git-url-parse at ^16.1.0 for the git variables, and normalize-url at ^9.0.1 for the link handling.

The credits section is unusually explicit about lineage, and it is the place to look for the real history of the project. It names discordjs as the creator of the Discord RPC Client, iCrawl as the creator of discord-vscode, and Satoqz as the creator of vscode-discord. The documentation then says that much of the code in this repository is based on discord-vscode and vscode-discord, and that the extension would not exist without them.

That matters for judging the project. This is not a from scratch implementation of a new protocol; it is a configurable layer on top of two earlier extensions, with the configuration surface as the actual contribution.

How the extension is packaged and built

The manifest is a good description of the engineering, because it is small and every entry is deliberate.

The package is named vscord with the display name Discord Rich Presence, published by LeonardSSH, and the version in the manifest is 5.3.10. The entry point is dist/extension.js, which means the TypeScript source in src/ is bundled rather than shipped as loose files, and the build is done with rspack rather than the older webpack setups. The scripts reflect that: compile runs rspack, watch runs rspack --watch, package runs rspack in production mode with hidden source maps, and vscode:prepublish chains into the package script. The pretest hook compiles first, so the tests always run against fresh output.

The activation event is onStartupFinished, which is a deliberate choice over an onCommand activation: the presence has to be there before you start typing, not after you run a command.

The extension declares both ui and workspace in extensionKind, so it can run in a remote or container window, and it is classified under the Visualization and Other categories with a dark gallery banner in the Discord blurple.

The dev dependencies are the usual modern set: rspack and its CLI, TypeScript 6, the vscode typings pinned to 1.52.0, the vsce packaging tool, prettier and npm-run-all. The repository root holds the rspack config, the tsconfig, a prettier config, a changelog, the assets folder with the extension icon, and the language guide.

What VSCord is not, and when to leave it alone

The limits here are mostly about scope, and they are easy to state plainly.

This is presence only. It publishes a status; it is not a Discord client, it does not send messages, and it does not run any Discord feature beyond the presence card. If what you want is Discord inside the editor, this is the wrong extension, and if what you want is your editor state visible to other people, it is exactly right.

The second limit is the sandboxing constraint already mentioned, and it is worth checking before you install rather than after, because the failure mode is an extension that loads and does nothing.

The third is maintenance of the language list. Support for over 130 languages is maintained by contributors following a written procedure in ADDING_LANGUAGE.md, which is a good sign for a community project and a slow one for a language that nobody contributes. And a status line built from variables you configure is only as good as the settings you write, which is why the project ships 60-plus settings rather than three.

The alternative worth comparing is the two extensions this one is built on. iCrawl's discord-vscode and Satoqz's vscode-discord are the earlier, simpler implementations with a fixed behaviour. vscord's approach is different in one specific way: it turns the status text into a template that you fill with variables, and it ships its own fork of the RPC client rather than depending on the original. If you want a presence that says exactly what you want it to say, that extra machinery is the point. If you want the default behaviour and no configuration, the simpler predecessors do the same job with less to learn.

Release cadence, licence and who maintains it

The release history shows a project in the 5.3 line with a steady but not fast rhythm. v5.3.10 was published on 2026-06-09, v5.3.9 on 2025-12-12 and v5.3.8 on 2025-11-23, so the last tagged release is a few months old while the repository itself is not archived and the last push was on 2026-10-17.

That gap between the newest tag and the newest commit is normal for a packaged extension, since the marketplace version is what users get, but it means the tag is the thing to track rather than the branch.

The licence is MIT, and the manifest carries the same identifier, so the extension can be used, modified and redistributed with attribution and nothing more to negotiate. For a status line plugin that is about as permissive as a project gets.

The contribution path is the standard fork workflow, and the documentation walks through it: fork or clone the main branch, create a branch in your fork, make the changes, commit and push, then submit a pull request. Continuous integration and continuous delivery badges are shown in the header, and there is a Gitter support chat linked from the same place.

The project also says it is a highly customizable extension with a note to star the repository, which is the kind of sentence you can ignore and still learn everything you need to know from the variable table.

Editorial conclusion

Adopt vscord if you want a Discord status that reflects the file, the workspace and the git branch you are actually in, and you are willing to spend an afternoon tuning the settings and the template variables. Do not adopt it if you need a Discord client, since it only publishes presence, or if you run the snap store or Flatpak build of VS Code, because the extension states it does not work there. Verify first that your Discord client exposes the Rich Presence interface the RPC client expects, that the version you install matches your editor, and that the editor build you use is the official one rather than a repackaged variant.

Frequently asked questions

Official sources

1. leonardssh/vscord on GitHub
2. License: MIT
3. Project website
4. README
5. Releases