Heroic Games Launcher Ships Hotfix #3 After v2.22.2 Wrecked Windows Games on Linux
The September 16 release repairs a regression in which a Steam Runtime change caused "umu inside of umu" to wreck game launches.
Heroic Games Launcher shipped v2.22.3 today. It is the third hotfix of the 2.22.x track, and its one real change quietly undid a mistake the project made just a day earlier. That mistake had broken game launches for a good chunk of the Linux gaming community.
Here's the short version. Yesterday, v2.22.2 went out. That build bundled a feature routing Windows games launched on Linux through UMU, the "Unified launcher for Windows games on Linux." The goal was reasonable. The execution, well, it doubled up.
Keep in mind that UMU is essentially a repackaged copy of Valve's Steam Runtime, tweaked so Windows games can run without Steam. It's the piece that lets Heroic, Lutris, and Bottles share one set of protonfixes instead of each maintaining their own scripts. Standardization that every launcher benefits from.
The change in v2.22.2 set an internal flag to treat every game as if it needed the Steam Runtime. That sweep included Windows titles running through Wine or Proton. It should only have applied to a narrower set.
So when prepareLaunch ran, it handed back a UMU path for basically every game. Store managers like Legendary took that path and wrapped the launch command with it. Then the Wine-specific code looked at the same command, saw UMU was available, and bolted a second UMU wrapper on top.
Result: umu inside of umu. That does not work.
One reporter's issue title put it technically enough. The launched command built a malformed string with umu_run.py duplicated right into the Proton slot, which threw a SyntaxError under the Steam Runtime's Python 3.9.
Real-world impact was less academic. People reported Lord of the Rings' launcher breaking with UMU enabled. Satisfactory threw a PCGamingWiki AxiosError and just refused to start. The practical fix was to turn UMU off in settings, which got games running again but also discarded the very behavior many people wanted.
The fix
v2.22.3 lands PR #5894. The author is CommandMC again, merged by lead maintainer Flavio da Lima and approved by aarielj. Rather than making prepareLaunch smarter, the team chose to keep it dumb and fix the logic around it. getWineFlags no longer appends the extra wrapper when UMU is already in play, and non-native sideloaded games ignore the steamRuntime return value entirely.
A handful of lines changed. Existing store-manager code, which already respected the option, kept working as-is. For reference, the whole 2.22.3 build spans five commits across eleven files by four contributors. Only that one change touches what you actually see. The rest is internal: a bug-report template update, a Flathub release-notes metadata cleanup, an AUR PKGBUILD reuse in the build workflow, and the version bump itself.
The release note ran along the lines of "The last release broke UMU for a lot of people and this new Hotfix should fix it. Hopefully our last hotfix before the next Major release." Translation: a major version is coming. Soon.
The bigger takeaway, for what it's worth, is that the Linux gaming stack is a stack of interdependent projects. Valve's runtime, umu-launcher, protonfixes, Proton, Wine. A single line of logic in a migration can cascade into broken launches for thousands of users. That fragility is the trade-off for how nicely everything interoperates.
It's also a decent case study in lean open-source maintenance. Two changes landed in one hotfix, a regression shipped the very next release, and the same small volunteer crew diagnosed and fixed it within roughly two days. Fast. Fragile. And mostly working.
Keep in mind that if a game just stopped launching after the last update, your safest first move is still to check whether UMU is toggled on in settings. Then update to 2.22.3 and turn it back on if needed.
Head here to download the 2.22.3 release from GitHub.
