Wrye Bash: managing mods across thirteen Bethesda Creation Engine games

What Wrye Bash actually manages

The repository description calls Wrye Bash a swiss army knife for modding Bethesda games, and the About section gives the precise scope: it is a mod management utility for games based on Bethesda's Creation Engine, with a rich set of features.

The thing it manages is the plugin system. Creation Engine games load data plugins in a load order, and that order decides which values win when two plugins disagree. A utility that understands the order, can reorder it, and can show you the conflicts is solving a real problem rather than offering a convenience.

The feature set, though, is not described in the README in detail, and that is worth being honest about. What the README does give is the support matrix, the install steps, the branch layout and the support channels, and then links to a General Readme and an Advanced Readme in the online docs for anything more. The tool's depth is real, but it is documented outside this repository.

What the README does establish is the project lineage. It is a fork of the Wrye Bash related code from the SVN 3177 trunk revision, and the team says they are in the process of refactoring the code to eventually support more games, offering the same feature set for all of them. That refactoring goal is the single most useful fact about the project's direction, because it tells you that a feature which exists for Skyrim today may end up shared across every supported title.

The primary language is Python, the licence is GPL-3.0, the default branch is dev, and the homepage is wrye-bash.github.io. The code lives in the Mopy/ directory, which is the historical name of the project's internal tree and shows up in the launcher script name too.

The supported game list is a patch-version contract

The support list is the most operationally important part of the README, and the framing sentence tells you how to read it. It is a list of supported games with the minimal patch version that Bash was tested on, and the parenthetical warns that previous versions or latest versions may or may not work.

That is a blunt statement of the real constraint. Wrye Bash patches and reads game data files, so it is coupled to the exact data format the game ships. The list gives you the floor: Enderal at patch 1.6.4.0, Enderal: Special Edition at 2.0.12.4, Fallout 3 at 1.7.0.3, Fallout 4 at 1.10.163.0, Fallout 4 VR at 1.2.72.0, Fallout New Vegas at 1.4.0.525, Morrowind at 1.6.1820.0 but marked as very early support, Nehrim at 2.0.2.4, Oblivion at 1.2.0.416, Skyrim at 1.9.36.0, Skyrim Special Edition at 1.6.1130.0, Skyrim VR at 1.4.15.0 and Starfield at 1.7.23.0.

Morrowind is the one to notice. It is listed with very early support, which is the project's own way of saying the feature set there is not comparable to the others. The stated goal is the same feature set for all games, and that goal is not reached for Morrowind.

Two other things fall out of this list. The games span a decade of engine versions, from Oblivion and Morrowind on the older engine to Starfield on the current one, and a single tool handling all of them is unusual. And the patch numbers being pinned to specific builds means the upgrade order matters: if you update your game to a patch the utility has not been validated against, you are outside the tested envelope.

The topic tags on the repository match this list, adding Fallout: New Vegas, Skyrim Special Edition, Skyrim VR, Fallout 4 VR, Nehrim and Enderal to the names, and the generic tags mod-manager and modding.

Installing on Windows and Linux

There are two install routes and they are not equivalent.

On Windows, downloads come from GitHub and from NexusMods. On Linux, the package is on the AUR. Documentation is included in the download and also published online at wrye-bash.github.io.

The short version of installation is that you use the installer and install everything to its default location. The long version is in the General Readme and the Advanced Readme in the online docs. The README then walks through the manual sequence: install one of the supported games, install Python and the plugins above, extract the downloaded Wrye Bash archive into your game folder, and run Wrye Bash by double-clicking Wrye Bash Launcher.pyw in the new Mopy folder.

The launcher being a .pyw file is a small Windows detail with a purpose: the .pyw extension runs the script without a console window, so the user sees the application rather than a terminal.

To run the latest dev code instead of a release, you need two things: a game to manage from the supported games, and Python 3.11 64-bit, with the latest 3.11 recommended. The requirements are explicit that the 64-bit version is required and that 32-bit operating systems are no longer supported.

Once those are in place, the dependencies are installed with:

py -3 -m pip install -r requirements.txt

The README notes you will have to use a more specific version for py -3 if you have multiple versions of Python 3 installed, which is the usual Windows launcher behaviour.

Linux users have the AUR package, and there is also a WINE route. Since version 306, Wrye Bash runs on WINE, with some hiccups, and the README points to a wiki article for a detailed guide plus a specific relevant issue number for the current problems.

The branch layout and how betas reach users

The three-branch arrangement is unusual and worth understanding before you pick a source.

The dev branch is the main development branch, where approved commits end up, and the README is emphatic that you should not push directly to it: push to your own branches and contact a maintainer in the relevant issue. The master branch is the production branch, contains stable releases, and should be used only as reference. The nightly branch is the bleeding edge branch, where commits land for testing.

So there are three distinct kinds of code here, and the naming is not the usual one. Master is not where you get the newest features; it is where the stable releases live and it is explicitly not meant to be used as a working branch. Nightly is the experimental edge, and dev is the curated development line.

