Sine: a theme and mod manager that lives inside Firefox settings

The settings page is where Sine takes over

Sine is described as a community-driven mod and theme manager for all Firefox-based browsers, positioned as a more efficient, powerful, user-friendly and compatible alternative to manual installation.

The mechanism is unusual and worth understanding before anything else. Sine is independent of other third-party tools and injects itself into the settings page to provide a clean, intuitive and sturdy system for getting new mods and themes. So the user interface is not a separate application, and not a website, but a panel that appears inside the browser's own preferences.

That choice is the whole reason a theme manager like this is possible at all in a browser that does not support extensions touching the chrome area. Everything the user wants to customise lives in the browser's own UI layer, in userChrome and userContent, and Sine is a way to install, version and remove those files without editing them by hand.

The supported browsers are named in the repository topics rather than in a single explicit list, and they read as the Firefox family: Firefox itself, Floorp, LibreWolf, Waterfox and Zen. The Zen mod format is supported explicitly, which matters because Zen is a browser whose chrome is a frequent target for this kind of customisation.

The audience is two-sided. There are users who want a curated set of themes and mods without maintaining CSS by hand, and there are mod authors who want distribution and automatic updates without running a website.

Updates are pulled from the author's repository, not from a release feed

The marketplace is built into the settings GUI, and that is where users add and view Sine-compatible mods. There is also a website, sineorg.github.io/store, with its own repository at github.com/sineorg/store, and Sine provides support for installing mods from that site too, so the GUI is an entry point rather than a wall.

The update model is the part that differs from a conventional extension store. The README is explicit: Sine does not require update requests and pulls them straight from your repository. The consequence for an author is that publishing a new version on GitHub is enough, and the users of the mod get it. The README also notes that you will never have to worry about GitHub issues being outdated or have to tell your user to update to the latest version.

Publishing is correspondingly cheap. The README says that all you have to do is make an issue with a template, and that assuming your project is already Sine-compatible, it will work just fine.

The compatibility requirement is the part authors have to satisfy, and the README is generous about it. Sine supports userChrome, userContent, the Zen mod format, and mods that are missing typically necessary metadata. That last case is the interesting one, because it means a mod does not have to be repackaged into a specific format to be installable, as long as its contents are the kind of files the manager can place.

Testing an unpublished mod is also built in. You type in the name of the repository, a folder if needed, and Sine handles the rest, so an author can try a mod on their own browser before it is in the store.

Update control is per mod, and auto-update on start is a switch

The preferences area is where Sine exposes what it actually manages, and the README divides it into three things: built-in settings, mod management and mod preferences.

Built-in settings are described as the controls over what you like and dislike about Sine itself, with the fallback being to open an issue or discussion. Mod management is the one that matters for trust. Sine gives the power to turn on or off updating for certain mods, and to enable auto-updating on browser start.

Those two knobs are the difference between a manager you trust and one you do not. A mod that you have disabled updates for will stay at the version you approved, and turning off auto-update on browser start means mods are only fetched when you ask. The README also links a wiki page listing the extra preference features mods can expose, so a mod can add its own settings on top of the manager's own.

The design assumes that not every mod should update on the same schedule, which is realistic. A mod that changes the appearance of the chrome and a mod that changes behaviour under the hood are not the same kind of thing to let update on a Tuesday morning while you are using the browser.

It is also worth being clear about what Sine is not. It is a file manager for browser chrome, not a security control and not a sandbox: a mod it installs is a mod running in your browser profile. The per-mod update switch manages freshness, not permission.

On macOS the installer has to be re-signed before it will run

Automatic installation is described as the easiest way to set up both Sine and its bootloader, and since version 2.0 installers exist for macOS, Linux and Windows, with x64 and ARM architectures also supported.

The steps are: download the installer for your operating system from the Sine release page, run it, then close and reopen the browser to complete the setup. On Windows and Linux, running the downloaded file is the whole procedure.

On macOS it is not, and the reason is the quarantine attribute that macOS applies to downloaded files. You have to unquarantine the file and then execute it, by opening a terminal in the location of the installer and running:

