Keeping Clearcote up to date

Each SDK version is pinned to one specific, SHA-256-verified browser build. Updating is a normal package bump — the SDK fetches and verifies the matching binary for you.

SDK users (recommended)

Bump the package the way you update any dependency:

bash

npm i clearcote@latest        # Node
pip install -U clearcote        # Python

On the next launch() the SDK notices its pinned build isn't cached, downloads it from GitHub Releases, and verifies the SHA-256 before use. Nothing runs unverified. The binary is cached under ~/.clearcote, so it's a one-time download per version.

Update the binary without upgrading the SDK

Want the newest build the SDK knows about without changing anything else? Opt into auto-update — the SDK checks for a newer pinned release and fetches it (still verified):

javascript

import { launch } from "clearcote";
await launch({ autoUpdate: true });   // or set env CLEARCOTE_AUTO_UPDATE=1

The browser itself never phones home or auto-updates on its own — updates are always something you initiate (a package bump or autoUpdate). That's deliberate: no background beacons.

Direct / Docker users

Direct binary: download the new archive from the Releases page, verify the checksum + signature (see Verification), and pointexecutable_path at the new chrome.
Docker: docker pull teamflatearth/clearcote for the latest image, then recreate your container. See Deployment.

Clearcote Pro — always current

On Pro, staying current is the point: the license-gated build tracks the latest Chromium and the newest anti-detection patches, so you get updates without manual rebuilds — setCLEARCOTE_LICENSE_KEY and the SDK selects the maintained Pro binary.

After upgrading, re-verify

A new build can shift a signal. Re-run your fingerprint checks (e.g. CreepJS) and, if you use an imported profile, confirm it still loads coherently — see Verification. The current release line is v0.1.0-pre.21 (Chromium 149); the roadmap tracks what's next.