Clearcote aktuell halten

Ohne Lizenzschlüssel ist jede SDK-Version an einen per SHA-256 verifizierten offenen Build gepinnt, und ein Update ist ein ganz normales Anheben der Paketversion. Mit Schlüssel holt das SDK bei jedem Start den aktuellen lizenzierten Build — ohne dass Sie eine Version anheben müssen.

Welche Builds verfügbar sind

Die Chromium-Major-Versionen, die wir derzeit ausliefern oder an denen wir arbeiten, und wann welche Stufe sie bekommt:

SDK-Nutzer (empfohlen)

Aktualisieren Sie das Paket wie jede andere Abhängigkeit:

npm i clearcote@latest          # Node
pip install -U clearcote        # Python
dotnet add package Clearcote    # .NET (adds or updates to the newest version)

Beim nächsten launch() bemerkt das SDK, dass der benötigte Build nicht im Cache liegt, lädt ihn herunter — den offenen Build von GitHub Releases, den lizenzierten Build von clearcotelabs.com — und verifiziert den SHA-256-Hash vor der Nutzung. Nichts läuft unverifiziert. Jeder Build landet einzeln in Ihrem Benutzer-Cache-Verzeichnis — %LOCALAPPDATA%\clearcote\Cache unter Windows, ~/.cache/clearcote unter Linux (ein anderes Verzeichnis setzen Sie mit CLEARCOTE_CACHE) — und wird daher nur einmal heruntergeladen. Alte Builds bleiben erhalten, bis Sie clearcote clear-cache ausführen.

Mehrere Programme, ein Cache

Programme, die sich den Cache teilen, installieren einen Build nacheinander (SDK 0.41.0+, in Python, Node und .NET gleichermaßen): Das erste lädt ihn herunter, die anderen warten und nutzen ihn dann, und ein Build, den ein anderes Programm gerade ausführt, wird nie unter ihm ersetzt. Ein wartendes Programm gibt nach 30 Minuten auf, mit einer Meldung, die den Prozess nennt, der die Installation hält (die Sperre ist die Datei .install-lock im Cache-Ordner dieses Builds; die Meldung sagt, wann Sie sie gefahrlos löschen können). Eine Sperre, die ein abgestürztes Programm hinterlassen hat, wird von selbst übernommen.

Ein gecachter Build, dessen Dateien beschädigt oder entfernt wurden (Quarantäne durch einen Virenscanner, ein gelöschter Ordner), wird beim nächsten Start mit einem einzigen Download repariert. Sind seine Dateien noch in Gebrauch, bricht der Start sofort ab und fordert Sie auf, jedes Programm zu schließen, das diesen Browser nutzt, und es dann erneut zu versuchen. Die Sperre setzt voraus, dass jeder Prozess, der den Cache teilt, SDK 0.41.0 oder neuer verwendet; ältere Releases warten nicht auf sie.

Windows: Manche Umgebungen können einen heruntergeladenen Build nicht an seinem Ort starten, etwa ein Programm, das in einer paketierten (MSIX-)App läuft, deren Schreibzugriffe auf %LOCALAPPDATA% Windows umleitet (der Start scheitert mit spawn UNKNOWN oder "the side-by-side configuration is incorrect"). Dort legt das SDK eine Kopie des Builds in ~/.clearcote/recovered an, und jeder spätere Start aus Python, Node oder .NET nutzt sie; so bleibt nichts im temporären Ordner zurück, und wiederholte Starts sind in Sekunden bereit (Python und Node ab 0.40.1, .NET ab 0.41.0). clearcote clear-cache entfernt auch diese Kopien; das .NET-SDK hat keine Kommandozeile, rufen Sie dort also WinLaunch.ClearRecovered() auf.

Offenen Build aktualisieren, ohne das SDK zu aktualisieren

Ohne Schlüssel können Sie Auto-Update aktivieren, um statt des im SDK gepinnten Builds den neuesten offenen Build von GitHub zu nehmen. Er wird gegen die SHA256SUMS.txt des jeweiligen Release verifiziert (und gegen den Signaturschlüssel, wenn gpg installiert ist); ist GitHub nicht erreichbar, fällt das Update auf den gepinnten Build zurück. In der Shell erledigt clearcote update dasselbe. Mit Schlüssel ändert sich dadurch nichts — Sie bekommen ohnehin den aktuellen lizenzierten Build.

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

