VRCX keeps a second VRChat session outside the headset

A second VRChat session beside the one in VR

VRChat's own client keeps you inside the session you launched, desktop or headset, and its website covers part of the same ground. VRCX takes the opposite route: it logs you in separately on the desktop and keeps working while you are nowhere near a world. Friends, worlds and avatars get listed there, and the activity of people on your list is tracked for online status, current location and the avatar in use.

What sits at the center is that second session. Every friend, world and avatar panel depends on it, as do the dashboard widgets, the notification handlers and the invite flow where you send and accept requests without opening VRChat. Friendship history sits alongside it, covering add dates, time spent together and every name change a person has been through.

Smaller pieces lean on the same connection. A heatmap draws a user's online pattern across day of week and hour of day, social status presets save a status plus description pair for one click reapplication, and Quick Search does client-side fuzzy matching over your friends, avatars, worlds and groups, or takes a pasted ID or URL straight to the record. One feature stands apart: world data is written into the pictures you take in game, so an image file carries the place it came from.

One installer for Windows, a wiki page for everyone else

The distribution story is a single installer plus a set of wiki pages. Windows users are pointed at the latest `VRCX_Setup.exe`, the build published on 2026-09-16, and everyone else is told to check a wiki page about running VRCX on Linux. No macOS package, repository or store listing appears in the documentation. The build scripts tell a more capable story than the download instructions do, because the same manifest carries `build-electron` for x64 and `build-electron-arm64` for arm64, both driven by `electron-builder.config.js`.

Here is that x64 entry in full, since it shows three things at once:

"build-electron": "node ./build-scripts/download-dotnet-runtime.js --arch=x64 && node ./build-scripts/patch-package-version.js && cross-env DEBUG=electron-builder electron-builder --config electron-builder.config.js --x64 --publish never",

A .NET runtime is fetched into the tree first, the version is patched second, and packaging passes `--publish never`, so the run stops short of uploading anything. Whatever puts a build in front of users happens outside these scripts. The manifest also carries `"private": true`, so there is no published npm package to install either; a clone plus a build, or the installer, are the two real routes in.

An arm64 packaging path next to one Windows download link is the first thing a new user runs into, and the documentation does not resolve it. On macOS or Linux the decision is whether the wiki instructions work on your machine, and you find that out after committing to the install.

The dev script serves the renderer, not the desktop shell

The architecture splits across two roots, and the manifest's entry point shows it. `main` points at `src-electron/main.js`, the Electron process that owns the window, while the dev script serves the renderer on its own:

"scripts": {
    "dev": "vite serve src",
    "localization": "node ./src/shared/utils/localizationHelperCLI.js",
    "format": "oxfmt",
    "lint": "oxlint",
    "typecheck:js": "tsc -p tsconfig.checkjs.json",
    "typecheck:vue": "vue-tsc -p tsconfig.checkjs.json",
    "test": "vitest run",
    "prod": "vite build src && npm run build:licenses",
    "build:licenses": "node ./build-scripts/generate-third-party-licenses.js"
},

Read that first line twice. It brings up the interface without the desktop shell, and no entry above or below it launches Electron alongside the vite server. The listed scripts stop at the two builder commands, so how a contributor gets the renderer and the main process into one window is left to the building-from-source wiki page rather than the manifest.

The second root is the surprise. The primary language is JavaScript, yet a `Dotnet/` directory sits beside it and the same manifest wires `dotnet format` against a `VRCX.slnx` solution. Quality gates are split too: `oxfmt` formats, `oxlint` lints and fixes, four tsconfig files cover the app, the Node side and a check-JS pass, and `vitest.config.js` with `vitest.setup.js` runs the tests. A contributor with only Node installed has half the checks, and the rest needs a .NET SDK on the machine.

Licensing is wired into the web build rather than maintained by hand: `prod` runs `build:licenses`, which calls `generate-third-party-licenses.js`, and the manifest carries the MIT identifier.

Export writes more than import can restore

Export and import are not symmetric, and the asymmetry is the part that bites. The export side covers the friends list, the avatar list, Discord names, notes and favorite groups. The import side takes favorite groups and group moderation bans, and nothing else.

Read as a pair, your notes, your memos about how you met somebody and the Discord name mapping can be written out to a file but cannot be pushed back into a fresh install. The same holds for the avatar list and the friends list: VRCX writes them and does not read them. The documentation names no file format, no directory and no version marker for those exports, so there is no stated way to tell a current export from an old one.

