vrc-get: a command line client for the VRChat Package Manager

A community client for a first-party tool

vrc-get is described as an open source command line client of the VRChat Package Manager, the main feature of VRChat Creator Companion, and it supports Windows, Linux and macOS. The project states in small print that it is developed by the community and not by VRChat, which is the single most important fact for anyone deciding whether to depend on it. The stated initial goals were to provide an open source command line client of the package manager and to provide more functionality for VPM than the official vpm commands can do. Since 2024 an additional goal was added, to provide a better cross-platform Creator Companion. That last goal is why the graphical version exists at all, and the README dates it: since late February 2024 an experimental GUI version of vrc-get has been available, with its own README in the vrc-get-gui directory.

The command list, and the resolve alias that matters for CI

The commands section is a checklist of what the tool does, with aliases marked. Installing a package into your project is vrc-get install with a version argument, aliased as vrc-get i, and there is a related vrc-get resolve. Removing a package is vrc-get remove, aliased vrc-get rm. vrc-get outdated lists outdated packages, vrc-get upgrade upgrades packages, and vrc-get search takes a query and searches the repositories installed on your machine rather than anything remote. The repository commands are a subcommand group: repo list, repo add with a URL and optional name, repo remove by name or URL, repo cleanup for the cache, and repo packages to list the packages in a named repository. The split between install and resolve is the part to notice for automation, since the README points CI users at a dedicated action for resolving VPM dependencies and a separate setup action for other commands.

Installing it, and the packaging is unusually broad

The installation options cover most package managers, which is what you would expect from a tool that wants to replace a first-party installer. Homebrew is the shortest.

brew install vrc-get

Windows has two routes, winget and scoop, and the scoop route needs the bucket added first.

winget install anatawa12.vrc-get

scoop bucket add xrtools "https://github.com/babo4d/scoop-xrtools"
scoop install vrc-get

On Arch it is an AUR package, and the README says to use your favourite AUR helper.

yay -S vrc-get

For Rust users there are two options, cargo binstall, which downloads and installs a prebuilt binary from GitHub, and a plain cargo install, which builds from source.

cargo binstall vrc-get

cargo install vrc-get

The release page also carries prebuilt binaries that you can place anywhere, with no additional requirements, since they are compiled as statically as possible. The README details the remaining dynamic links per platform, since on Linux the binary is actually statically linked, while on Windows only a list of builtin DLLs such as bcrypt.dll and ws2_32.dll are dynamic, and on macOS only the Security and CoreFoundation frameworks and a couple of builtin dylibs.

A Cargo workspace with the CLI, the VPM library and the GUI

The repository is a Cargo workspace with edition 2024 and the licence declared as MPL-2.0. The members are xtask, vrc-get, vrc-get-gui, and inside the GUI two more crates, a windows-installer-wrapper and an online-installer, plus vrc-get-vpm. The default members are only vrc-get and vrc-get-vpm, and the workspace file explains why: the GUI is excluded because it requires complex Tauri configuration, and a build-check-static-link target is excluded because it is a project utility rather than part of the main project. The vrc-get-vpm member is the interesting one structurally, since separating the package manager library from the command line front end is what lets the GUI and any other consumer reuse the same logic. The workspace profiles also show care about build size, with the online installer using a single codegen unit, link time optimisation, panic set to abort and symbols stripped, while the xtask profile turns off incremental builds and link time optimisation for fast local iteration.

What is in the repository beyond the code

A few files describe how the project is maintained and where its data comes from. The repositories.txt file at the root is the list of package repositories the project knows about, which connects to the repo commands, since adding a repository and searching within it are both built on that set. There is a CHANGELOG.md for the CLI and a separate CHANGELOG-gui.md for the graphical version, so the two release lines are tracked independently, which matches the release tags, where the CLI and the GUI have their own version numbers and their own release cadence. The Cargo.lock is committed, along with a .cargo directory for cargo configuration, an update-deps.sh script for dependency updates, and a .something-releaser.toml for the release tooling. The contribution section points to a CONTRIBUTING.md for the CLI and a separate one in the vrc-get-gui directory for localisation work on the GUI.

Active development, and the licence detail to check

The project is being worked on. The release history shows v1.9.2 for the CLI on 2026-07-12, and the GUI at gui-v1.1.8 on 2026-07-11 with a release candidate the same day, so both halves of the project are shipping on a similar rhythm. The last push to the repository was on 2026-10-19, and the repository is not archived. The README badges show the same distribution reach it describes: GitHub deployments, crates.io, Homebrew, MacPorts, Scoop, AUR and WinGet all carry a version badge, which is a good sign for a tool that must stay in step with a first-party product. One detail to check yourself. GitHub reports the repository licence as a custom one that it cannot classify, while the Cargo manifest declares MPL-2.0, so the LICENSE file in the repository root is the authority on the terms, and the author is listed as anatawa12.

Editorial conclusion

vrc-get fits a VRChat creator who wants to script package installs, pin versions in a repository, or resolve VPM dependencies in a GitHub Actions workflow without driving the official Creator Companion. It does not fit someone who wants a supported VRChat product, since the project states it is developed by the community and not by VRChat. Verify first that the packages you need are in a repository your project already has, since vrc-get search only looks in installed repositories, and prefer the resolve subcommand in CI over the install subcommand, because the README points to a dedicated action for resolving dependencies.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. vrc-get/vrc-get on GitHub