xattr -d com.apple.quarantine ./sine-osx-arm64
chmod +x ./sine-osx-arm64
sudo codesign --force --deep --sign - sine-osx-arm64
./sine-osx-arm64

The README notes that you should replace sine-osx-arm64 with sine-osx-x64 if you use x64. The codesign command with an ad hoc signature is what re-signs the binary so the system will run it.

A manual installation guide is also available, in the documentation page for installation in the sineorg docs repository, which is the route to take if you would rather not run an installer that writes into your browser profile. Since the installer sets up both Sine and its bootloader, understanding what it places on disk is the reasonable first step for anyone who cares about the contents of their profile.

The build runs on Bun and browsercfg, with Python for packaging

The repository is a JavaScript project with an unusual mix of toolchains, and package.json describes it accurately: the package is named sine, it is marked private, it is licensed MPL-2.0, and it declares a workspace at ./tools/oxlint-plugin-mozilla.

The scripts show the pipeline. The dev command is browsercfg import followed by browsercfg run, and the test command is browsercfg test, with a separate test:twilight variant that targets the zen-twilight browser and downloads it as needed. Linting runs oxlint and then ruff, plus a script named check_licenses.py, and formatting runs oxfmt and ruff format. The package step is uv run scripts/package.py, and the init step is bun install together with uv sync --project scripts/.

So the front end tooling is Bun based with browsercfg as the harness, and the packaging and licence checking work is done in Python through uv. The Python side of the repository is in the scripts directory, and the tree also carries engine.json, .browsercfg.json, locales, a crowdin.yml, a CODEOWNERS file, a SECURITY.md and .githooks with the prepare script pointing git at them.

That combination is worth understanding for a contributor rather than an end user. The interesting part for a mod author is the licence check, since check_licenses.py runs as part of lint and the project ships a licence as well as a SECURITY.md and a code of conduct. The interesting part for a user is much less, because the end product is an installer and a panel in the settings page.

MPL-2.0, a volunteer project, and two different version numbers

The licence is the Mozilla Public License 2.0, and the README credits CosmoCreeper and the contributors, with the project distributed under that licence and a LICENSE file at the root of the repository.

MPL-2.0 is file level copyleft. Modified files that you distribute must stay under the licence, and the notice has to be carried, but the licence does not reach into the parts of a larger work it is merely combined with. For a project that ships mod files into browser profiles and expects third-party mods to be pulled from their own repositories, that is a sensible choice, and the licence check in the lint script is the mechanism that keeps it honest.

The maintenance picture is clear enough to read from the release list. Version 2.3.3 was published on 2026-05-17, 2.3.4c on 2026-08-11 and 2.3.4c2 on 2026-08-25, and the last push to the repository was on 2026-10-19, the day before this article. The project is being worked on right now.

One detail catches the eye. The version badge in the README advertises 2.3.4, and the release tags are in the 2.3.4 line, but the version field in package.json reads 1.0.0. That is not a mistake to worry about, since the package is marked private and is not published to a registry, so its version field is not the release version of the application. It is the kind of thing that confuses anyone who lands on the repository expecting the manifest to describe the shipped product.

The project is community driven in the literal sense. The README links a Discord, a Reddit community, an x account, the documentation, the store and the discussions, and it credits SignPath.io with providing free code signing on Windows through the SignPath Foundation, which is what makes the Windows installer a signed binary rather than an untrusted download.

Editorial conclusion

Sine fits a Firefox user who has accumulated userChrome.css and userContent.css edits and wants them managed, updated and reversible rather than hand-maintained, and it fits mod authors who publish on GitHub and want installs to update themselves. It does not fit a browser you need to keep pristine, since Sine injects itself into the settings page, and it does not fit someone unwilling to run a third-party installer that writes into the browser profile. Before you install, read the manual installation guide in the sineorg documentation, and on macOS expect to run xattr, chmod and codesign yourself before the installer will run.

Frequently asked questions

Official sources

1. CosmoCreeper/Sine on GitHub
2. Issues
3. License: MPL-2.0
4. README
5. Releases