That gap turns a migration into a data question rather than a feature question. Move machines or reinstall Windows, and what survives is decided by VRCX's own storage on the old disk, where the documentation does not say where it lives or how to carry it. The world data embedded in in-game pictures has no documented path out either.

The import side still has a use: favorite groups and moderation bans are the one migration the tool performs, which is why the longer export list matters.

Nightly builds with no documented way back

Two channels ship side by side, a stable installer and a beta or nightly build reached through a separate page or through `Settings -> General -> Change build` inside the app. Once you take that second step, no page in the documentation gives a route back: nothing covers selecting a stable build again, pinning a version or undoing the switch, so the move is one-way until you reinstall.

The version in the code does not settle it either. The checked-in `version` reads 2026.09.16, and the packaging path runs `patch-package-version.js` before electron-builder starts, which means that number tracks the build being cut rather than the channel on your disk. Nothing inside the installed app tells you which channel you are on.

Maintenance itself is current: the last push landed on 2026-10-05 and the repository is not archived, with tagged builds 2026-05-03, 2026.07.18 and 2026.09.16 spaced roughly two months apart. Planning around that rhythm is reasonable; planning around a rollback is not, because none is written down.

Watching the VRChat process is the real cost

Some features only make sense if a background process watches the client. VRCX can launch other apps when VRChat starts, and it will restart VRChat and rejoin the last instance after a crash. A status bar and a login-page alert report VRChat server outages as they happen, and Discord Rich Presence publishes the world thumbnail, world name, player count and a join button for public lobbies.

That combination is the honest price. A separate application, logging into your VRChat account outside the official client, sitting in front of the game process and bridging to Discord, is a different posture from the vanilla client. No permission prompt, sandbox rule or note on how the login session is held after the two-factor page shown beside the login screenshot appears anywhere in the repository.

This is where it stops being the right tool. Want your friend list visible without entering VR, and you will like it. Would rather not have a third-party desktop process hold a live account session and be able to relaunch the client under you, and none of the friend, world or avatar features pay for that. A VR overlay with a live feed of supported events extends the same reach into the headset, so there is no way to take the tracking without the window.

Measured against the plain client and the website

The real alternative is the pair the README measures itself against: the plain VRChat client, on desktop or in VR, and the website. They are the ones VRChat ships, and they cover the same friendships and instances you would otherwise be scrolling.

The difference is where the work happens. VRCX runs a separate desktop login, keeps its own history and notes, and adds the surfaces the official client has no place for: a customizable dashboard with Feed, GameLog and Instance widgets and multiple filterable panels, avatar and world image uploads without Unity, per-build themes, and a crash-and-rejoin loop. Take the plain client instead and you give up every one of those, with nothing to migrate because none of that data is documented as importable.

A third path suits people who only want tracking: nothing in the manifest exposes a headless or server mode. The entry point is an Electron main process, so VRCX is a windowed desktop application by construction, which rules out running it on a home server or in a container for a shared account.

The questions the documentation leaves unanswered

Several practical questions have no answer in the repository, and knowing which ones saves an afternoon. There is no documented configuration file, no environment variable list, no command line interface and no API surface; every feature listed is reached through the window. Themes, the Linux instructions and the build recipe are each a wiki page, while contribution guidance does live in the repository at `CONTRIBUTING.md`.

One manifest entry points outside the build pipeline. The `localization` script runs `node ./src/shared/utils/localizationHelperCLI.js`, and the files it serves sit in `README/` next to the English readme, nine translations in all. Nothing else in the manifest touches string files.

The toolchain cost is lopsided. Staying on the stable installer is a download. Building means providing Node, a .NET SDK and an Electron-capable environment, and the manifest that carries `format:check`, `lint`, three typecheck scripts and `test` also carries the two packaging commands.

Editorial conclusion

Adopt VRCX if you live inside VRChat's social graph and want friends, notes, history and dashboards outside the headset, since every one of those panels hangs off a separate desktop login of its own. Skip it if you will not let a third-party process hold that session and relaunch the client after a crash, or if you need your notes to move with you, because import only takes favorite groups and moderation bans back in. Before installing, confirm your platform has a documented route beyond VRCX_Setup.exe and export a notes file first.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vrcx-team/VRCX on GitHub