MO2-LINT: A One Command Installer for Mod Organizer 2 on Linux

The Problem It Solves Is the Setup, Not the Installer

Mod Organizer 2 is a Windows application, and running it on Linux means running it through Wine or Proton, in a prefix that has to be configured correctly, with the game's own launcher and its mod loader present. The MO2-LINT project describes its goal as making the installation of Mod Organizer 2 on Linux systems easier and more accessible, providing a simple process to set up a fully functional Mod Organizer 2 installation with minimal user input.

So the target user is a player, not a sysadmin, and the promise is a working MO2 setup for a particular game with as few decisions as possible. The tool is a Python command line application, distributed under the GPL-3.0 licence, and its documentation is published at docs.furglitch.com with a getting started page, a CLI guide, per-game guides, troubleshooting and an FAQ.

The README also flags an important detail for anyone about to run it. Setting up a specific game means checking the Game Guides section first, because some games need extra steps before or after install. That is a warning worth heeding, since a modding setup that is half configured tends to fail later in a confusing way.

What the install Command Does

The feature table gives the summary in one line: the install command sets up Proton, downloads MO2, registers compatibility tools, and wires up the NXM handler.

Each of those four steps is work that would otherwise be manual and error prone. Setting up Proton means creating a prefix for the right Proton version and making sure the game is known to it. The NXM handler is the piece that makes the Nexus Mods Mod Manager Download button work.

The CLI is described as designed to be as user friendly as possible, with clear commands and options, and the implementation shows how that is done. The dependencies include click for the command line, inquirerpy for interactive prompts, pydantic for configuration models, loguru for logging, protontricks for the Proton prefix work, patool for archive handling, requests for the network, websockets for the messaging the NXM handler uses, and vdf for the Valve Data Format that Steam and Proton configuration uses.

The package metadata requires Python 3.13 or newer, and the repository carries a.python-version file and a uv.lock, so the tool is developed against a managed interpreter rather than whatever the system provides.

The NXM Handler Is What Makes the Nexus Button Work

Of the four steps, the NXM handler is the one with the most visible effect on day to day use. The README describes the bundled NXM handler as making the Mod Manager Download button on Nexus Mods work out of the box.

NXM is the URL scheme Nexus Mods uses for direct download links. On Windows the Mod Manager button hands a link to the mod manager client and the file downloads into the right place. On Linux, without a registered handler, the browser either refuses the link or hands you a file you have to place yourself.

The implementation is a separate binary rather than a mode of the main tool. The Makefile builds an nxm-handler executable with pyinstaller, along with a mo2-lint executable, and the source tree has a src/nxm-handler/ directory with its own __init__.py entry point, a src/shared/ directory used by both, and a src/steam-proton-wrapper/ directory. The nxm-handler build pulls in find_heroic_install as a hidden import, which tells you it knows how to locate a Heroic Games Launcher installation.

Because the handler is a separate program, it can be registered with the desktop environment independently of the installer, and it is the piece that has to survive the container or prefix boundary between the browser and the Windows-side MO2.

One MO2 Instance per Game

The second row of the feature table is multiple instances, described as running separate MO2 instances for each game, each independently tracked and updatable.

This is the design point that most affects how you use the tool afterwards. Mod Organizer 2 keeps a virtual file system and a per-instance profile, and running a single instance for several games is a common source of conflict: a mod for one game sits in the same load order as a mod for another, and a plugin installed for one title loads inside the other. One instance per game removes that class of problem, and the fact that each instance is tracked and updatable means the tool keeps its own record of what it created for each title.

The supported games list in the README is long and specific, which is itself a signal about the scope. It covers Baldur's Gate 3, Cyberpunk 2077, Dragon Age: Origins and Dragon Age 2 in their Ultimate Editions, Enderal in both editions, Fallout 3 with its Game of the Year Edition, Fallout 4 and Fallout 4 VR, Fallout London, Fallout New Vegas, Morrowind, Oblivion, Skyrim, Skyrim Special Edition, Skyrim Anniversary Edition in the Heroic edition, Skyrim VR, Starfield, Subnautica, Valheim, and The Witcher 3 in both its base and Game of the Year editions.

