FAQ

Does this work in safe mode?

No, and that is intentional. Safe mode exists to start the browser without your configuration, and these scripts are configuration. In safe mode:

config.js is skipped (Firefox disables AutoConfig in safe mode),
userChrome.js returns early (it explicitly checks Services.appinfo.inSafeMode),
your .uc.js scripts do not run.

So if a script breaks your browser and you cannot reach the troubleshooting tools, safe mode is the way back in. Anything you change while there stays; the scripts simply stay out of the way until the next normal start.

Do I have to install it for every profile?

The configuration files: no (per browser). The utils: yes (per profile).

config.js lives in the browser's installation directory and is read once per browser. The utils live in <profile>/chrome/utils/, and UChrm resolves per profile. A second profile (including a temporary about:profiles one) starts with no legacy add-ons and no .uc.js scripts until you copy utils.zip into it.

The installer lets you pick the browsers; for extra profiles, unzip utils.zip into the new profile's chrome/utils/ as described in Installation.

Does it slow the browser down?

The loader work is a handful of file reads and a manifest hash comparison at startup. The daily update check re-reads a small JSON manifest over the network at most once a day, and only when the browser starts. No background service, no scheduled task, no telemetry.

Why is an unsigned binary telling me to click through SmartScreen?

The installer is not code-signed. Windows shows "Windows protected your PC" for any untrusted binary; click More info → Run anyway.

You do not have to take the word of anyone on the internet: each installer asset in the release ships a .sha256 sidecar, and the elevation it performs is a single, checksum-verified copy step through a helper downloaded for that purpose. If you want to inspect what you are running before running it, download from the Download page and check the hash yourself.

Will an extension still work after a browser update?

Not automatically, and the updater is not what keeps an individual extension working. The updater only notifies you when a new version of the firefox-scripts packages (utils.zip, fx-folder.zip) is published; it does not update your extensions.

Whether an extension keeps working after a browser update is a separate question. Legacy add-ons hook deep into browser internals, and most of them need an update for each Firefox release. Whether a fix exists, and how quickly, depends on each extension's author. If you let Firefox auto-update extensions (in Add-ons Manager → ⋯ → Restart Firefox / the extension's auto-update setting in about:addons), those updates arrive from the extension's own update channel, not from this project.

What the updater does is close the other half of the problem: when a browser update breaks an add-on and a fix is published in the firefox-scripts packages, it offers that fix to you once a day in a tab you can act on immediately, instead of leaving you with a broken extension until you notice.

Waterfox / Zen / LibreWolf / Floorp

Supported, and validated in CI on every release. See the Browser compatibility section in Installation for the per-browser notes, including the current Nightly version this was tested against.

Waterfox ships its own Bootstrap Loader, so ours skips loading (loading both would double-register the loader and break legacy add-ons). userChrome.js and the updater still work. See config.js.
Zen Browser, LibreWolf and Floorp need no special handling.

Detection uses process scanning and lock-file inspection, so the browser must be running when the installer runs.

Is it safe?

The honest answer: it is privileged code, and you should trust its source. A legacy add-on and a .uc.js script both run with the full privileges of the browser, the same level as Firefox's own code. That is inherent to what they are, not a flaw in this project.

What you can rely on:

The scripts are built from source in a public repository, and every release's contents are published with a hash manifest the updater verifies.
The installer performs no network I/O of its own: the browser tab it opens downloads the packages and hands them to the local server, so there is no hidden download path.
The local server that receives those bytes requires a per-run session token.

Install add-ons and user scripts only from sources you trust.

Can I install only the configuration files?

No. The configuration files (config.js and config-prefs.js, the fx-folder package) only switch on Firefox's AutoConfig startup hook. With nothing else installed, there is no code for that hook to load: no legacy add-on and no .uc.js script will run.

The utils package (BootstrapLoader.js, userChrome.js and the updater) is what the hook loads, so it is required in every setup. Picking only "Configuration files" in the installer leaves a browser that reads config.js and then does nothing with it. The reverse holds too: the utils do nothing without the configuration files loading them. Install both packages; that is the default the installer offers.

Installation paths per OS are in Installation → by hand.

What about the macOS app bundle being replaced?

When macOS updates Firefox it replaces the whole Firefox.app bundle, which removes the configuration files you put inside it (config.js and defaults/pref/config-prefs.js). After a macOS Firefox update, reinstall the configuration files into the fresh bundle. See Installation → by hand. If macOS blocked the modified bundle from launching, check System Settings → Privacy & Security → Security and allow it.

I want to go back to a clean browser

Remove config.js and defaults/pref/config-prefs.js from the browser root directory, remove the chrome folder from each profile, and restart. See Removing the scripts.