Mantener Clearcote actualizado

Sin clave de licencia, cada versión del SDK está fijada a un build abierto verificado por SHA-256, y actualizarlo es subir la versión del paquete como con cualquier otro. Con una clave, el SDK obtiene el build con licencia actual en cada lanzamiento, sin necesidad de subir de versión.

Qué builds hay disponibles

Las versiones mayores de Chromium que publicamos hoy o en las que estamos trabajando, y cuándo llegan a cada plan:

Si usas el SDK (recomendado)

Actualiza el paquete como cualquier otra dependencia:

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

En el siguiente launch(), el SDK detecta que el build que necesita no está en caché, lo descarga —el build abierto desde GitHub Releases, el build con licencia desde clearcotelabs.com— y verifica el SHA-256 antes de usarlo. Nada se ejecuta sin verificar. Cada build se guarda por separado en el directorio de caché de tu usuario —%LOCALAPPDATA%\clearcote\Cache en Windows, ~/.cache/clearcote en Linux (define CLEARCOTE_CACHE para cambiarlo de lugar)—, así que cada uno se descarga una sola vez. Los builds antiguos se conservan hasta que ejecutes clearcote clear-cache.

Varios programas, una sola caché

Los programas que comparten la caché se turnan para instalar un build (SDK 0.41.0+, tanto en Python como en Node y .NET): el primero lo descarga, los demás esperan y luego lo usan, y un build que otro programa está ejecutando nunca se reemplaza mientras está en uso. Un programa que espera se rinde a los 30 minutos con un mensaje que nombra el proceso que retiene la instalación (el lock es el archivo .install-lock de la carpeta de caché de ese build; el mensaje indica cuándo es seguro borrarlo). Un lock abandonado por un programa que se cayó se toma automáticamente.

Un build en caché cuyos archivos se dañaron o se eliminaron (una cuarentena del antivirus, una carpeta borrada) se repara en el siguiente lanzamiento con una sola descarga. Si sus archivos siguen en uso, el lanzamiento se detiene de inmediato y te pide que cierres todos los programas que usan ese navegador y lo intentes de nuevo. El lock requiere que todos los procesos que comparten la caché usen el SDK 0.41.0 o posterior; las versiones anteriores no lo esperan.

Windows: algunas configuraciones no pueden iniciar un build descargado desde donde está, por ejemplo un programa que se ejecuta dentro de una app empaquetada (MSIX), cuyas escrituras en %LOCALAPPDATA% redirige Windows (el lanzamiento falla con spawn UNKNOWN o con "the side-by-side configuration is incorrect"). En ese caso, el SDK hace una copia del build en ~/.clearcote/recovered, y todos los lanzamientos posteriores desde Python, Node o .NET la usan, así que no queda nada en la carpeta temporal y los lanzamientos repetidos arrancan en segundos (Python y Node desde 0.40.1, .NET desde 0.41.0). clearcote clear-cache también elimina esas copias; el SDK de .NET no tiene línea de comandos, así que ahí llama a WinLaunch.ClearRecovered().

Actualiza el build abierto sin actualizar el SDK

Sin clave, activa la actualización automática para usar el build abierto más reciente de GitHub en lugar del que fija el SDK. Se verifica contra el SHA256SUMS.txt de esa versión (y contra la clave de firma si tienes gpg instalado); si no se puede acceder a GitHub, vuelve al build fijado. Desde una terminal, clearcote update hace lo mismo. Con una clave no cambia nada: ya recibes el build con licencia actual.

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

El navegador en sí nunca “llama a casa” ni se actualiza solo. Sin clave, el navegador solo cambia cuando subes la versión del SDK o activas autoUpdate. Con una clave, el SDK toma cada nuevo build con licencia en el siguiente lanzamiento; en Pro puedes quedarte en un build con version.

Elegir un build

Pasa version (o define CLEARCOTE_BROWSER_VERSION): "latest", una versión mayor como "154", una versión exacta "154.0.8037.57" o una revisión con licencia "r36" / "154.0.8037.57-r36". Antes de descargar nada, una versión o una versión mayor se comprueba contra el catálogo publicado, y una revisión, contra el servidor de licencias. releaseChannel: "preview" (release_channel en Python, o CLEARCOTE_RELEASE_CHANNEL=preview) toma un build preview cuando existe. En el build con licencia, los builds anteriores, la fijación de versión y el canal preview son funciones de Pro; las claves gratuitas siempre reciben el más reciente.

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

Si usas el binario directo o Docker

