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:

Build de Chromium	Código abierto	Clave gratis y Pro
Con licencia, actual156r57 · 25 Oct 2026	~2 meses después	Disponible ya
Con licencia, anterior155·154·153·152	Todavía no	Solo Pro — version="155"
Abierto, actual151v0.1.0-pre.25 · 28 Oct 2026	Disponible ya	Disponible ya
Abierto, anterior150·149	Disponible ya	Disponible ya

Todos los builds: Windows + Linux x64. Una nueva versión mayor de Chromium llega al build con licencia —gratis para un navegador, o Pro— el mismo día en que se compila; el build abierto recibe esa misma versión mayor, totalmente abierta y reproducible, unos 2 meses después.

Si usas el SDK (recomendado)

Actualiza el paquete como cualquier otra dependencia:

bash

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.

javascript

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 "156", una versión exacta "156.0.8078.47" o una revisión con licencia "r57" / "156.0.8078.47-r57". 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 vienen con Personal y Pro; las claves gratuitas siempre reciben el más reciente.

bash

clearcote install --version 156        # 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 tres formas de conseguir una clave:

Gratis con GitHub: un navegador a la vez, sin costo. Abre “Licenses” en tu panel y solicítala de una de tres formas: conecta una cuenta de GitHub que tenga al menos 30 días de antigüedad (“Connect GitHub and get it free”), pasa una verificación de tarjeta (nunca se le cobra a la tarjeta; no se aceptan tarjetas prepago) o inicia sesión con una cuenta de Google Workspace de empresa (hasta 3 solicitudes por dominio de empresa cada 30 días). Una clave por cuenta de GitHub, tarjeta o cuenta de Google. La clave dura 30 días; renuévala gratis desde la misma página antes de que venza.
Personal: el mismo build, con hasta 15 navegadores simultáneos, builds anteriores, fijación de versión y el canal preview; sin soporte por email.
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 151). 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.
Personal cuenta cada navegador, hasta 15 a la vez. Cada navegador ocupa su propio slot, en una máquina o en varias, y el 16.º se rechaza hasta que se cierre alguno. Personal requiere el SDK 0.55.0 o posterior (Profile Manager 0.19.0).
Pro cubre hasta 250 navegadores a la vez. Con el SDK 0.55.0 o posterior, cada navegador ocupa su propio slot, así que el panel cuenta navegadores, no máquinas; un SDK anterior sigue compartiendo un slot por 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, agrega bloques de 100 o pídelo.
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 requiere Personal o 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.

bash

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 156 r53, valores predeterminados del navegador: el guardado de contraseñas está activado, como en Chrome: el navegador ofrece guardar una contraseña después de iniciar sesión (la opción del Gestor de contraseñas "Ofrecer guardar contraseñas y llaves de acceso" lo desactiva). Google vuelve a ser el motor de búsqueda predeterminado, en perfiles nuevos y existentes, así que una búsqueda escrita en la barra de direcciones va a Google; elige otro en Configuración > Motor de búsqueda. Con Playwright, usa junto con él el SDK 0.63.3 o una versión posterior. Las identidades no cambian.
0.64.1: personaSchema / persona_schema / PersonaSchema acepta 5 y 7 en todos los SDK.
0.64.0, sin clave de licencia: el SDK descarga el build abierto de Chromium 151, versión v0.1.0-pre.25, en lugar de 150. version="150" sigue obteniendo el build de 150.
Identidades servidas desde el 2026-10-26 (r52, y también r51), un seed existente: el esquema de persona predeterminado ahora es el 7, un modelo de máquina en el que la tarjeta gráfica determina el tipo de máquina, su procesador, hilos, memoria y pantalla, así que un seed obtiene una máquina distinta de la de antes. Para conservar la identidad que tenía un seed en r45 a r51, define persona_schema=5 / personaSchema: 5. Consulta el mismo seed en máquinas distintas.
Build con licencia 156 r51: la identidad viene del servicio de personas de Clearcote en cada lanzamiento, así que la máquina necesita HTTPS saliente hacia persona.clearcotelabs.com (y persona-us como respaldo), y el navegador necesita el SDK 0.63.0 o posterior (claves gratuitas 0.63.2) y Profile Manager 0.27.0 o posterior. Las identidades no cambiaron con r51. Consulta Arquitectura.
Build con licencia 155 r45, un seed de Windows existente: cada perfil de Windows obtiene su propio conjunto de fuentes de Office, así que su lista de fuentes cambia una vez. persona_schema=4 / personaSchema: 4 conserva exactamente la identidad de r44.

Notas anteriores (builds 154, SDK 0.40 a 0.42)

Build con licencia 154 r37, un seed existente: ahora un seed toma su tarjeta gráfica de entre una gama más amplia de modelos reales del propio fabricante de GPU de la máquina, cada uno tan común como en el tráfico real de navegadores, así que la mayoría de los seeds reportan una tarjeta distinta a la de r36; una máquina sin tarjeta gráfica ahora declara gráficos integrados de Intel o de AMD, y no solo de Intel. Nada más cambia en el hardware de un seed. Para conservar las tarjetas que tenían tus seeds en r36, define persona_schema=3 / personaSchema: 3; las identidades anteriores a r36 conservan las suyas con 2, como antes. Consulta el mismo seed en máquinas distintas.
Build con licencia 154 r37, selector de archivos e impresión en headless: un selector de archivos que abre una página y que tu script no maneja ahora queda abierto de 4 a 9 segundos y luego se cancela, como haría un usuario que no lo quería; mientras está abierto, esa pestaña no puede abrir popups ni ventanas de imagen en imagen, como en un navegador headed. window.print() ahora retiene la página unos 1.2 segundos y luego dispara afterprint, como una vista previa de impresión que el usuario cierra. Antes, ambos respondían en milisegundos. Las subidas con setInputFiles o con un evento filechooser que tu script maneja funcionan como antes.
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.
Build con licencia 154 r36, solicitudes de permiso en headless: un navegador headless ya no rechaza en el acto la solicitud de permiso de un sitio (notificaciones, cámara, micrófono, ubicación y similares). La solicitud queda sin respuesta, como un aviso de permiso abierto en un navegador headed, así que un script que espera Notification.requestPermission() o getUserMedia() ahora se queda esperando. Concede el permiso antes (en Playwright, context.grant_permissions() / context.grantPermissions()) o pasa --deny-permission-prompts para recuperar el rechazo de antes.
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.25 (Chromium 151.0.7922.108); el build con licencia actual es 156.0.8078.47-r57. En la hoja de ruta puedes ver lo que viene.