Why do my key rebindings reset every time I restart?

Because the rebinding round trip breaks: the new bindings aren't saved to persistent storage when changed, are saved but not loaded on startup, or, commonly, are loaded but not actually applied to the input system (so the defaults remain active even though the custom bindings were read). Each break leaves the player with default bindings after restart.

Why are my rebindings saved but not used after restart?

That's the 'loaded but not applied' case: the saved bindings exist and may even be read on startup, but they aren't pushed into the active input system, so the game keeps using the default input map. The fix is to actually apply the loaded bindings to the input system on startup (configure the input map with them), and ensure that application isn't overwritten by defaults set up later in startup.

How do I make key rebindings persist?

Complete the round trip: save rebindings to persistent storage when changed, load them on startup, and apply them to the active input system (not just read them into a variable). The most-missed step is applying loaded bindings to the input map, so the game actually uses them. Verify by rebinding, restarting, and confirming the custom bindings are in effect, and ensure defaults don't clobber loaded bindings during startup.

How to Fix Key Rebinding That Won't Save

Quick answer: When key rebindings don't persist, the custom bindings aren't completing the round trip: they may not be saved when changed, saved but not loaded at startup, or loaded but not actually applied to the input system (so the defaults remain active). Check that rebindings are written to persistent storage on change, loaded on launch, and applied to the active input map, and fix wherever the chain breaks.

Rebindings that reset every launch are a frustrating accessibility and convenience failure, players who remap controls (often out of necessity) have to redo it every time. It's a specific case of settings not persisting, applied to the input bindings, and it usually breaks at one of the same points: saving, loading, or applying the bindings.

Why Rebindings Don't Persist

Custom key bindings need to round-trip: when the player rebinds, the new mapping should be saved; on launch, it should be loaded and applied to the input system so the game uses the custom bindings. Rebindings 'won't save' when this breaks. Not saved, the rebinding changes the in-memory input map but isn't written to persistent storage, so it's lost on exit. Not loaded, the bindings are saved but the game doesn't read them on startup. Or not applied, the bindings are loaded but not actually applied to the active input system, so the default bindings remain in effect even though the custom ones were loaded.

The 'loaded but not applied' case is common and sneaky: the saved bindings exist and are even read, but the input system still uses defaults because the loaded bindings weren't pushed into it. Each break leaves the player with default bindings after restart.

How to Diagnose It

Test the round trip. Rebind a key, then check whether the new binding is actually written to persistent storage. If not, saving is broken. If it is saved, restart and check whether the game loads it and whether the game actually uses the custom binding, if the saved binding is present but the default still works (and the custom doesn't), it's loaded-but-not-applied (or not loaded). This pinpoints the broken stage.

Rebinding-persistence issues are usually reproducible locally by testing the round trip, and reports are clear ('my key bindings reset every time'). Capturing reports (Bugnet collects them with context) confirms scope and any platform pattern, but the core diagnosis is testing rebind-restart-check yourself.

How to Fix It

Fix the broken stage of the round trip. If rebindings aren't saved, persist them to storage when changed (handling write failures), like any setting. If they're not loaded, read the saved bindings on startup. Critically, if they're loaded but not applied, apply the loaded bindings to the active input system on startup, actually configure the input map with the custom bindings rather than just reading them into a variable while the input system keeps using defaults. Ensure the application happens after loading and isn't overwritten by defaults set up later in startup.

Verify the full round trip: rebind several keys, restart, and confirm the custom bindings are in effect (not just saved, but actually working). Test that it persists across sessions and that defaults don't clobber loaded bindings during startup. Reliable rebinding persistence matters especially for accessibility, players who remap out of necessity depend on it, so getting the save-load-apply chain right (with emphasis on actually applying loaded bindings to the input system) removes a real barrier.

Rebindings that won't save break at save, load, or apply, often loaded but never applied to the input system. Make sure loaded bindings are actually pushed into the input map at startup.