Rust Plugins Missing After an Update: Framework, Plugin or Dependency?

Short answer: After a Rust update, first check which framework is actually running. With Oxide, oxide.version, oxide.plugins and the startup log tell you. If only one plugin is missing, tell a compiler error, a missing dependency and a configuration error apart. Plugins that load do not rule out a framework problem. Back up files and the save before you change anything; a wipe or deleting all configs is not a sensible first diagnostic step.

This guide applies to Rust Dedicated Server for PC, self-hosted or with any provider. For the admin steps you need access to the real server console or authorized RCON, and possibly to the server files. You do not need a SupremeTier account. If you only play on the affected server, start with the next section.

Last checked: October 29, 2026. The commands in the main flow refer to Oxide. Carbon is covered separately. The failure paths "a single plugin does not compile" and "a dependency is missing" were triggered on purpose and repaired on our own isolated test server. These tests simulate failure states; they are not an observation of a third-party plugin breaking after the update. A deliberately mixed framework state was also tested in isolation. Plugins loaded while a framework hook failed. The original output below comes from controlled failure tests and is not presented as a natural incident on a customer server.

As a player: what can you do?

A missing /kit menu does not prove that your inventory was deleted. Perhaps only the plugin that provides the command is missing. First ask whether other players miss the same feature and whether several unrelated features are affected. Note the time, the command you typed and the response you saw. A screenshot of a message helps; you can cover private player names before you pass it on.

Report it like this, for example: "Since the restart around 7 pm, my kit command gets no response. Teleport doesn't work either. Building works normally. Both worked before the restart." That lets the admins look for the matching startup run. The statement "Everything was wiped" would go too far without checking.

Do not install random client files that someone offers as a fix for a server plugin. As a player you cannot reload the server-side framework. If protective features are missing, such as the PvE rules promised on this server, do not rely on them until the issue is resolved. The admins have to decide whether normal play is safe.

First, separate the three layers

For this diagnosis, a modded Rust server consists of three layers. Rust itself provides the world and the gameplay. The framework, here Oxide or alternatively Carbon, makes extensions possible. Individual plugins implement things like kits, teleport, admin tools or changes to game rules. Some plugins need further plugins or extensions.

When a lower layer is missing, many features above it seem broken at the same time. When a single extension fails, the others can keep working. This distinction is the starting point, but not yet proof: several plugins can also depend on the same missing library. Conversely, a framework can respond and still have problems with certain game events.

"File present", "compiled", "loaded" and "working" are four different states. A .cs file in the right folder only proves that source code is there. Compiling means executable code was produced from it. Loading includes initialization. Only a targeted function test shows whether the desired behavior actually works with your settings and permissions.

The official Oxide documentation on installing plugins describes .cs files, automatic compilation and the plugins directory. Do not confuse this file level with visible success in the game.

The quick decision path

Once the server has finished starting, begin in the server console, not in the normal game chat. This first check does not change any plugins:

oxide.version
oxide.plugins

oxide.version queries the framework version. oxide.plugins lists plugins, including failed load attempts. The official command reference describes the plugin list and the targeted load commands; the owner guide to commands explains console and chat.

An unknown command is a clue, not a finished diagnosis. Check that you really opened the console of the affected server, that startup has finished and that this server uses Oxide at all. On Carbon, an Oxide-specific test alone is not a sufficient basis.

Before any repair: secure evidence and a way back

A good diagnosis starts with a short inventory. Write down when the error was first noticed, which game update or restart came before it, and what has been changed since. Save the complete startup log from process start to the first error message. A screenshot of the last red line is often not enough, because it only shows the follow-on error.

Oxide also writes load and compiler errors to its own log files in the oxide/logs folder of your server installation. A message there is often more complete than in the visible console excerpt, for example when the console only shows the last lines. Pick the file whose date matches the affected start and save it together with the console log.

Note the Rust version or build information, the release branch, the operating system, the framework version and the versions of the affected plugins. Keep the download source of the installed files. "Latest version" is not a reproducible version statement: the file may have been replaced since your download, or your startup script may load a different state than expected.

What belongs in the backup?

Back up a consistent set of world and player data, startup configuration and modding files. With Oxide, oxide/plugins, oxide/config and oxide/data in particular belong in the inventory; also consider permission data and your own extensions. The exact storage layout depends on the installation. Check the paths you actually use instead of blindly copying an example directory.