Der Browser selbst telefoniert nie nach Hause und aktualisiert sich nie selbst. Ohne Schlüssel ändert sich der Browser nur, wenn Sie das SDK aktualisieren oder autoUpdate einschalten. Mit Schlüssel übernimmt das SDK jeden neuen lizenzierten Build beim nächsten Start; mit Pro können Sie per version an einem Build festhalten.

Einen Build auswählen

Übergeben Sie version (oder setzen Sie CLEARCOTE_BROWSER_VERSION): "latest", eine Major-Version wie "154", eine exakte Version "154.0.8037.57" oder eine lizenzierte Revision "r36" / "154.0.8037.57-r36". Eine Version oder Major-Version wird gegen den veröffentlichten Katalog geprüft, eine Revision gegen den Lizenzserver — bevor irgendetwas heruntergeladen wird. releaseChannel: "preview" (release_channel in Python oder CLEARCOTE_RELEASE_CHANNEL=preview) nimmt einen Preview-Build, sofern es einen gibt. Beim lizenzierten Build sind ältere Builds, Pinning und der Preview-Kanal Pro-Funktionen — kostenlose Schlüssel bekommen immer den neuesten.

clearcote install --version 154        # fetch + verify a build ahead of time
clearcote install --channel preview     # the newest preview build (Pro)
clearcote info                          # what's installed and cached, and your key
clearcote clear-cache                   # delete cached builds

Direkte Nutzung / Docker

• Direkte Binary (nur offener Build — der lizenzierte Build läuft über das SDK, clearcote serve oder das Docker-Image): Laden Sie das neue Archiv von der Releases-Seite herunter, verifizieren Sie Prüfsumme + Signatur (siehe Verifizierung) und lassen Sie executable_path / executablePath (oder CLEARCOTE_BINARY) auf die neue chrome-Binary zeigen.
• Docker: docker pull teamflatearth/clearcote holt das neueste Image; erstellen Sie danach Ihren Container neu. Kostenlose Schlüssel brauchen ein Image, das aus SDK 0.30.0 oder neuer gebaut wurde. Mit Schlüssel mounten Sie -v clearcote-cache:/opt/xdg-cache, damit der lizenzierte Build nur einmal heruntergeladen wird statt in jeden neuen Container. Siehe Deployment.

Der lizenzierte Build — immer aktuell und immer zuerst

Der lizenzierte Build folgt dem neuesten Chromium und den neuesten Patches, Sie bekommen Updates also ohne manuelles Neubauen. Setzen Sie CLEARCOTE_LICENSE_KEY, übergeben Sie licenseKey oder führen Sie clearcote login aus (Python/Node; npx clearcote login bei lokaler npm-Installation) — der Befehl prüft den Schlüssel und speichert ihn in ~/.clearcote/license.key, wo ihn jedes SDK liest, .NET eingeschlossen. Es gibt zwei Wege zu einem Schlüssel:

• Kostenlos mit GitHub — ein Browser gleichzeitig, ohne Kosten. Melden Sie sich mit einem GitHub-Konto an, das mindestens 30 Tage alt ist, öffnen Sie in Ihrem Dashboard Licenses, klicken Sie auf Connect GitHub and get it free und dann auf Claim my free key (einer pro GitHub-Konto). Der Schlüssel gilt 30 Tage; verlängern Sie ihn vor Ablauf kostenlos auf derselben Seite.
• Pro — derselbe Build mit bis zu 250 gleichzeitigen Browsern, dazu ältere Builds, Versions-Pinning und der Preview-Kanal sowie E-Mail-Support direkt vom Inhaber.

Neue Major-Versionen kommen zuerst in den lizenzierten Build. Sobald eine neue Chromium-Major-Version gebaut ist, steht sie sofort in „Kostenlos mit GitHub“ und Pro bereit; der offene Build bekommt sie später — angestrebt sind etwa 2 Monate nach dem Release (heute basiert er auf Chromium 150). Der offene Build ist immer vollständig offen und reproduzierbar; der lizenzierte Build bekommt die neueste Version früher.

Wie lizenzierte Browser gezählt werden

Jeder mit Schlüssel gestartete Browser belegt einen Slot beim Lizenzserver und gibt ihn beim Schließen wieder frei. Ihr Dashboard zeigt, wie viele gerade belegt sind, und clearcote info gibt dieselbe Zahl aus.

