Update 2026-07-15 (v0.4.23, and addon 3.3.24): the client-side detection was removed and the decision moved to GSE’s server

GSE shipped Companion v0.4.23 (2026-07-14) and addon 3.3.24-1. I analyzed the installer I downloaded and confirmed its app.asar is byte-identical to my installed copy, so this is the code that runs. As always, I am a competitor; verify it yourself. Hashes are in hashes.txt.

What changed in v0.4.23

v0.4.23 removed the client-side detection and account-flagging. This is confirmed by a normalized diff against v0.4.22, not inferred:

• The access-policy fetch no longer returns integrityRef (the server-supplied target name). The client has nothing to scan for.
• The entire syncRestrictedAccountFlag routine, which read your WoW folders and PATCHed data.restrictedAccount true or false on your GSE account, is deleted.
• The 10-minute policy check now only reads the enforce flag. The scan and the account-flag write are gone.
• The policy:state handler now returns restricted: false hard-coded, with GSE’s own comment in the shipped code:

// `restricted` is retained in the contract for the renderer's access-policy
// composable but is now always false: the Companion performs no client-side
// presence scan. Any account restriction is decided server-side.

What did not change

The enforcement machinery is all still in v0.4.23:

• The ed25519-signed, server-pushed engine that can delete from or rewrite any addon’s .lua SavedVariables while WoW is closed (same embedded key b531cb8b...683a).
• The unsigned, server-triggered routine that reads arbitrary files under your Interface\AddOns and WTF folders and uploads them.
• The BugGrabber/BugSack error-log gather that attaches those logs to a diagnostic upload (regex Bug(Grabber|Sack) still present).
• The unsigned auto-updater that spawns a downloaded installer with /S --force-run and no signature or hash check.

What this means

The behaviour did not stop; the decision moved. Detection and flagging used to live in the shipped client, where anyone could read them. In v0.4.23 that logic is gone from the client and, by GSE’s own comment, happens on their server, which cannot be inspected. Meanwhile the arm that acts on a flagged account, the signed delete/rewrite engine and the arbitrary-file capture, is unchanged. So the targeting became less auditable while the capability to act stayed the same. I cannot tell you what the server does with a flag, because that code runs on GSE’s infrastructure and I will not attack it to find out.

Live state on 2026-07-15

• GET https://api.gse.tools/settings/access-policy returns {"enforce":false,"updatedAt":null,"integrity":"verified"}, the same with the account token and anonymously.
• One thing I can state as an aggregate, with no identity attached: of 3,747 member records, exactly one currently carries restrictedAccount:true. It is not mine. My own account carries no restriction field. I do not know who the one is and did not look; I only counted.

Honest limits

• Server internals are a black box. Any statement about what the server does with restrictedAccount or enforce is inference from observed responses, not fact.
• I observed no signed directive being sent during a live capture, but that is a window, not a proof; the signed engine is armed whenever GSE chooses to send a valid directive, and it ignores enforce (it needs a signature).

Addon 3.3.24-1

Inert with respect to competitor targeting: no GRIP-EMS, provenanceSource, gse-legacy, or detection strings in any file. The encoder still writes the plain !GSE3! format; the ChaCha20 !GSE3!+ format is still decode-only. It now also declares Interface 120100 (12.1.0).