Separate settings from payload data. A config, for example, determines how a plugin behaves; its data can contain rewards already handed out, saved positions or other persistent state. The content depends on the plugin. Blanket-clearing oxide/data can therefore change more than the broken feature.

For a consistent backup, use the documented backup procedure of your installation. A copy made during ongoing writes can be inconsistent. Check that the backup actually finished and can be retrieved. Unpack or inspect it in a separate location without overwriting the current server. A backup name in a list is not yet a verified way back.

Set the boundary of your change

Before you intervene, write down: "I am only replacing this plugin file" or "I am reinstalling the Oxide package that matches the current Rust build". That includes the backed-up old file, the new file and the success criterion. Do not change the framework, several plugins, configs and map parameters at the same time. Otherwise you will not know afterwards which change helped or did damage.

If a protection, economy or access plugin fails, decide on the server's availability before testing. A world that is technically reachable is not automatically playable under the promised rules. Announce a necessary interruption and use your installation's regular stop procedure. Repeated hard kills are no substitute for a diagnosis.

Case A: the framework fails

Typical situation: The server starts after a game update, but numerous unrelated plugin features are missing. Oxide is not visibly successful in the current startup log, or the version query in the correct console context returns no framework version.

The cause to check is not just "Oxide is too old". The game update can replace modified files; a startup script can then restore vanilla files again; the framework may have been unpacked into the wrong server directory. A package for the wrong operating system, a mismatched game branch or an incomplete upload are also possible.

In its guide to creating a dedicated server, Facepunch explicitly points out that a game update can require reinstalling Oxide and that SteamCMD in the startup routine can reset files to vanilla. That gives you the important order: update the game, install the matching framework build, then start the server. Another game file validation after the framework installation can undo the work.

Order for self-hosted servers

On a self-hosted server with SteamCMD, the order looks like this. The path is an example; use your actual server directory:

steamcmd +force_install_dir /path/to/rustserver +login anonymous +app_update 258550 validate +quit

258550 is the app ID of Rust Dedicated Server. validate checks the game files and restores the vanilla version in the process. That is exactly why Oxide comes afterwards: from the official Oxide.Rust release, download the archive for your operating system, Oxide.Rust-linux.zip for Linux or Oxide.Rust.zip for Windows. Unpack it with its folder structure into the server root, the folder that also contains RustDedicated or RustDedicated.exe, and let it overwrite existing files. Only then start the server and check oxide.version.

If your startup script runs SteamCMD before every start, it replaces the Oxide files again on every restart. In that case, the Oxide installation belongs in the startup script as well, between the update and the server start, or you take the automatic update out of the startup script. With managed hosting, use your provider's framework feature instead.

Putting October 2026 in context

The uMod changelog for Rust lists, under October 2026, a patch for the Rust update of October 22 with the value 2635.289.1. Several earlier October hotfixes are listed as well. This value from the changelog is not an Oxide package version number and not a guarantee for every later server state. The matching official Oxide.Rust release 2.0.7839 was published on October 22, 2026 at 18:02:03 UTC. When we last checked on October 29, 2026, it was still the newest Oxide.Rust release. On our isolated test server, version and oxide.version later actually reported Rust protocol 2635.289.1 and Oxide.Rust 2.0.7839. That is one specific test combination, not a standing recommendation to keep these numbers after later updates.

When you actually make the change, check the current release and your server's Rust build again. A matching release note does not prove that your provider or startup script has already installed that version. What counts is the version read from the running instance afterwards, together with the current startup log.

Our own test A: a framework error even though plugins load

Our starting point was Rust protocol 2635.289.1 with the matching Oxide.Rust 2.0.7839. After a regular stop and a backup of our own test world including the Oxide directory, we deliberately inserted, only on the isolated test server, the old Oxide.Rust.dll from the official release 2.0.7072 of February 19, 2026. The rest of the current installation stayed in place. This simulates a mixed, mismatched framework state; it is not a test of a complete historical server package.

The change was verified via the SHA-256 of the DLL actually inserted. On startup, this real message appeared:

Failed to call hook 'IOnServerCommand' on plugin 'RustCore v2.0.7072' (MissingFieldException: Field not found: string .Arg.FullString Due to: Could not find field in class)

