Runtime Unity Editor, and an inspector that runs inside the game

An inspector that lives in the game process

Runtime Unity Editor is an in-game inspector, editor and interactive console for applications made with the Unity3D game engine. It is designed for debugging and modding Unity games, and the project description also says it can be used as a universal trainer.

The mechanism is a mod loader. It runs under BepInEx5, BepInEx6 IL2CPP and Unity Mod Manager, and it works on most games made in Unity 4.x or newer that use either the mono or the IL2CPP runtime, with IL2CPP support currently in beta.

That last point is the crux of the whole design. A Unity game is a compiled binary, and the interesting state, the object graph, the component values, the private fields, lives in the process memory of a running program. A tool that attaches to that process at runtime can present that state as a browsable, editable structure, which is what an external debugger struggles to do for a game because the object graph is rebuilt by the engine and the type names are obfuscated in some builds.

The audience is therefore modders and developers of Unity games, and the tool sits in the same family as dnSpy, which it integrates with, rather than in the family of a general purpose debugger.

The repository is C#, the licence is GPL-3.0, and the releases are frequent: v6.3.2.1 from 2026-10-06, v6.3.2 from 2026-09-23 and v6.3.1 from 2026-08-03, with the most recent push on 2026-10-17.

Minimal impact, and why that is a design constraint

The feature list opens with two constraints rather than with features, and they are the ones that shaped the implementation.

Minimal impact on the game, with no GameObjects or Components spawned outside of the plugin component loaded by the mod loader, and no hooks used, except if requested for the profiler.

This matters more than it might sound. A tool that injects itself into a game process can break the game in ways the player notices, and for a modder shipping a build to other people, a crash or a performance dip is a support burden. So the tool avoids the two most invasive techniques available: it does not create scene objects to host its UI, and it does not detour engine functions, except where the profiler specifically needs to.

The features that follow are the ones a debugging tool needs and that a shipped game does not provide. There is a GameObject and component browser. There is an object inspector that allows modifying values of objects in real time, with a clipboard. There is a REPL C# console with autostart scripts. There is a simple profiler. There is object serialization and dumping.

There is dnSpy integration, so you can navigate to a member in dnSpy from the inspector, which is how you get from a value to the code that produced it. There is mouse inspect, to find objects or UI elements by clicking with the mouse, and gizmos, with the transform origin, renderer bounds and collider area.

The last feature in the list is the one that makes the tool feel like a single application rather than a set of tools: all parts are integrated together, so the REPL console can access the inspected object and the inspector can focus objects on the GameObject list, and a right click on most objects brings up a context menu with more options.

Installing: three builds, one hotkey

RUE is available for different mod loaders in separate builds, which are largely the same, and the BepInEx version is the most supported and has some extra features. If you do not already have to use a specific mod loader, BepInEx is recommended.

For BepInEx on mono, the steps are: install BepInEx v4.x or v5.x, download the latest BepInEx build from the releases page and make sure it is the correct version for your BepInEx, extract the BepInEx folder from the archive directly into the game directory, replacing files if asked, and then press F12 in game to bring up the window. If the window does not appear, the instruction is to check the logs for errors.

There is one specific fix worth knowing. If the plugin fails to load under BepInEx 4 with a type load exception, you move RuntimeUnityEditor.Core.dll into the BepInEx core folder.

For BepInEx on IL2CPP, the project puts a warning before the steps, and the warning is blunt. It is a beta build that is unstable with many features broken, it is likely to not work in many IL2CPP games because it relies on unstripped UnityEngine.IMGUIModule.dll and possibly other game specific differences, and it works in HoneyCome if used together with the IMGUIModule Il2Cpp CoreCLR patcher, which can be used with some other games with some degree of success. IL2CPP bug reports will be largely ignored, while pull requests to fix issues will be greatly appreciated.

For Unity Mod Manager, you install Unity Mod Manager from its site, pick your game from the dropdown and click Install, download the UMM build from the releases page, go to the Mods tab and drag the zip into the drop area, and press F12 in game.

So the installation is the same shape in all three cases, and the difference is which archive you download.

Known issues, and the C# console that will not work on modern Unity

The known issues section is the most useful part of the documentation for anyone deciding whether this tool fits their setup, because it is specific about failure.