• Binario directo (solo el build abierto; el build con licencia se ejecuta a través del SDK, clearcote serve o la imagen de Docker): descarga el nuevo archivo comprimido desde la página de Releases, verifica el checksum + la firma (consulta Verificación) y apunta executable_path / executablePath (o CLEARCOTE_BINARY) al nuevo chrome.
• Docker: ejecuta docker pull teamflatearth/clearcote para obtener la imagen más reciente y luego vuelve a crear tu contenedor. Las claves gratuitas requieren una imagen construida con el SDK 0.30.0 o posterior. Con una clave, monta -v clearcote-cache:/opt/xdg-cache para que el build con licencia se descargue una sola vez y no en cada contenedor nuevo. Consulta Despliegue.

El build con licencia: siempre al día y el primero en actualizarse

El build con licencia sigue el Chromium más reciente y los parches más nuevos, así que recibes las actualizaciones sin recompilar nada a mano. Define CLEARCOTE_LICENSE_KEY, pasa licenseKey o ejecuta clearcote login (Python/Node; npx clearcote login con una instalación local de npm): comprueba la clave y la guarda en ~/.clearcote/license.key, que leen todos los SDK, incluido el de .NET. Hay dos formas de conseguir una clave:

• Gratis con GitHub: un navegador a la vez, sin costo. Inicia sesión con una cuenta de GitHub que tenga al menos 30 días de antigüedad, abre “Licenses” en tu panel, haz clic en “Connect GitHub and get it free” y después en “Claim my free key” (una por cuenta de GitHub). La clave dura 30 días; renuévala gratis desde la misma página antes de que venza.
• Pro: el mismo build, con hasta 250 navegadores simultáneos, builds anteriores, fijación de versión y el canal preview, además de soporte por email del dueño del proyecto.

Las nuevas versiones mayores llegan primero al build con licencia. Cuando se compila una nueva versión mayor de Chromium, queda disponible de inmediato en Gratis con GitHub y en Pro; el build abierto la recibe más tarde, con el objetivo de unos 2 meses después del lanzamiento (hoy está en Chromium 150). El build abierto siempre es completamente abierto y reproducible; el build con licencia recibe la versión más nueva antes.

Cómo se cuentan los navegadores con licencia

Cada navegador que se inicia con una clave toma un slot del servidor de licencias y lo devuelve al cerrarse. Tu panel muestra cuántos están en uso, y clearcote info muestra el mismo número.

• Gratis con GitHub cuenta cada navegador. Hay un solo slot, así que un segundo navegador —en el mismo programa, en otro programa o en otra máquina— se rechaza con The free tier runs one browser at a time, and one is already running hasta que se cierre el primero. Un navegador que se cayó sin cerrarse libera su slot en un máximo de 6 minutos.
• Pro cuenta máquinas y cubre hasta 250 navegadores a la vez. Todos los navegadores de una misma máquina comparten el slot de esa máquina. Las suscripciones iniciadas antes del 26 de septiembre de 2026 conservan sus condiciones anteriores, sin límite; si necesitas más de 250, pídelo y lo ampliamos.
• Las claves gratuitas requieren el SDK 0.30.0 o posterior (Python, Node y .NET), porque para contar cada navegador el SDK tiene que reportar cada lanzamiento y mantener la licencia vigente mientras ese navegador se ejecuta. Un SDK anterior recibe SDK_UPGRADE_REQUIRED junto con el comando para actualizarlo, y si aun así llega al motor, el motor lo rechaza. Las claves Pro siguen funcionando con SDK anteriores como hasta ahora.
• Un navegador gratuito se detiene cuando pierde su slot. La comprobación es continua, no solo al arrancar: si se revoca la clave, el slot se devuelve desde otro lugar o la licencia supera su límite, un navegador gratuito que ya está abierto se cierra en unos 2 a 3 minutos. Los cortes de red breves (uno o dos heartbeats perdidos) se toleran; una caída de más de unos 2 a 3 minutos detiene un navegador gratuito de la misma manera.
• El plan gratuito siempre ejecuta el build más reciente. Pedir un build con licencia anterior o el canal preview devuelve FREE_LATEST_ONLY; fijar un build es una función de Pro.
• Descargas con una clave gratuita: hasta 10 builds distintos cada 24 horas. Un mismo build cuenta una sola vez, sin importar cuántas veces lo inicies.

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

Qué cambia al actualizar

La mayoría de las versiones del SDK no cambian nada que te obligue a actuar. Estas sí cambian lo que hace una configuración existente; todas las versiones aparecen en “Releases”, en tu panel.