At the same time, our own test plugins reached their initialization markers. The server process kept running as well. That is the important difference from an overly simple rule of thumb: a framework problem does not have to stop all plugins from loading. A successful plugin list or a running process is not a complete compatibility check.

The message names RustCore, a framework component, and a field access that could not be found. It is not a JSON error in a kit configuration. In this deliberately created combination, the cause lies in the mismatched framework state. An error of the same type under a different name, however, can come from a single plugin; always read component, hook and context together.

For the minimal rollback, we restored the previously pinned matching DLL 2.0.7839 and restarted in a controlled way. Afterwards, oxide.version again answered with 2.0.7839, oxide.plugins listed all four of our test plugins, and the previously observed MissingFieldException was no longer present in the new available console buffer. The way back to the matching framework is therefore verified for this specific test. For your production server, this does not mean you should piece together individual DLLs from arbitrary archives: use the complete matching framework installation there so that the state is consistent.

The test deliberately uses a much older release. It claims neither that every older version fails the same way nor that exactly this error appears with every October update. A framework failure can also simply mean vanilla without Oxide loaded. That is why the combination of the actual version, the first log diagnosis and a function test is still necessary.

Minimal repair

1. Save the starting state and the log. Check whether an automatic updater is currently running. Do not start a second, competing installation.
2. Match the Rust build, release branch, operating system and the framework release intended for them.
3. Stop the server regularly if the installation requires changes to the framework files.
4. Use the documented installation path. When self-hosting, unpack the trusted, matching archive into the correct installation while keeping its directory structure, in the order described above. With managed hosting, use its framework feature; do not apply another provider's panel menus to yours.
5. Check the update order and start once in a controlled way. Read the new startup log.
6. Check the framework version, the plugin list and at least one feature that failed before.

Success: The expected framework responds from the correct instance, the expected plugins load, and the tested feature works. Way back: Keep the state from before the change. Do not blindly copy an old framework file back over a new game. If only an older complete package was compatible, its restorability, including world format and client compatibility, has to be checked separately. If that is unclear, the server stays out of operation in a controlled way until a matching version is available.

Case B: a plugin does not compile

Typical situation: Oxide responds, other plugins load, but one specific plugin shows up as failed. The log names a compiler error, often with file, line, column and a missing symbol or a method that no longer fits.

A compiler error initially only means: the source code at hand cannot be compiled against the available references. A game update may have changed an interface it uses. But a corrupted download, your own modified code or a missing hard dependency are also possible. "Failed to compile" therefore does not automatically mean "the author just needs to release a new version".

Our own test B: a compiler error

On our isolated test server with Rust protocol 2635.289.1 and Oxide.Rust 2.0.7839, only the test plugin Guide7CompileBroken.cs contained a deliberate #error line. The already loaded control plugin Guide7Probe stayed separate from it. The real console output was:

Error while compiling Guide7CompileBroken: #error: 'GUIDE7_INTENTIONAL_COMPILE_FAILURE' | Line: 1, Pos: 8

For the minimal repair, we removed only the deliberately inserted error line. Afterwards, the console reported:

Guide7CompileBroken was compiled successfully in 362ms
Loaded plugin Guide7CompileBroken v1.0.0 by Guide7 isolated test fixture

The way back for this controlled test is to restore the unchanged broken file; that would produce the same deliberate compiler error again. For a real third-party plugin, "delete some line" is explicitly not a repair instruction. Our test demonstrates the separation between framework and plugin compiler, not a specific API break caused by the October update. The 362 ms we observed describe only this single test, not a general load time.

In the real log, in the console or in oxide/logs, first look for the name of the affected file and the first compiler diagnostic. A later "plugin could not be loaded" often just repeats the result. Check whether several plugins name exactly the same missing symbol: then a shared API change or reference may be affected rather than several independent defects.

Download an update only from the plugin's documented source. Read the change notes: do they fix your problem, require a new dependency or change the data format? A higher version number alone does not guarantee compatibility with your combination.

Minimal repair

Back up the previous .cs file as well as the related config and data. First replace only the affected plugin with the intended corrected version. Oxide normally watches the plugins folder for changes; so avoid duplicate uploads and hectic extra reloads. Follow the process in the console and then check the actual state.

If a targeted reload is necessary, the form is:

oxide.reload PluginName

