diff --git a/apps/zen.nix b/apps/zen.nix
index 2e82dca..402dcb3 100644
--- a/apps/zen.nix
+++ b/apps/zen.nix
@@ -5,17 +5,18 @@ let
   # startup — the only scriptable way into chrome, since Gecko has no reload
   # for userChrome.css and Zen exposes no command for one.
   #
-  # So don't use userChrome.css at all for the wallpaper theme. Register
-  # <profile>/chrome/zen-theme.css as a style-sheet-service USER_SHEET here
-  # and re-register it under a cache-busting URI whenever its mtime moves —
-  # that is what makes a `theme-apply` switch land in a running Zen
-  # (settings/theming.nix writes that file on every switch).
+  # So register <profile>/chrome/zen-theme.css as a style sheet here and
+  # re-register it under a cache-busting URI whenever its mtime moves — that is
+  # what makes a `theme-apply` switch land in a running Zen (settings/theming.nix
+  # writes that file on every switch).
   #
-  # theming.nix still writes userChrome.css too, so a broken watcher costs the
-  # live update and nothing else. Whether the watcher can win at all is the
-  # open question: nsIStyleSheetService documents its user sheets as ordered
-  # BEFORE the profile's userChrome.css, which would let the startup copy
-  # outrank every sheet we register.
+  # AGENT_SHEET, not USER_SHEET. theming.nix still writes userChrome.css as the
+  # startup floor, and nsIStyleSheetService orders its user sheets BEFORE the
+  # profile's userChrome.css — so as a user sheet ours registered fine and then
+  # lost every `!important` to the copy parsed at startup, which is precisely a
+  # theme frozen at launch. Agent sheets sort above ua.css, so agent-origin
+  # !important outranks it. theming.nix wraps this file in @-moz-document to
+  # keep that agent origin off web pages.
   #
   # Everything here goes through Components.classes rather than `Services`,
   # which is not a global in this scope.
@@ -71,11 +72,11 @@ let
           // A fresh query string dodges the CSS loader's per-URI cache; without
           // it a re-register would hand back the sheet parsed at startup.
           const base = io.newFileURI(file).spec;
-          sss.loadAndRegisterSheet(io.newURI(base + "?" + stamp), sss.USER_SHEET);
+          sss.loadAndRegisterSheet(io.newURI(base + "?" + stamp), sss.AGENT_SHEET);
           if (live !== null) {
             const old = io.newURI(base + "?" + live);
-            if (sss.sheetRegistered(old, sss.USER_SHEET))
-              sss.unregisterSheet(old, sss.USER_SHEET);
+            if (sss.sheetRegistered(old, sss.AGENT_SHEET))
+              sss.unregisterSheet(old, sss.AGENT_SHEET);
           }
           live = stamp;
           note("ok " + stamp);
diff --git a/settings/theming.nix b/settings/theming.nix
index ff8dd52..7296d73 100644
--- a/settings/theming.nix
+++ b/settings/theming.nix
@@ -532,7 +532,17 @@ let
     # userChrome.css the result is the old behaviour — themed on next launch —
     # never an unthemed browser.
     install -Dm644 "$theme/zen.css"     "$HOME/${zenChrome}/userChrome.css"
-    install -Dm644 "$theme/zen.css"     "$HOME/${zenChrome}/zen-theme.css"
+    # Same CSS again, at agent level via the watcher in apps/zen.nix, which is
+    # the copy that actually changes a running window — a user-level sheet is
+    # ordered below userChrome.css and loses every !important to it. Agent
+    # origin applies to web pages too, hence the @-moz-document scope; the
+    # startup copy above stays unwrapped so it survives even if that syntax is
+    # ever dropped for user sheets.
+    {
+      echo '@-moz-document url-prefix(chrome://) {'
+      cat "$theme/zen.css"
+      echo '}'
+    } > "$HOME/${zenChrome}/zen-theme.css"
 
     # Icon theme: replace the directory contents (cheap — the tree is
     # symlinks into the papirus store path) so GTK's icon-theme monitor sees