• „Kostenlos mit GitHub“ zählt jeden Browser. Es gibt einen Slot, daher wird ein zweiter Browser — im selben Programm, in einem anderen Programm oder auf einem anderen Rechner — mit The free tier runs one browser at a time, and one is already running abgelehnt, bis der erste geschlossen ist. Ein Browser, der abgestürzt ist, ohne sich zu schließen, gibt seinen Slot innerhalb von 6 Minuten frei.
• Pro zählt Rechner und deckt bis zu 250 gleichzeitige Browser ab. Alle Browser auf einem Rechner teilen sich dessen Slot. Abonnements, die vor dem 26. September 2026 abgeschlossen wurden, behalten ihre bisherigen Bedingungen ohne Obergrenze; wenn Sie mehr als 250 brauchen, fragen Sie uns, dann erhöhen wir das Limit.
• Kostenlose Schlüssel brauchen SDK 0.30.0 oder neuer (Python, Node und .NET), denn um jeden Browser zu zählen, muss das SDK jeden Start melden und die Lizenz aktuell halten, solange der Browser läuft. Ein älteres SDK bekommt SDK_UPGRADE_REQUIRED samt Upgrade-Befehl, und ein älteres SDK, das trotzdem bis zur Engine durchkommt, wird dort abgewiesen. Pro-Schlüssel funktionieren wie bisher auch mit älteren SDKs.
• Ein kostenloser Browser stoppt, wenn sein Slot wegfällt. Die Prüfung läuft fortlaufend, nicht nur beim Start: Wird der Schlüssel widerrufen, der Slot an anderer Stelle freigegeben oder das Limit der Lizenz überschritten, beendet sich ein bereits geöffneter kostenloser Browser innerhalb von etwa 2 bis 3 Minuten. Kurze Netzwerkaussetzer (ein oder zwei verpasste Heartbeats) werden abgefangen; ein Ausfall von mehr als etwa 2 bis 3 Minuten stoppt einen kostenlosen Browser auf die gleiche Weise.
• Der kostenlose Tarif nutzt immer den neuesten Build. Wer einen älteren lizenzierten Build oder den Preview-Kanal anfordert, bekommt FREE_LATEST_ONLY; einen Build zu pinnen ist eine Pro-Funktion.
• Downloads mit kostenlosem Schlüssel: bis zu 10 verschiedene Builds pro 24 Stunden. Derselbe Build zählt einmal, egal wie oft Sie ihn starten.

pip install -U clearcote          # Python 0.30.0+
npm i clearcote@latest            # Node 0.30.0+
dotnet add package Clearcote      # .NET 0.30.0+

Was sich beim Upgrade ändert

Die meisten SDK-Releases ändern nichts, worauf Sie reagieren müssten. Die folgenden ändern, was ein bestehendes Setup tut; jedes Release ist in Ihrem Dashboard unter Releases aufgeführt.

