Open it with the Check Conflicts button on the Keybind tab or with /gems keys. It lists every key bound to a sequence on your current spec, plus the vehicle bar and pet battle slots, and reports four things about each one: what your saved key bindings have on it, what the keypress actually reaches, whether a modifier on that key redirects your casts, and whether a click binding holds it. Each gets its own row, including the ones that came back clean, because a check that found nothing is worth seeing too. Where the addon that made a binding can be named, the row names it and the file and line it came from. The verdict on a key is decided by what the keypress reaches, so a saved binding sitting underneath a working sequence key reads as covered rather than as a conflict. Four severity filters narrow the list, a box at the top checks any key you type, and a block headed "What this check cannot see" is on screen at all times, whether or not anything is wrong.
GRIP-EMS v2.4.0
Released August 14, 2026. 15 entries in the author's notes.
Every entry
The author's own words, complete. Long sections are sorted into areas by LazyGrip.
Added
5Two kinds are fixable from here: a saved key binding that owns the key, and a modified-click action set to redirect your casts. Those rows get a Fix button, and Fix All does the whole list after telling you the exact number it is about to change. Undo puts back the last binding the panel changed, and if something else has claimed that key since, it leaves the key alone and says so instead of overwriting. Every fix re-reads the binding immediately before writing, so a key that moved between the check and the click is left untouched. In combat the change is queued and lands the moment you leave. The cast-redirect fix clears only the three redirect actions on that key, so shift-clicking to link an item still works. A key held by another addon's override binding cannot be taken back by any addon, and that button is greyed with a tooltip saying so.
Off is what sequences have always done: every press advances the step counter, mid-channel or not. Hold cursor stops the counter while you are channeling, so the press casts nothing and the sequence holds its place through a channel you are already running. Hold + release at max does the same and adds one thing for empowered spells: once the cast reaches maximum rank, the next press ends it there instead of letting the rest of the hold window run down. The control appears only if your spellbook contains an empowered spell, or if the sequence already carries the setting, so an import from another character does not leave an invisible flag on a character that cannot use it. The check is against your spellbook and never against your class, so any character with an empowered spell gets it. The hold by itself applies to any channel from any source. Known issue on release at max: on at least one tester's client the empower ends at the first rank instead of at maximum, on every press, with nothing on screen to say so. It does not reproduce on the development client and the cause is still open, so if your empowered casts are ending early, set that version back to Hold cursor.
Three rows in the Repair panel for the setting above. One flags a version whose steps carry a channel conditional and an empowered spell but no channel hold. One notes that Empower Tap Controls is turned on, which changes how empowered spells fire everywhere in the interface and not only in macros. One points out a version that has the hold on and could use release at max. None of the three applies itself, because all three change what the sequence casts.
For plugins: the API version is 4. API:GetActiveSequence() returns the name of the sequence the engine last drove, and the GetAuthoredSteps accessor that shipped in v2.3.7 is now listed in the capability set, so a plugin can find it without probing for the function. The version number now moves on any addition, not only on a breaking change, because a method added quietly mid-version left plugins with no reliable way to ask whether it was there. Nothing changes unless you run a plugin that uses it.
Fixed
6Changing a variable's definition is meant to rebuild every sequence that uses it and throw away anything already built from the old definition. The listeners that do that work were reading the wrong part of the message: they took the variable's new value where they should have taken its name, so they went looking for sequences filed under a name that does not exist and found none. Nothing looked wrong and no error appeared; the old definition simply kept casting until the next reload. Creating and deleting a variable were worse, because those messages carry only a name and no value, so the listener received nothing at all and the cached copy was never cleared. All of it is reading the right part of the message now.
Same cause, in the queue that holds back changes the game will not let an addon make during combat. Its listener was reading the setting's value where it should have read the setting's name, so it never recognised its own setting: the timer kept running at whatever interval it started the session with, no matter what you set. The related option that flushes pending changes the moment you leave combat was on the same listener and never triggered at all.
Six things were meant to happen the moment the game finishes telling the addon which spells you have: repairing sequences after you change the game's language, refreshing spell names after a hero talent change, the same for variables, retrying a sequence whose spell could not be looked up yet, rebuilding the sequences that use the new release-at-maximum setting, and applying a change to the sequence reset modifiers to buttons that are already loaded. All six were hooked up at the wrong moment during start-up, before the part of the addon that carries these messages had been built, so the hook-up quietly did nothing and not one of the six has ever run for anybody. They are connected at the right point now. If you have ever had a sequence stay stuck on the wrong spell name after switching language or hero talents, or needed a second reload before a sequence would work, this was why. The reset modifier setting had a second, separate fault on top of that: it was reading the setting's value where it should have read the setting's name, so even once connected it would not have recognised its own setting. That is fixed too.
The reset timer, the reset modifiers and the channel-hold settings are written straight onto the live button, which the game forbids during combat. That write was skipped and nothing retried it, so the setting sat unapplied while the step changes from the same edit landed normally. It is queued now and applied the moment you leave combat, reading the settings as they stand at that point rather than as they stood when you made the change, so a second edit in the same fight wins.
When an issue cannot be repaired automatically the Fix button is greyed out and carries a tooltip naming the exact setting to change and where to find it. A greyed-out button in this game fires no mouse scripts unless it is told to keep watching for them, and it never was, so that text has been on screen for nobody since the Repair panel shipped in April.
CRIT, ERR, WARN and INFO were written into the code as English text instead of being read from the locale files, so every player on a non-English client saw four English words in a panel that was otherwise in their own language.
Internal
4The colour-palette guard checks every file the .toc loads, not the two folders it was pointed at, which took it from 48 files to 109, and it compares survival file by file rather than directory by directory.
A check that catches time-bound wording in translated strings, with its allowlist left out of the published package.
The four game-setting descriptions covering empowered spells no longer name Evoker. Detection has always been a test against your spellbook and never a check on your class, so naming one class stated something the code does not. The corrected English was copied into the translated files, which had been left on the old wording.
Giving sequence keybinds priority over other bindings was investigated and rejected. Three separate paths already depend on the current precedence, and one of them would have produced a pet battle key that stays dead until the state corrects itself. The binding calls are pinned by a test so the question is not reopened by accident.
Grab it
Release notes written by Sataana and reproduced here with his permission.