PluginName here stands for the actual plugin file name without .cs, not for the marketing title of a download. The official command reference documents this targeted reload. Do not use a wildcard reload of all plugins while narrowing down the problem. It changes unnecessarily many states and can create new errors.

Success: The compiler diagnostic disappears, the expected plugin version loads, and the specifically affected feature passes the test. Way back: If the update fails, save this new log too. Restore the old plugin version along with the required data state only if that combination fits the current game. An old file that was already broken after the game update is not a working rollback.

If no compatible fix exists, it can make sense to temporarily disable only the affected plugin. First check which other plugins and game rules depend on it. With the server stopped regularly, move the backed-up source file out of the watched plugins directory into a separate backup folder. Do not delete the config or payload data. Document which feature is missing until the repair.

Case C: a dependency is missing

Typical situation: A plugin names a missing requirement. Other features keep working, or several failed plugins depend on the same library. The missing file may even be present but fail to load itself.

The Oxide guideline on dependencies distinguishes optional, required and hard dependencies. An optional integration extends behavior. A required dependency is needed for the feature. A hard dependency can prevent compilation in the first place. These terms explain why "dependency missing" and "compiler error" can overlap.

Our own test C: a missing dependency

On the same test server, our own test plugin Guide7Consumer.cs was loaded with the declared requirement // Requires: Guide7Dependency. The corresponding dependency was deliberately not installed at first. This is real output from the controlled test:

Guide7Consumer plugin requires missing dependency: Guide7Dependency
Ignored unexpected plugin compilation failure: Guide7Consumer
Error while compiling Guide7Consumer: Missing dependency: Guide7Dependency

Here, too, it says "Error while compiling". The decisive addition, however, is the explicitly named missing dependency. We installed only Guide7Dependency.cs and then reloaded the consumer in a targeted way. Afterwards both initialization markers and both load confirmations appeared:

[Guide7Dependency] GUIDE7_DEPENDENCY_READY
Loaded plugin Guide7Dependency v1.0.0 by Guide7 isolated test fixture
[Guide7Consumer] GUIDE7_CONSUMER_READY
Loaded plugin Guide7Consumer v1.0.0 by Guide7 isolated test fixture

The markers prove the initialization of both test plugins, not a shop, teleport or protection function test of a third-party plugin. To roll back this test, only our own dependency would be removed after unloading the consumer. Reloading the consumer over and over does not install its requirement. If, in your real log, the dependency itself fails first, fix its first error first. A similarly named library from a random download source is no substitute.

Check the plugin page and documentation for the exact name, the type of dependency and any required versions. Another .cs plugin and a compiled extension are different things. They can have different install locations and restart requirements. For extensions, follow their own installation instructions; do not copy a DLL into oxide/plugins on a hunch.

Minimal repair

Build a small chain: affected plugin → required dependency → status of that dependency. Check the dependency in the plugin list and in the startup log. If it is actually missing, install exactly that one from its official source. If it is already present, fix its first error instead of uploading the same file again and again.

For an ordinary plugin dependency, you can then load first the dependency and then the consumer in a targeted way, provided their documentation supports that flow. For an extension or changed startup initialization, a controlled restart may be necessary. Treat a restart as a verifiable step with a new log, not as an automatic cure.

Success: The dependency and the consumer load in the intended versions; the feature that connects them works. A mere list of two loaded plugins is not enough for that. Way back: Restore the backed-up compatible combination or disable the consumer as long as its requirement is missing. Before a downgrade, check whether the new version has already rewritten configs or data.

Loaded, but not working

When a plugin shows up as loaded, switch from installation diagnosis to function testing. First check whether you are testing the right feature with the right account. An admin can have different permissions than an ordinary player. The result of a single admin attempt therefore cannot automatically be transferred to all players.

Then check the documented permissions and settings. Are the required feature, world, zone or user group enabled? Are there conditions such as a cooldown, combat status or an in-game prerequisite? These examples are possible areas to check, not a claim about every plugin. What matters is the documentation of exactly your extension.

A successful start also does not prove that every hook works. A hook is a connection point to a game event provided by the framework. If such an interface changes, a plugin can load and only fail, or stop reacting, when the relevant event happens. So repeat the actual trigger and watch the log at exactly that moment.