• Lizenzierter Build 154 r36, ein bestehender Seed: Ein Seed wählt seine Grafikkarte jetzt aus mehreren echten Modellen vom GPU-Hersteller des Rechners selbst statt aus einem einzigen Modell pro Hersteller, daher melden die meisten Seeds eine andere Karte als unter r35. Auf einem Rechner mit NVIDIA-Karte gibt ein Seed, der bisher Einsteiger-Hardware angab (4 bis 6 Prozessor-Threads, 4 bis 8 GB Arbeitsspeicher, ein kleiner Bildschirm), jetzt mindestens Mittelklasse-Hardware an, und dort gibt kein Seed einen Touchscreen an. Um die Identitäten zu behalten, die Ihre Seeds vor r36 hatten, setzen Sie persona_schema=2 / personaSchema: 2. Siehe Derselbe Seed auf verschiedenen Rechnern.
• Lizenzierter Build 154 r36, Drittanbieter-Cookies: Der Browser erlaubt sie jetzt standardmäßig, wie Chrome, auch wenn ein älteres SDK oder Ihr eigener Launcher keine Cookie-Option übergibt. --block-third-party-cookies blockiert sie.
• 0.42.0, Linux-Hosts: Das WebGL einer Linux-Persona rendert jetzt headed wie headless über Mesa auf EGL (der Host braucht libegl1), daher ändern sich Renderer-String, Erweiterungsliste und Limits des WebGL einer Headed-Linux-Persona einmalig, und zwar auf die Form, die Headless-Launches schon zeigten und die die meisten echten Linux-Rechner melden. Ein Headed-Launch unter Xvfb ohne Fenstermanager öffnet an den Bildschirm angepasst. Headless-Launches behalten ein realistisches Display, auch wenn eine Persona nicht greift, und serve() behält es, wenn Sie nur --window-position übergeben. Siehe Playwright & Puppeteer.
• Lizenzierter Build ab 154 r34, disableGpuFingerprint: Es ändert jetzt nur noch, was die GPU meldet. Das Auslesen von WebGL-Pixeln behält das Rauschen des Seeds pro Website, sodass readPixels und die Exporte eines WebGL-Canvas übereinstimmen. Vorher stoppte es nur das Rauschen von readPixels. Siehe Fingerprint-Flags.
• 0.41.1, menschenähnliche Eingaben: Mit humanize wird in ganzen Mausrad-Rasten gescrollt, wie mit einem echten Mausrad: 100 px pro Raste bei einer Windows-Identität, 120 unter Linux und 40 unter macOS. Eine gewünschte Distanz wird auf die nächste Raste gerundet (mindestens eine), daher scrollt mouse.wheel(0, 800) unter Windows 800 px und unter Linux 840. Beim Tippen wird bei schnellen Tastenpaaren jetzt manchmal die nächste Taste gedrückt, bevor die vorherige losgelassen ist. In .NET bewegt sich ein Humanizer, der mit einer Zahl geseedet wird, jetzt mit derselben motorischen Identität wie in Python und Node; vorher teilten sich alle Zahlen-Seeds ungleich null eine einzige. Siehe Menschenähnliche Eingaben.
• 0.41.0 auf dem lizenzierten Build ab r32: Die Persona erreicht den Browser über seine Umgebung statt über seine Kommandozeile; ein Tool, das den Seed aus der Prozessliste gelesen hat, findet ihn dort also nicht mehr (persona_env=False behält das alte Verhalten bei). Die Kontexte, die ein lokaler Launch anlegt, emulieren kein helles Farbschema mehr, sodass eine dunkle Persona überall dunkel meldet (übergeben Sie color_scheme, um eines festzulegen). Ein Headless-Launch unter Linux mit Persona bekommt einen Bildschirm in der Größe, die die Persona angibt. Siehe Launch-Optionen.
• 0.41.0, .NET unter Linux: Launches nutzen jetzt die gebündelten Schriften des Browsers, wie Python und Node es schon immer tun, statt der Schriften des Hosts. Eine Windows-Persona misst dort deshalb anders, jetzt so wie mit den anderen beiden SDKs. Siehe eigene Schriften unter Linux.
• 0.41.0, eine Linux-Persona auf einem Windows-Rechner: Das SDK warnt einmal pro Prozess. Windows betreibt die GPU über Direct3D, was die Limits von WebGL und WebGPU deckelt, und eine Persona kann ein Limit senken, aber nie über das des Treibers anheben; eine Linux-Persona meldet dort also Limits, die kein Linux-Rechner hat. Geben Sie unter Windows Windows an, oder betreiben Sie Linux-Personas unter Linux oder in Docker. quiet oder CLEARCOTE_NO_WARN unterdrücken die Warnung.
• Docker-Image sdk-0.41.0: Chrome kann mit seiner Sandbox laufen, wenn Sie den Container mit dem seccomp-Profil des Images starten; ohne das Profil läuft der Container wie bisher. Schriften für weitere Schriftsysteme sind eingebaut. Siehe Deployment.
• 0.40.0: Unter macOS startet launch() das Docker-Image von Clearcote (Docker Desktop erforderlich; docker=False schaltet das ab). Siehe macOS.

Nach dem Upgrade erneut prüfen

Ein neuer Build kann ein Signal verschieben. Führen Sie Ihre Fingerprint-Tests erneut aus (z. B. CreepJS) und prüfen Sie bei einem importierten Profil, ob es weiterhin kohärent lädt — siehe Verifizierung. Der aktuelle offene Build ist v0.1.0-pre.23 (Chromium 150.0.7871.114); der aktuelle lizenzierte Build ist 154.0.8037.57-r36. Was als Nächstes kommt, steht auf der Roadmap.