Is Camoufox still maintained? Reading the repository

Whether Camoufox is still maintained is a question its own repository answers in about five minutes, and better than any forum thread. Open the latest release. Note its date and the Firefox version it is built on. Then compare that with the Firefox release people run today. That gap, and how recently the patches changed, is the honest answer to "is Camoufox still maintained".

We are not going to give a verdict here, because it would be a dated fact on a page that stays up. What follows is the method, and what the answer costs you if it comes out badly.

What Camoufox is, in one paragraph

Camoufox is Firefox with patches applied to its source. The fingerprint values change inside the browser's own code, not in a script that a page could catch overwriting them. It is installed with pip: the Python package fetches the patched browser and drives it through Playwright. We have read parts of it closely. Before we wrote our own navigator.maxTouchPoints patch, 0109 in our series, we looked at how Camoufox handles that value. It gates the TouchEvent constructor along with the count, because a page that finds touch points and no TouchEvent has found a contradiction. Chromium ships TouchEvent on every desktop build anyway, so 0109 changes only the count. We kept the reasoning and did not need the second half.

How it works: Its own Chromium

How to tell if Camoufox is still maintained

1. The release, and the Firefox under it. A Camoufox build carries two version numbers: its own, and the Firefox it was patched onto. Only the second one ages. Write both down, with the release date.
2. Today's Firefox. Mozilla puts out a new major about every four weeks, so subtracting gives you a rough age. One or two majors behind is a project doing the slow work of rebasing and testing. Ten behind is about nine months in which the engine did not move.
3. What the commits touch. A busy log can be README edits, CI fixes and changes to the Python wrapper. The engine is the patch files and the Firefox version they target, so look for those.
4. What your machine runs. pip reports the package version, and the browser it fetched reports its own. On an old install the two can be far apart, so check both.
5. The issues. The useful reports say that a particular fingerprint check started failing. If those get a reply and a fix, someone is doing the work. A pile of them with no replies tells you more than the date of the last commit.
6. The README and the forks. A project with one main author can change hands or carry on in a fork. If the README sends you somewhere else, run these steps again on the repository it names.

None of this needs inside knowledge. It also keeps working after news about the project has gone stale, which a forum answer does not.

What an unmaintained engine costs

Nothing breaks on the day the commits stop. Each Firefox release after that adds to the bill.

Say the latest build sits on a Firefox six majors old, which is about half a year. Every real Firefox on that major has had six chances to update itself and most have taken them, so the browsers still on it are largely machines nobody looks after. That is the crowd a profile on that build stands in. Claiming a newer version does not get you out, because a page can check for the features each release added, and the TLS handshake moved as well. We measured one step of that on Chrome: 152 read t13d1517h2 and 153 read t13d1518h2, seventeen TLS extensions against eighteen (JA4 moves with the Chrome major). A browser whose claimed version and handshake disagree is easier to spot than one honestly reporting an old version.

The security side is simpler. Six majors is six months of Mozilla's fixes the browser does not have, in a tool that is usually pointed at sites you do not control.

The fingerprint side is the one people forget. Detectors keep adding checks. A maintained project reads a new check and patches for it. A frozen one gives the answer it gave last year.

Why a gap costs more to close the longer it runs

Catching up is not one small update per missed release. It is one rebase across the whole gap, where every patch has to land on code that moved under it. Our engine is Chromium, not Firefox, but the arithmetic is the same and we have the figures.

Moving our patch series across nine Chrome majors, 144 to 153, rejected 11 of 51 patches. Eight of those were only drift in the include lines at the top of files. Four were real code that had changed underneath. The single step from 153 to 154 then added three kinds of breakage we had not met before, including a removed struct field: the one class that compiles cleanly once the write is dropped, while the value it carried quietly stops arriving. The near-full rebuild for that step took 93 minutes on our build Mac, against one or two minutes for an incremental build after one changed patch.

So a project that lapses for a year does not owe twelve small updates. It owes one large rebase where the hard part is proving nothing went missing, which is why "it's coming back soon" and "it's current" are different statements.

If you need Firefox, and if you do not

If the job really needs a Firefox fingerprint, the engine has to be Firefox, and Camoufox or a commercial Firefox core is the right tool. Kameleo keeps one (Kameleo's two engines). Multilogin froze its own, and Multilogin's legacy Stealthfox is what that looked like for the people using it.

Mosaic runs one engine, Tesseract Chrome: stock Chromium source with our patch series on top, so every profile claims Chrome. It is a desktop app for macOS and Windows, not a Python library you import, which makes it a tool for a different job. The anti-detect browser roundup lists which product runs which engine.