For a runtime exception, save the complete relevant stack trace and the action before it. Changing many permissions "for testing" is not a good substitute: it can widen access and hide the original error. A clean comparison uses one defined account and documented permissions.

Why deleting configs is rarely the right start

A configuration file can actually be faulty. Signs include, for example, an explicitly reported JSON parse error or an error right when a setting is read. A compiler error about a missing game method, on the other hand, is not repaired by resetting all configs.

The Oxide guide on configuring plugins also warns about plugins that write settings back when they unload. An edit made while the plugin is running can then be overwritten. Back up the file, follow the plugin's instructions and unload it before editing if necessary.

First check JSON locally with a suitable validator. Confidential values such as credentials or webhook addresses do not belong in public online validators. Valid JSON is only the syntax check, though: a cleanly written field can still contain an invalid value or an outdated schema.

If you need a fresh config for comparison, work in an isolated copy if possible. Keep the original file unchanged. Then compare individual settings and take over only changes you can explain. A full reset can change rules, prices, permission references or other plugin-specific settings without it being noticeable in the first function test.

No wipe as a plugin repair

A wipe affects the save or selected progress data. A plugin compiler error affects code and its requirements. These are different layers. A new world does not bring back a removed API method and does not install a missing library.

An error appearing on wipe day does not prove a connection to corrupted world data. Game update, framework update, plugin update and wipe often happen in the same maintenance routine. Separate these events on your timeline. Also check whether a different server identity or a different data directory was used after the restart.

If a world or data problem is actually suspected, that is a separate diagnostic task with its own backup and its own success criterion. Do not carry it out as a casual last step of a plugin repair. Before restoring an older backup, it must be clear which progress made since then would be lost and whether that state is compatible at all.

Carbon: the same diagnostic idea, its own installation path

If the server uses Carbon, start with its version query:

c.version

The Carbon configuration and the official release notes document Carbon's own features and version information. Use the commands and paths of your actual Carbon installation. A failed Oxide command alone does not prove a framework failure there.

The basic questions stay the same: is the framework running? Which extensions are actually loaded? Is a single consumer failing or a shared requirement? Which feature was really tested? It does not follow, however, that every Oxide plugin works unchanged under every Carbon version or that switching frameworks is a risk-free instant fix.

Do not switch between Oxide and Carbon on the side while narrowing down a problem. A migration changes several requirements at once. Plan it separately, back up data and permissions, and test the plugins you need. For a single compiler error, the smallest matching change is usually easier to follow than a complete platform switch.

The three cases side by side

This comparison shows the diagnostic flow, not measured repair times. Not every error fits neatly into one row. A missing DLL reference target, for example, can trigger a compiler error. Classify by the first proven cause, not by the last red message.

How to verify the repair properly

Before the change, define a small test that makes the original failure visible. For a kit plugin, that would be, for example, a documented claim with a test account set up for it and a known test kit. For a protection plugin, the protection promised beforehand has to be tested under controlled conditions. Do not use other players' bases or real in-game economic values for this.

Then compare the same test before and after exactly one change. Note the account type, relevant permissions, plugin version, settings, action and result. Also check a neighboring feature that was not broken. That way you notice when a repair fixes the visible problem but changes another central rule.

A sensible wrap-up covers five questions:

• Does the expected framework respond from the correct server instance?
• Do the plugin versions actually loaded match the intended state?
• Has the first error disappeared from the new log without creating a different one?
• Does the specific use case work with the matching user account?
• Does the result persist after the next planned controlled start?

The last point checks the installation order and startup automation in particular. Do not force an unnecessary extra restart during live play for it. If this proof is still pending, document the repair as functionally verified with the startup proof outstanding.

A helpful error report

Do not send a collection of unsorted screenshots. A short, reproducible report speeds up the narrowing down. The Oxide notes on reporting issues recommend environment details, steps, expected and actual results, and relevant logs.

Affected feature:
First observed error with date and time zone:
Rust build and release branch:
Framework and the version actually read:
Plugin name, version and download source:
Required dependencies and their status:
Last change before the error:
First complete error message:
Steps to reproduce:
Expected result / actual result:
Single change already tried and its result:
Available backup and way back:

Remove passwords, tokens, webhook addresses and personal data that isn't needed from the copy. Keep the unchanged original protected for yourself. A cleaned-up log copy should preserve the technical cause: do not accidentally remove the plugin file name or the error message needed for the diagnosis.