Script Extenders, Plugins, Themes and Compatibility Fixes

Three of the remaining features are optional extras that the setup step can install for you.

Script extenders are the first, and for the games that need one they are not optional in practice. The README mentions SKSE and F4SE by name as examples, and the tool can install the game's script extender during setup. Without the extender, a large part of the mod ecosystem for those titles simply does not load.

MO2 plugins and themes are the second, described as optionally installing community plugins and themes for Mod Organizer during setup. These are the plugins that extend the MO2 interface itself, and installing them alongside the base installation saves a second round of clicking inside the Windows application.

The third is the one that is genuinely the maintainer's own work rather than a download. Compatibility workarounds ship fixes for known Proton and Wine quirks per game, so you do not have to hunt them down yourself. Each of these is a patch for a specific interaction between the game, Proton, Wine and MO2, and no generic installer could handle them, which is why the supported list is the place where the effort actually went.

Per-Game Documentation Is the Real Knowledge Base

The documentation structure is a good indicator of how the project is meant to be used. There is a Getting Started page covering prerequisites, installing the binary, setting up Proton and the first install. There is a CLI Guide for every command, option and file configuration. There is a Game Guides section for per-game notes. And there is Troubleshooting and an FAQ for when it goes wrong.

The Game Guides are linked from the supported games table itself, so a specific game may point at a guide. Cyberpunk 2077 has one, Fallout 3 Game of the Year Edition has one, Fallout 4 has one, Fallout London has one, Oblivion has one, and Skyrim Anniversary Edition in the Heroic edition points at a guide on the docs.furglitch.com domain. The guide for Skyrim Anniversary Edition is hosted on the older domain, which suggests the documentation was moved once and a link was left behind.

The repository also carries a docker/ directory, which suggests the project can be exercised in a container for testing or for a headless setup, alongside a tests/ directory, a docs/ directory, a configs/ directory and a build/ directory holding the pyinstaller runtime hooks.

A Bash Script Rewritten in Python

The credits section is short and explains the project's shape. It was originally developed by rockerbacon as a Bash script, and has since been maintained by furglitch and fully rewritten in Python for maintainability, extensibility and cross-distro compatibility.

That rewrite is visible in the tree. A Bash script that only worked on one distribution's helper tools becomes a Python package with pydantic models for configuration, a testable module layout under src/, and a dependency list that pins the pieces it relies on. The project also uses uv, with a uv.lock at the root, and the Makefile drives the run and build targets through uv run.

The build itself is pyinstaller, producing single file executables. The mo2-lint target bundles the src/mo2-lint and src/shared trees, the steam-proton-wrapper, the configs directory and the dist directory as data, with a runtime hook from build/runtime_hooks.py and additional hooks from build/hooks. The hidden imports listed in the Makefile, InquirerPy, patoolib, protontricks, pydantic_core, requests, send2trash, websockets and yaml, are the modules pyinstaller cannot detect automatically.

The release cadence is fast. The tags are MO2-LINT 7.0.3 on 2026-10-07, 7.0.2 on 2026-10-05 and 7.0.1 on 2026-10-03, three releases in five days, with the version in pyproject.toml at 7.0.2. The repository is not archived and the last push was on 2026-10-19, so the tool is being maintained actively, with the 7.x line evidently used for compatibility and support fixes to specific games.

Editorial conclusion

MO2-LINT fits a Linux player who wants Mod Organizer 2 working for a specific game without assembling Proton prefixes, compatibility tools and the NXM handler by hand, and it does not fit a game outside the supported list, or a player who wants a general purpose mod manager across many titles rather than per-game instances. Before running install, read the Game Guide for your title, since the README says some games need extra steps before or after that command, and check the compatibility table, because the per-game workarounds are the part of the tool most likely to need updating. The project is GPL-3.0 licensed, requires Python 3.13 or newer, the newest release is 7.0.3 from 2026-10-07, and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. Furglitch/modorganizer2-linux-installer on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases