Does GRIP-EMS work on WoW: Forever?
What is confirmed
As of September 18, GRIP-EMS loaded on WoW: Forever without any changes. Forever's .toc interface number is 16001, which Sataana added to the addon's .toc in v2.4.18 on September 17 as groundwork for this client (the number was read out of a shipped addon listed under the store's own Forever flavor, and that release post said it had not yet been confirmed on a running client), so the addon passed Forever's interface check with the file exactly as it shipped then. Sataana confirmed this directly and had gotten the addon running in-game on the beta client himself.
That was true of the build Sataana tested in September, and it stopped being true with v2.4.20. According to the v2.4.21 changelog, v2.4.20 stopped at a Lua error at every Forever login because two spec functions it calls are gone from that client (GSE, which has its own Coming from GSE page in this guide, hit the same kind of break, and its 3.3.35 release notes say Forever build 1.60.1.70338 removed the global GetNumSpecializationsForClassID, though we do not know whether that is one of the two functions GRIP-EMS called), and nothing after that point in the login ran, so the settings panel never registered, sending and receiving sequences did not work, and plugin sequences, the tracker HUD and the floating menu never loaded. Selecting a sequence stopped with an error before its Keybind tab loaded, which meant there was no way to bind a key to it. v2.4.21 fixes that, and the October 17 announcement in the GRIP-EMS Discord says it loads clean on the beta. The v2.4.20-hotfix from October 14 is v2.4.20 plus two fixes for patch 12.1.5, the loading and the spell picker's item lists, with no Forever fix listed, so read it as still falling over at a Forever login, which is a reading of that release post and not something anyone has tested. If you tried GRIP-EMS on the Forever beta on v2.4.20 and it fell over, that was the addon and not the beta, and updating is the fix. The v2.4.22 files we checked on November 2 agree with the changelog on the listing side: the .toc names Forever's interface number 16001 next to the retail numbers, and the guide that ships inside the addon gives its requirements as retail 12.0.1 or later, or WoW Forever 1.60.1. The changelog adds that v2.4.21 stops a spell catalogue notice from printing at every Forever login, because Forever's builds do not match the retail build that list comes from. v2.4.22, released November 1, adds more Forever fixes according to its changelog, and Sataana read two of them on the live client at launch: the spell picker's Class tab now lists your spells on Forever, where v2.4.21 left every tree spell under Other because the Forever spellbook names no spec, and the CVar health check no longer counts three encounter timeline CVars that Forever does not have as wrong. We have not run v2.4.22 or v2.4.21 on the beta ourselves, so whether either works there still rests on the changelogs and on Sataana.
On launch night, November 4, Sataana logged a new level 1 Mage into the live client, build 1.60.1.70790, which still declares interface 16001. The GRIP-EMS on it was the development build that follows v2.4.22, not the v2.4.22 download. It loaded with no Lua errors at login or at any point after it. /gems status said it had left out three CVars this client does not have. The spell picker opened on its Class tab with Fireball and Frost Armor listed. A Fire Mage string imported as three sequences, and after a UI reload GRIP-EMS restored all three from its saved data, so saving works on the live client. Sataana has not yet run one of those sequences in a fight.
v2.4.22 has two problems on Forever, and v2.4.23, released November 5, fixes both. Opening a second sequence in the editor showed the error Regions must have a frame parent, and every sequence opened after that showed it again until a UI reload. v2.4.22's notes also said that characters whose names share a first part keep their own records, and on Forever that wasn't true: v2.4.22 read only the first part of the name there, so two characters such as Grip Ems and Grip Two on one realm shared one record. v2.4.23 reads the first name and the surname, so each keeps its own. Your settings profile still goes by the first part of the name.
One loose end on the listings: the CurseForge page names Forever as a supported flavor next to Retail and now carries a WoW Forever v2.4.22 file, but its description text still says Retail only, so two parts of the same page disagree, and the Wago page now lists Forever as a flavor beside Retail, but its description and requirements still read Retail and Midnight 12.0.x, so it disagrees with itself the same way. Both listings showed v2.4.22 when we checked on November 2. The changelog and the guide inside the addon are the better guide to what works.
What that does not confirm is whether a sequence actually runs correctly once it is loaded. Loading and working are different claims, and only the first one has been verified, on the beta and on the live client at launch. Nobody has told us yet that they verified the second.
Why Forever is not quite Classic Era or retail
Per Sataana, Forever is classed internally as Mainline, meaning it runs on the current retail codebase while declaring the older Classic-style interface number above. That is an unusual pairing, and it means neither existing retail testing nor existing Classic Era testing fully covers it. One concrete example surfaced in September: UnitName("player") returned your full name on Forever, but UnitName("target") did not, and Sataana said the final behavior was unsettled. The Warcraft Wiki's Forever API notes list a September 23 beta build (70009) that made UnitName consistent across unit tokens (the same entry lists the SavedVariables fix and a fix for the restricted environment not loading), and an October 1 build (70170) that stopped UnitName("player") returning "Unknown" before login finished, so treat that example as out of date. On the live client at launch, UnitName("player") returned a two-part name as two separate values, the first name and then the surname, and GetUnitName("player", true) returned the two joined, so an addon that keeps only the first value of UnitName sees the first name alone. The same notes show Blizzard now treats Forever as a game type of its own, with a WOW_PROJECT_CAMELOT constant from build 70170 on October 1, and a forever game type for .toc directives, equivalent to camelot, from build 70291 on October 7. Treat anything Forever-specific as provisional until it has been observed directly, not assumed from how retail or Classic Era behaves.
SavedVariables: the early blocker, now working on the live client
This was the reason nothing got published here at first. A sequence that looked broken on Forever in those weeks could just as easily have been a working sequence that lost its saved state on the last reload. There was no way to tell the difference while the underlying bug was live, so no result from that period is meaningful evidence either way.
A fix has since been reported from more than one direction. The Warcraft Wiki's Forever API notes list "Fixed SavedVariables not loading" under beta build 70009 of September 23. In a Blizzard bug report thread about saved data reaching disk but not being restored at startup, one player wrote on September 25 that it loads correctly again in that build, and in a second thread that was marked solved, a tester confirmed the same on September 25. No Blizzard employee replied in either thread, and we have not tested it ourselves. A third report comes from the changelog of the Wayfinder addon, whose author says Blizzard fixed it in build 70009 and that they verified it in-game against their own settings. It is also worth knowing that, as far as we could tell, the Known Issues lists we read, from September 17 and 18 through the October 8 update, never carried a SavedVariables entry, so the only record of the bug and its fix is players, addon authors and the volunteer wiki, with nothing written by Blizzard.
The picture is not perfectly clean. The same second thread has a tester saying addon settings saved but the built-in chat still lost its customizations at logout, and a couple of third-party sites, one with a compatibility page checked on October 4, were still describing the bug as open or the fix as unconfirmed after the fix build, which may just be stale copy but which we cannot prove. Players also built unofficial workaround tools during the bad weeks. We have not tested those and do not recommend them, because they work by linking files around inside your WoW folder and the client fix should make them unnecessary.
Forum reports and a volunteer-kept wiki are not confirmation, so the rule here was to wait until Sataana confirmed the fix or it was tested here. That happened on launch night: on the live client, GRIP-EMS wrote its saved data at a UI reload and read it back, and all three saved sequences came back. A sequence still has to be run correctly before it counts as validated here.
What Blizzard has said about addons on Forever
In a post-BlizzCon interview that Kotaku published on September 14, 2026, lead encounter designer Mike Nuthals said Forever will carry over retail's restriction on in-combat addons that automate marking or communicating for players, the kind he called computational addons. Neither he nor lead Classic designer Tim Jones gave specifics on how addons will work, and the article does not say which addons stay allowed. Kotaku also reports that the One-Button Rotation Blizzard added to retail will not carry over to Forever. Macros are not mentioned anywhere in the piece. Other outlets picked the story up afterward, and the write-ups we found all traced back to that one interview.
A second round of statements followed on September 17. Icy Veins reported a message from a Blizzard representative on the WoW UI Discord and a Game Informer interview with the Forever developers. Per that report, Forever will use the same API restrictions Blizzard introduced with Midnight, and the representative said Forever shares Mainline's UI architecture, including "the vast majority of APIs available in 12.1.5." The developers said they want to keep the customization addons allow without giving addons excessive power over the player's experience. The Warcraft Wiki's Forever API notes carry the same statement, dated September 15. Neither source mentions macros or sequencing addons.
The beta notes since then add no restriction on macros. In the addon-facing API notes, Beta 4 on October 8 tightened the rules on addons sending emote chat and on reading minimap rotation during encounters, and Beta 5 on October 16 obfuscated the server and spawn portions of creature and object GUIDs, and the wiki has no entry after that one as of November 2, with the beta having closed on October 23. Those notes are compiled by volunteers and cover addon-facing changes only, so they are good evidence that Blizzard has not announced a change to macros and weaker evidence that nothing changed at all. They do show the direction of travel, which is more restriction on what addons can read and do, not less. For macros specifically, one thing points the other way: Blizzard's own beta development notes mention macros in passing as something that works on Forever. The October 1 notes fix macros placed on a gamepad action bar so they can be moved, the October 8 notes restore swapping several weapons inside one global cooldown through a macro, and the October 16 notes fix a focus macro sending a Paladin spell to the wrong target. That shows Blizzard treating macros as a normal part of the Forever client, which is not a statement about sequencers, and nobody at Blizzard has said anything about those.
What that means for GRIP-EMS is a guess until someone tests it on Forever. A sequence steps through fixed macro lines and leans on conditionals the game evaluates itself, which is not the kind of calculation the report describes, so the sequencing side looks like the safer half. The part more likely to be affected is the Variables system, because Sataana says Forever is classed internally as Mainline, and if it carries retail's rules for reading aura and cooldown state then Variables could behave on Forever the way the How it works page describes for retail, returning plain true or false answers and nothing numeric. That was an inference when we first wrote it. Blizzard's statements above now say Forever carries Midnight's API restrictions, which fits it, and the v2.4.21 changelog says the game no longer lets an addon read a unit's health percentage, which is why that helper was removed, while the helpers that remain return only true or false. But nobody has published a test of Variables on the Forever client, so it is still unconfirmed.
The wider question of what Blizzard has and has not said about addons that sequence your keypresses, on retail and everywhere else, is on its own page: What Blizzard has said about addons like GRIP-EMS.
Where this stands
The schedule, as far as Blizzard has put it in writing: the beta closed at 10:00 a.m. Pacific on October 23 according to a Blizzard community manager's post from October 22 (Blizzard's own pre-purchase page and several write-ups still say October 21 or 22, which were the earlier plans, so we are going by the newer post), early name reservation opened on October 27 for pre-purchasers of the Skyborne packs or the Warcraft Forever Collection (Blizzard's article footnotes that as requiring the Digital Upgrade or Collector's Edition), with a window that runs through November 3 and covers up to three characters in total across all Rulesets, and the opening was scheduled for 1:00 p.m. Pacific in North America and 6:00 p.m. in Central Europe, but it opened late and badly according to Wowhead's running coverage: Blizzard put up a launcher notice saying reservations were delayed, Europe opened at about 12:40 p.m. Pacific and North America at about 1:05 p.m. with queues that dropped players on login, and by 2:30 p.m. most of the disconnects were fixed but players in both regions were still reporting missing rulesets. A separate bug in the restricted-name check wrongly blocked names containing "c-o-n", and Blizzard said in a post Wowhead quotes that the fix would come with the next realm restarts in each region, so we do not know whether it has gone in yet. The game launched November 4, at 3:00 p.m. Pacific according to Blizzard's launch announcement, which writes that hour as PST, and Blizzard's own October 29 launch post has a table that lists the same moment as 11:00 p.m. UTC. Raids open December 9 according to that post as well, naming Barrow Deeps, Hyjal Summit and Onyxia's Lair. Blizzard can move any of those dates.
LazyGrip keeps Forever sequences apart from retail ones, with their own page and a filter on Browse, but nothing on it counts as validated until someone can confirm a sequence runs correctly end to end on Forever, past a UI reload, with no SavedVariables asterisk attached. This page gets updated the moment that happens.
Forever is live, so install v2.4.23 or later, which installs the same way it does on retail. Check that your keybinds and settings survive a reload before you judge a sequence: saving worked on the live client at launch, but it is still the first thing to rule out. One more obstacle is the class and spec changes Forever made: sequences here are written with spell names, so an ability that Forever renames would break a step without any error telling you why, and we have not found a list of which names changed. Check Sataana's Discord for the latest before assuming a problem is GRIP-EMS's fault rather than the game's.
One more difference worth knowing
Forever has no realms. Where an addon would normally key something to your realm name, Forever uses a "Ruleset" name instead. It does not affect sequences directly, but it is worth knowing if anything you use looks for a realm and comes up empty.