Text that is invisible, scrambled, not scaled properly or otherwise wrong is most likely because the Arial.ttf font is missing from the system, the Unity UI default font, which may be different in some games. The project points at a case that happens on Linux with misconfigured wine and on some regional versions of Windows such as Chinese ones, and the fix is to find the Arial font and install it.

The C# REPL console is only available in a subset of games, because mcs, the current REPL backend, does not work with the .NET Standard runtime used by default in more recent versions of Unity, because of missing features. The project is explicit that there is no fix and the backend will have to be changed, possibly to Lua. That is a hard limitation stated without hedging, and it means the console feature, which is the most interesting part of the tool, is unavailable in exactly the games most people want to look at.

The wireframe toggle might not work in some games because of an incompatible rendering setup. The IL2CPP version is broken where the main issue is stripped IMGUI assemblies. And in some games the BepInEx5 mono version can be seen loading in the log but does not react to the hotkey, which is fixed by setting HideManagerGameObject to true in BepInEx.cfg.

That last one is worth remembering: the tool can be present and working, and the only symptom is that the key does nothing.

Building from source, and a deliberate old UnityEngine.dll

The build instructions are aimed at a developer who wants to modify the tool, and the repository layout supports that with separate project directories for each target.

There is a RuntimeUnityEditor.Core directory, a RuntimeUnityEditor.Core.Mono directory, a RuntimeUnityEditor.Core.IL2CPP directory, a RuntimeUnityEditor.Bepin5 directory, a RuntimeUnityEditor.Bepin6.IL2CPP directory and a RuntimeUnityEditor.UMM directory, alongside the solution file, a Directory.Build.props, a modules directory, an install.ps1 and a nuget.config. So the core logic and the per loader shells are separate projects, which is how one feature set can be compiled for three different hosts.

The steps are: get Visual Studio 2019 or later, clone the repository recursively, and open the solution and build all. If you already have the repository cloned, or you want to update the mcs submodule, you need to run git submodule update --init --recursive.

git submodule update --init --recursive

The mcs submodule is the C# compiler the REPL uses, and the note about the submodule is the same one as the known issue: the console backend has to be updated independently of the tool.

The final note explains an unusual choice. An old version of UnityEngine.dll, from before 2017, is used for compatibility with all Unity versions 4.x and above, because the new UnityEngine.dll in 2017 and later forwards all of the split types into their new respective dll files. In other words, the project compiles against a deliberately stale reference assembly so that a single build works across a decade of Unity versions, at the cost of not being able to use anything added to the newer engine assemblies.

GPL-3.0, and what that means for a modder who ships a build

The licence is GPL-3.0, and for this particular project that is a practical fact rather than a legal footnote.

A modder who installs a build of Runtime Unity Editor into their own game directory for their own use is not distributing anything, and the licence obligation does not bite. A modder who packages the plugin into a build they give to other people, or publishes a mod that includes it, is distributing, and the GPL requires that the corresponding source be made available to the recipients along with the licence. A permissively licensed project such as an MIT one still requires the copyright notice to be kept when a build is redistributed.

That is a real constraint on how the tool is used, and it is worth knowing before you pick a build to ship rather than one to keep on your own machine.

The project is also supported through the author's Patreon page, and the description asks for support that way. The rest of the repository is a normal GitHub project with a.github directory, a.gitmodules file for the mcs submodule, a nuget.config and a LICENSE.

The release cadence is fast, with three releases in the last ten weeks of the 2026 releases listed, and the version numbers follow the pattern of the per loader builds, where the same feature set ships as a mono build and an IL2CPP build. The last push was on 2026-10-17, after the v6.3.2.1 release.

Editorial conclusion

Adopt Runtime Unity Editor if you are debugging or modding a Unity game and want to inspect and edit live objects, script a console and dump state without attaching a separate debugger, and you are comfortable with a tool that injects itself into a process. Do not adopt it for a game you do not have permission to modify, and do not ship a modified build without reading the GPL-3.0 licence, since distributing a build carries obligations that a permissive licence would not. Before you install, pick the build that matches your mod loader and runtime, and check the known issues list, because the IL2CPP build is explicitly unstable and the C# console does not work in recent Unity versions at all.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. ManlyMarco/RuntimeUnityEditor on GitHub
4. README
5. Releases