• Build con licencia 154 r36, un seed existente: ahora un seed toma su tarjeta gráfica de entre varios modelos reales del propio fabricante de GPU de la máquina, en lugar de un solo modelo por fabricante, así que la mayoría de los seeds reportan una tarjeta distinta a la de r35. En una máquina con una tarjeta NVIDIA, un seed que declaraba hardware de gama de entrada (de 4 a 6 hilos de procesador, de 4 a 8 GB de memoria, una pantalla pequeña) ahora declara hardware de gama media o superior, y ahí ningún seed declara una pantalla táctil. Para conservar las identidades que tenían tus seeds antes de r36, define persona_schema=2 / personaSchema: 2. Consulta el mismo seed en máquinas distintas.
• Build con licencia 154 r36, cookies de terceros: ahora el navegador las permite por defecto, como Chrome, también cuando un SDK anterior o tu propio launcher no pasa ninguna opción de cookies. --block-third-party-cookies las bloquea.
• 0.42.0, hosts Linux: el WebGL de una persona de Linux ahora se renderiza a través de Mesa sobre EGL tanto en headed como en headless (el host necesita libegl1), así que la cadena del renderer de WebGL, la lista de extensiones y los límites de una persona de Linux en modo headed cambian una vez, a la forma que ya mostraban los lanzamientos headless y que reporta la mayoría de las máquinas Linux reales. Un lanzamiento headed bajo Xvfb sin gestor de ventanas se abre ajustado a la pantalla. Los lanzamientos headless conservan una pantalla realista incluso cuando la persona no llega a aplicarse, y serve() la conserva cuando solo pasas --window-position. Consulta Playwright & Puppeteer.
• Build con licencia 154 r34 y posteriores, disableGpuFingerprint: ahora solo cambia lo que reporta la GPU. La lectura de píxeles de WebGL conserva el ruido por sitio del seed, así que readPixels y las exportaciones de un canvas WebGL coinciden. Antes, detenía únicamente el ruido de readPixels. Consulta Flags de huella digital.
• 0.41.1, entrada humanizada: con humanize, el scroll avanza en muescas enteras de la rueda del mouse, como lo hace una rueda real: 100 px por muesca con una identidad de Windows, 120 en Linux y 40 en macOS. Una distancia solicitada se redondea a la muesca más cercana (como mínimo una), así que mouse.wheel(0, 800) desplaza 800 px en Windows y 840 en Linux. Ahora, en pares rápidos, la escritura a veces presiona la siguiente tecla antes de soltar la anterior. En .NET, un humanizer con un seed numérico ahora se mueve con la misma identidad motora que en Python y Node; antes, todos los seeds numéricos distintos de cero compartían una sola. Consulta Entrada humanizada.
• 0.41.0 en el build con licencia desde r32: la persona llega al navegador a través de su entorno y no de su línea de comandos, así que una herramienta que leía el seed de la lista de procesos ya no lo encuentra (persona_env=False conserva el comportamiento anterior). Los contextos que crea un lanzamiento local ya no emulan un esquema de colores claro, así que una persona oscura reporta el modo oscuro en todas partes (pasa color_scheme para fijar uno). Un lanzamiento headless en Linux con persona recibe una pantalla del tamaño que declara la persona. Consulta Opciones de lanzamiento.
• 0.41.0, .NET en Linux: los lanzamientos ahora usan las fuentes incluidas con el navegador, como siempre lo hicieron Python y Node, en lugar de las del host. Una persona de Windows mide ahí de otra forma, ahora igual que con los otros dos SDK. Consulta tus propias fuentes en Linux.
• 0.41.0, una persona de Linux en un equipo Windows: el SDK avisa una vez por proceso. Windows usa la GPU a través de Direct3D, que limita los valores máximos de WebGL y WebGPU, y una persona puede bajar un límite, pero nunca subirlo por encima del que aplica el driver, así que una persona de Linux ahí reporta límites que ninguna máquina Linux tiene. Declara Windows en Windows, o ejecuta las personas de Linux en Linux o en Docker. quiet o CLEARCOTE_NO_WARN silencian el aviso.
• Imagen de Docker sdk-0.41.0: Chrome puede ejecutarse con su sandbox si inicias el contenedor con el perfil seccomp de la imagen; sin él, el contenedor funciona como antes. Las fuentes de escrituras vienen integradas. Consulta Despliegue.
• 0.40.0: en macOS, launch() ejecuta la imagen de Docker de Clearcote (hace falta Docker Desktop; docker=False lo desactiva). Consulta macOS.

Después de actualizar, vuelve a verificar

Un build nuevo puede cambiar alguna señal. Vuelve a ejecutar tus tests de huella digital (por ejemplo, CreepJS) y, si usas un perfil importado, confirma que sigue cargando de forma coherente; consulta Verificación. El build abierto actual es v0.1.0-pre.23 (Chromium 150.0.7871.114); el build con licencia actual es 154.0.8037.57-r36. En la hoja de ruta puedes ver lo que viene.