Mod Organizer 2: a virtual-file-system mod manager for Bethesda-era PC games

The problem MO2 was written to solve

Most mod managers copy files into the game's Data directory. Uninstalling then becomes a guessing game about which files belonged to which mod, and two mods that ship the same filename cannot coexist. Mod Organizer 2 takes the opposite position. The README says it is "a tool for managing mod collections of arbitrary size" and that it is "specifically designed for people who like to experiment with mods and thus need an easy and reliable way to install and uninstall them." That sentence is the whole design brief. The target user is someone who keeps several load orders side by side, turns mods on and off to isolate a crash, and expects the game folder to stay untouched when they are done. A player who installs one texture pack and never changes it is not the audience, and will find the extra indirection pure overhead.

How the virtual file system and profile model work

MO2 does not merge mods into the game directory. Each installed mod is kept in its own folder, and the manager presents a merged view of the enabled ones to the game process at launch. The repository layout reflects this: the code is split into a core application plus separate game plugins, so the manager itself knows nothing about Skyrim or Fallout until the matching game repository is present. The README lists those repositories by name, including modorganizer-game_skyrimSE, modorganizer-game_fallout4, modorganizer-game_falloutnv, modorganizer-game_starfield and modorganizer-game_ttw, alongside installers such as modorganizer-installer_fomod and modorganizer-installer_bain. Two consequences follow. First, the same installation can serve several games only if each game has its own plugin. Second, because mods are never copied into the game tree, a profile switch is a change of which folders are visible, not a reinstall. The README also points to usvfs as one of the project's repositories, which is the component that supplies that virtual view. The README does not describe the internals of usvfs, so treat the mechanism as documented only at this level.

Getting the build and running a first profile

The README does not give a step-by-step installation guide. It gives download locations: the GitHub releases page and the NexusMods page for site mod 6. Get the build from one of those two places; the old TanninOne releases page is listed separately as a legacy location. Beyond that, the README documents no commands, no installer flags and no configuration keys, so there is nothing to copy into a terminal. The one setup instruction it does give is aimed at developers rather than users: it says to refer to the Modorganizer2/mob project for build instructions, and that mob downloads the other repositories automatically as required, though they should also be buildable individually. The repository root carries CMakeLists.txt, CMakePresets.json, vcpkg.json and vcpkg-configuration.json, which tells you the build is CMake plus vcpkg rather than a single script, but the README does not spell out the steps. After a game instance exists, install a mod from an archive and enable it in the left pane; the game sees the merged result when launched through MO2, not when launched from Steam directly. That last point is the one users trip over most: launching the game outside the manager bypasses the virtual file system entirely.

Where MO2 stops being the right tool

The virtual file system only applies to processes started through MO2. Anything that reads the game directory from outside, including some external tools and launchers, will not see the mods. Games without a dedicated game repository in the README's list are not supported at all, which is why the software's reach is bounded by that list rather than by the manager's own code. There is also a maintenance reality the README states plainly: Tannin discontinued the project when he joined Nexus to build Vortex, and "MO2 was not completed and was left with many issues." LePresidente later brought it to a usable state and released v2.0.8, and more contributors arrived in late 2017. The README's "Help Wanted!" section still asks for developers, and translation work is coordinated through a Discord channel. The latest release listed is v2.5.2 from 2024-08-04, while the last push to the repository was on 2026-07-08, so the codebase moves between releases. If you need a documented support contract or a fixed release cadence, this is not it.

Vortex and Wrye Bash as the alternatives

Vortex is the closest comparison, and the history matters: the README says Tannin was hired by the Nexus team to develop Vortex after discontinuing MO2. The two take different approaches to the same job. Vortex is the official Nexus tool and is tied to that ecosystem, while MO2 keeps mods in per-mod folders and presents them through a virtual file system with independent profiles. For a user who installs everything from Nexus and wants the manager to handle deployment, Vortex asks less of them. Wrye Bash is the other long-standing option, and its model is different again: it works with the game's own data layout and a bashed patch rather than a virtual overlay, which suits people who want the merged result to exist on disk. Neither alternative is a drop-in replacement, and switching means rebuilding the mod list in the new tool's own terms.

Licence, building and what an upgrade costs

MO2 is GPL-3.0. That matters if you plan to redistribute a modified build: the licence carries obligations that a permissive licence does not, and the repository ships the LICENSE file at its root. Nothing here is legal advice; read the licence text before you ship anything derived from it. Building from source is deliberately indirect, since the README delegates it to the mob project rather than describing it in place. Upgrading is the cheaper path for most users: the README names two download locations, and the release list shows release candidates such as v2.5.2rc1 and v2.5.2rc2 preceding the v2.5.2 final. The README does not document a rollback procedure, so keep the previous version's archive if you test a release candidate on a working setup.

Editorial conclusion

Adopt Mod Organizer 2 if you run several mod profiles for the same game, or if you need to remove mods without leaving files in the game directory. Do not adopt it if you want a manager that configures itself with no setup steps, since the README points developers at the separate mob project for a build environment and the game support lives in many separate repositories. Before you commit, verify two things: that a game repository exists for your title in the list the README publishes, and that the release you download comes from the GitHub releases page or the NexusMods page the README names.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. ModOrganizer2/modorganizer on GitHub
3. Project website
4. README
5. Releases