Send the request to the right place. For a wrong installation order or a framework that cannot be selected, hosting support can help. For a reproducible error in a single plugin, its developer is often the right contact. If several layers are unclear, send your findings instead of assigning blame prematurely.

Before the next Rust update

Keep a small inventory of your critical plugins and dependencies. Record which game rules do not apply without them and which features are merely convenience. That way, after an update, you can check the things that matter most to your community first instead of touching every extension alphabetically.

Before planned changes, back up a traceable state and keep the related version information. Check current notices from the framework project and the most important plugin developers. Do not rely on a fixed waiting time: a release can appear quickly, but a specific plugin may still need an update.

Also check what your startup script or provider automates. Does it update Rust, the framework, both or neither? In what order? One host may do this on every start, another through a separate update feature. Another panel's instructions do not automatically describe your server.

For larger communities, a separate test routine with known test data is worthwhile. A test has to use the same relevant versions and settings; otherwise its success says little. Document the limits of the test instead of deriving general stability promises from an empty test server.

FAQ

Do I have to restart the whole server after every plugin update?

Not as a rule. Oxide supports automatically detecting plugin changes and targeted reloads. Framework files, extensions and certain initialization routines, on the other hand, can require a restart. What matters is the documentation of the affected component. After a reload, check the log and the feature; an accepted command alone is not enough.

All plugins are missing. Is Oxide definitely to blame?

No. It is a strong lead, but check the console context, a complete start, the framework selection, the server instance and shared dependencies. A wrong data directory or several plugins with the same requirement can also look like a total failure. Only the combination of findings narrows the error down reliably.

Does a restart help as soon as a new framework has been released?

Only if your installation routine actually installs this framework during the restart or you updated it correctly beforehand. When self-hosting, a restart alone is not a download. Compare the framework version you read afterwards with the intended state. If it is unchanged, investigate the update path.

Can I delete the config and let it be recreated?

A new config can help as a comparison in a backed-up test copy. As a blanket repair it is unsuitable and can reset your own rules. Look for a specific configuration error first. Back up the original and the data, and note whether the plugin writes settings back when unloading.

Why does a plugin still show as loaded after the update but not work?

Loading is only one stage. The specific feature can fail because of permissions, settings, a dependency needed only later, or a changed hook. Test the trigger under controlled conditions and read the log at the same moment. Do not claim the feature is repaired based on the list entry alone.

How long do I have to wait for Oxide or a plugin fix?

A fixed duration cannot be promised in good faith. Check the current release channel and the status of the affected plugin. If a critical protection is unavailable, decide on a safe operating state for the server instead of trusting an estimated time.

Can I simply go back to an older version?

Only with a verified compatible combination and a secured way back. An old framework plus a new Rust build can fail again. A new plugin version may have changed data that the old version does not understand. Additionally back up the current state and check data compatibility before you roll back.

Terms that often appear in the log

Framework: The base for the extensions, such as Oxide or Carbon. Plugin: A single extension with a specific function. Compiler: Translates the plugin source code into executable code. Dependency: Another component an extension needs. Extension: An additional framework extension, often a compiled library with its own installation path. Hook: A connection point to an event in the game. RCON: Authorized remote access to the server console. Rollback: A verified restoration of an earlier, consistent state. Wipe: Resetting selected game progress; not a general plugin repair.

Your most sensible next step on the affected server is small: save the current startup log, check the framework that is actually running and follow the first error message. Only then decide which single component needs to change.

Sources and verification

• Oxide.Rust releases on GitHub: release 2.0.7839 of October 22, 2026 ("Patch for October 22nd Rust update (2635.289.1)") and release 2.0.7072 of February 19, 2026.
• uMod changelog for Rust: October entries including the update of October 22, 2026.
• Oxide documentation: plugin installation, oxide/logs, commands, configuration, dependencies and issue reports.
• Facepunch guide to the dedicated server: SteamCMD, app ID 258550 and Oxide after game updates.
• Carbon documentation: version command and configuration.

Verified: October 29, 2026. The three failure tests ran on October 29, 2026 on our own isolated test server with Rust protocol 2635.289.1 and Oxide.Rust 2.0.7839; the test server was deleted afterwards. After every further Rust update, these version numbers are only an example.