For end users there is a separate channel above all of this. The latest betas are linked from the second post of the AFK Mods thread and from the wip-builds channel on Discord, and the README points out that these are the Python and standalone exe builds. It calls them bleeding edge bugfixes and enhancements, and asks for feedback on them.

That gives a practical three-tier model for a user: a stable release from GitHub or NexusMods for everyday use, a nightly build from the Discord channel if you want fixes before they are cut, and the dev archive if you are following development closely. The default branch in the repository metadata is dev, which tells you where the work is happening.

The release cadence is irregular by design. The recent releases are v315 on 2026-09-14, v314 on 2025-04-05 and v313 on 2024-12-21, so a year and a half passed between v313 and v314, and the last push was on 2026-10-19, which means there is development after the v315 tag.

Reading the dependency list, and what it reveals

The requirements.txt file is worth reading in full, because the comments explain design decisions that a bare list would hide.

The runtime required section pins chardet at 5.2.0, lz4 at 4.4.5, PyYAML at 6.0.3, vdf at 3.4 and wxPython at 4.2.5, plus two Windows-only packages, ifileoperation and pywin32, both marked with sys_platform == 'win32'. vdf is the Valve Data Format library, and it is the parser for the plain-text configuration files that Creation Engine games and their mods use.

The chardet pin comes with an explanation that is unusual to find in a dependency file. The comment says that newer releases of chardet are fully AI-generated and that there are license concerns as the original was LGPL, but that they suddenly changed to MIT/0BSD without asking contributors, so the project stays on v5 for now. That is a maintainer making a licensing judgement about a transitive dependency and recording it where every contributor will see it.

The recommended section is where the feature set becomes legible. lxml is there for FOMOD schema validation, which is the XML format that mod installers use to describe what an installer does. packaging is there for parsing download conditions when checking for updates. pyfiglet generates bash_default.ini section headers. PyMuPDF provides PDF support in the doc browser. reflink is for reflink copies and is explicitly marked as not supporting Windows or ReFS yet. requests handles Internet-based functionality, send2trash sends files to the recycle bin on non-Windows platforms, and websocket-client is for Nexus Mods integration.

That last one is a clue about the scope. Wrye Bash talks to Nexus Mods directly over a websocket, so the tool is not only a local patcher but also a client for the largest mod distribution site.

The file also has a compile and build-time section that pulls in requirements-scripts.txt, which is the separate requirements file in the repository root, and the project uses a pyproject.toml for coverage configuration with branch coverage enabled and the test directory omitted, plus isort settings. There is a .pre-commit-config.yaml, so formatting and import order are checked before commits land.

Where Wrye Bash is the wrong choice

There are three limits, and the first is the coupling to a specific engine and patch level.

The first is that this is not a general mod manager. It works on games built on Bethesda's Creation Engine, and each supported entry names a patch version it was tested against. If your game is not Creation Engine based, or if your patch is far from the listed floor, the tool has no way to help you, and the README is direct that versions outside the tested range may or may not work. There is no graceful degradation, because the whole approach depends on parsing game data files whose format changes between patches.

The second is that most of the documentation is elsewhere. The README gives you the supported games, the download links, the install steps and the branch layout, and then sends you to the General Readme and Advanced Readme in the online docs for the actual detail. So evaluating it properly means reading a separate site, and the wiki articles for WINE and for bug reporting add to that. For a tool that a user installs by extracting an archive into a game folder, that is a workable arrangement, but it does mean the repository is not self-explanatory.

The third is the environment. This is a Python application that requires a specific 64-bit Python, a set of pinned packages including a compiled wxPython, and it is written to be launched from inside the game folder. It has worked under WINE since version 306, with the README conceding some hiccups, but the supported desktop platforms are effectively Windows and Linux. If you want a mod manager that runs everywhere and manages any game, this is a specialist tool with a specialist's install.

The honest alternative for the load-order and conflict problem in a Creation Engine game is the smaller utilities that solve one piece of it: xEdit for conflict inspection and script editing, and Mod Organizer 2 for a virtualised, per-profile load order and its own conflict resolution. The difference in approach is the scope. Mod Organizer 2 is a general mod manager with a plugin layer that isolates installs, which is the right architecture if you want to run several different mod configurations without conflicts between them. Wrye Bash is a Creation Engine specialist that reads and writes the game's own data formats directly, patches conflicts in place, and carries the accumulated knowledge of that community's patching conventions, which is the right architecture if you want one working configuration of one of these specific games.

For a game outside the list, the honest answer is that neither tool helps and you need the game's own modding wiki, because the file formats and the conflict conventions are game-specific either way.

Editorial conclusion

Adopt Wrye Bash if you mod one of the listed Creation Engine games and want conflict handling and load order management rather than a plain file watcher, since it is the tool the community actually uses for that job. Do not adopt it if your game is not in the supported list with a matching patch version, because each entry names the exact patch the build was tested against. Before you install, check the minimum patch version for your game, note that 64-bit Python is required, and see that the last push was on 2026-10-19 with release v315 from 2026-09-14.

Frequently asked questions

Official sources

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