La última versión de Cline corrige tres pérdidas silenciosas de contexto: qué reglas, hooks y resúmenes de tareas largas volver a comprobar (2026)

La primera corrección se refiere a las reglas. La nota de lanzamiento dice: "El panel de Reglas solo enumeraba .clinerules y la carpeta global Documents, por lo que las reglas cargadas desde .cline/rules, ~/.cline/rules o ~/Cline/Rules se aplicaban al modelo pero no aparecían en el panel; y en Windows con una carpeta Documents redireccionada a OneDrive, las reglas globales no se encontraban en absoluto".

Dos fallos se esconden en esa frase: en tres ubicaciones las reglas funcionaban pero eran invisibles, y en Windows con redirección de OneDrive las reglas globales no se cargaban en absoluto.

La segunda corrección se refiere a los hooks. "Los hooks UserPromptSubmit y TaskStart pueden volver a inyectar contexto. Lo que esos hooks devolvían como contextModification se descartaba (solo sobrevivía cancel), por lo que un hook destinado a añadir hechos del repositorio o reglas internas a una tarea no hacía nada silenciosamente". La nota añade que el contexto "ahora se entrega como un bloque <hook_context> en la primera solicitud de la ejecución, igual que antes de la regresión".

La tercera corrección se refiere a las tareas largas. "La compactación ya no recurre silenciosamente al truncamiento a mitad de una tarea larga. El resumidor conservaba las credenciales capturadas cuando se iniciaba la tarea, por lo que una vez que se actualizaban, su solicitud fallaba con un error de autorización que se silenciaba; ahora sigue las credenciales y el modelo actuales de la tarea".

El lanzamiento de la CLI describe el mismo fallo desde el lado del usuario: "obtenías una transcripción recortada en lugar de un resumen, de forma más visible en los modelos cline-free/*". También señala que "El resumidor también se mantenía en el modelo original después de un cambio de modelo a mitad de sesión".

El lanzamiento de escritorio va más allá. "Las sesiones largas en la aplicación de escritorio ahora se compactan automáticamente. La autocompactación nunca se había ejecutado realmente aquí". Y es explícito en que esto no era nuevo: "Esto no fue una regresión reciente; la brecha se remontaba a cuando la compactación pasó a ser opcional en el núcleo en abril".

Un cambio más en la compactación aparece tanto en las notas de la CLI como del SDK. La compactación solía activarse según una estimación de caracteres, y el contenido denso rompía la estimación: "La compactación ahora se activa según el uso real de tokens de tu proveedor en lugar de una estimación de caracteres". La nota de la CLI detalla el síntoma antiguo: una sesión larga "podía alcanzar el límite real de contexto sin llegar a compactarse y luego verse reducida a un puñado de tokens de salida por turno".

Comencemos con el límite que más importa. Una nota de lanzamiento describe lo que hace el código desde el momento en que actualizas. Nada en estas notas describe la reparación de sesiones que se ejecutaron antes de la actualización. Una tarea truncada en agosto sigue siendo la transcripción en la que se convirtió.

La corrección de los hooks también es más estrecha de lo que parece. El lanzamiento de la CLI indica que "El control de hooks al inicio de la ejecución (cancel e inyección de contexto desde los scripts agent_start/agent_resume) permanece inactivo en la CLI a la espera de una activación deliberada". Por lo tanto, si tus hooks se ejecutan a través de la CLI, la corrección de la extensión no describe tu configuración.

La corrección de las reglas cambia lo que muestra el panel y cambia lo que la promesa de la documentación significa ahora en la práctica. La página de reglas de Cline dice: "Todos los tipos de reglas detectados aparecen en el panel de Reglas, donde puedes activarlos o desactivarlos individualmente". Después de la v4.1.20, esa frase describe el comportamiento de la extensión para las tres ubicaciones nombradas en la corrección. Antes de ella, esas ubicaciones se aplicaban pero estaban ausentes de la lista.

Esto tiene una consecuencia directa para cualquiera que usara el panel como una lista de verificación. Una guía anterior aquí sobre cómo mapear qué reglas de Cline están activas antes de una tarea trata al panel como un inventario de reglas detectadas. En versiones anteriores a la 4.1.20, las reglas en .cline/rules, ~/.cline/rules y ~/Cline/Rules estaban fuera de ese inventario a pesar de llegar al modelo. La lógica de dos puertas de esa guía (el interruptor del panel más las propias condiciones de la regla) sigue vigente; el paso del inventario necesita una versión actual para estar completo.

La corrección de la compactación restaura un diseño documentado en lugar de introducir uno nuevo. La página Auto Compact de Cline describe el comportamiento previsto ("Crea un resumen completo de todo lo que ha sucedido" y "Reemplaza el historial de conversación con el resumen") y lo contrasta con lo que había antes: "Anteriormente, Cline truncaba los mensajes más antiguos al alcanzar los límites de contexto, perdiendo contexto importante". El error devolvía las tareas largas afectadas al comportamiento anterior sin avisar.

La misma página también deja claro que el truncamiento sigue siendo el diseño en algunos modelos: "Con otros modelos, Cline recurre al truncamiento de contexto estándar basado en reglas, incluso si Auto Compact está activado". Por lo tanto, el truncamiento después de este lanzamiento no es automáticamente un error. Es una señal para comprobar en qué modelo estaba la tarea.

La primera lectura que circulará es "Cline estaba ignorando mis reglas". Para la mayoría de los usuarios, eso no es lo que dice la nota. En tres ubicaciones, las reglas "se aplicaban al modelo pero no aparecían en el panel". El modelo las estaba siguiendo; tú simplemente no podías verlas. La excepción es Windows con una carpeta Documents redireccionada a OneDrive, donde las reglas globales "no se encontraban en absoluto". Ese grupo debería tratar la corrección como un cambio de comportamiento, no solo de visualización.

La segunda lectura es que la compactación no es confiable y debería desactivarse. Eso es entender la historia al revés. La resumización es el reemplazo del truncamiento, y el fallo consistió en que el resumidor le devolvió silenciosamente el trabajo al truncamiento. Desactivar la compactación no evita el comportamiento antiguo; lo garantiza una vez que una tarea larga se queda sin espacio.

La tercera lectura es que los hooks ahora funcionan en todas partes. Vuelven a funcionar en la ruta UserPromptSubmit and TaskStart de la extensión. La nota de la CLI dice que su inyección de contexto al inicio de la ejecución "permanece inactiva en la CLI a la espera de una activación deliberada", y el lanzamiento del SDK describe un nuevo canal de inicio de ejecución para los hosts que se basan en él. El lugar donde se ejecuta tu hook decide cuál de esas frases se aplica a ti.

La mala interpretación que más vale la pena resistir es la general: que un panel, un hook o un resumen demuestren que el contexto llegó. Este lanzamiento documenta tres casos donde la superficie visible y el contexto real no coincidían. También es el mismo tipo de problema que hace que los agentes parezcan ignorar los archivos de instrucciones; la pregunta rara vez es si el archivo existe, sino si la sesión específica lo cargó.

No puedes auditar el contexto perdido de una sesión pasada. Puedes asegurarte de que la versión actual se esté ejecutando en todos los lugares donde usas Cline, y puedes comprobar los tres canales con un registro guardado fuera de la herramienta.

Paso 1: Actualiza cada superficie de Cline que uses realmente

Las correcciones se lanzaron por separado para cada superficie. La corrección de la extensión de VS Code está en la v4.1.20. Las correcciones de compactación y reglas de la aplicación de escritorio están en la versión de escritorio v0.0.33. Las correcciones de compactación, activación por tokens y reglas de la CLI están en cli-v3.0.63. Si mueves una tarea entre la extensión y la CLI, ambas deben estar actualizadas, porque las notas de lanzamiento describen el comportamiento de cada superficie por separado.

Escribe en qué versión está cada superficie. Cuando surja una duda sobre el comportamiento el próximo mes, eso será lo primero que querrás saber.

Paso 2: Haz el inventario de reglas desde el disco y luego compáralo con el panel

No empieces por el panel. Empieza por las ubicaciones que Cline documenta y haz una lista de lo que realmente hay allí.

Las reglas del espacio de trabajo pueden residir en .clinerules/ o .cline/rules/; la documentación dice: "Se buscan en ambos directorios cuando están presentes, por lo que no es necesario copiar las reglas en ambas ubicaciones". Las reglas globales residen en la carpeta Cline Rules dentro de Documents, y la documentación añade: "Cline también busca en ~/.cline/rules y ~/Cline/Rules para encontrar reglas globales". En Windows, también comprueba las ubicaciones de Documents redireccionadas a OneDrive. Cline además "lee instrucciones globales de AGENTS para múltiples herramientas desde ~/.agents/AGENTS.md ".

Haz una lista de cada archivo que encuentres, luego abre el panel de Reglas en la extensión actualizada y ve marcándolos. Cualquier cosa que esté en el disco y falte en el panel después de la actualización vale la pena reportarla. Cualquier cosa en el panel que no esperaras (un archivo de una herramienta antigua, una regla global escrita hace años) vale la pena leerla, porque antes de este lanzamiento algunas de ellas llegaban al modelo sin aparecer allí.

Si estás en Windows con OneDrive, comprueba una cosa más: si una regla global de la que dependes se está siguiendo realmente ahora. La nota dice que esas reglas "no se encontraban en absoluto", por lo que el comportamiento puede cambiar después de la actualización.

Paso 3: Ejecuta una tarea larga y confirma lo que puedes ver

La página Auto Compact de Cline nombra la señal visible: "Verás una llamada a la herramienta de resumización cuando esto suceda, mostrando el costo como cualquier otra llamada a la API". En una tarea larga, búscala. Si una tarea larga en un modelo que admite Auto Compact se queda sin espacio y no aparece ninguna llamada de resumización, ese es el caso que describe la corrección, y vale la pena registrar la versión y el modelo antes de reportarlo.

Para los hooks, añade un marcador inofensivo al contexto que inyecta tu hook (una sola línea con la fecha) y pídele al agente que lo repita al inicio de una tarea. Si puede hacerlo, el contexto llegó. Si ejecutas hooks a través de la CLI, espera el comportamiento "permanece inactivo" de la nota y planifica en consecuencia.

El principio general detrás de las tres comprobaciones es el mismo que en qué conservar cuando se activa la autocompactación: decide de antemano qué hechos deben sobrevivir a una sesión larga y colócalos en un lugar donde un resumen no pueda descartarlos.

Las tres comprobaciones anteriores dependen de una cosa: un registro breve, guardado fuera de la herramienta, de lo que se supone que el agente debe saber. MemoryLake es un lugar para guardar ese registro de modo que no dependa de si un panel, un hook o un resumidor se comportaron correctamente en una sesión determinada.

Tú mismo escribes las entradas, con tus propias palabras. No se lee, escribe ni elimina nada de las carpetas de reglas de Cline, su historial de tareas o el almacenamiento de ningún proveedor.

Paso 1: Crea una clave API

Inicia sesión y genera una clave desde el panel de control. La clave es lo que permite a un agente leer las entradas que has escrito, independientemente de qué superficie de Cline (extensión, escritorio o CLI) esté ejecutando la tarea.

Paso 2: Sube tus primeros recuerdos

Comienza con los hechos que una transcripción truncada perdería primero: las decisiones tomadas al principio de una tarea larga, las restricciones que un hook debía inyectar, las reglas internas que residen en una carpeta global. Un hecho por entrada, con el motivo adjunto.

Paso 3: Conecta tu IA y agentes

Apunta tus agentes al espacio de trabajo. Las decisiones estarán disponibles al inicio de cada tarea, lo que significa que una sesión larga que pierda sus primeros turnos seguirá conservando la parte importante.

El primer cambio práctico es el peso que puede tener el panel. Después de actualizar, es un mejor inventario, pero sigue siendo una vista de lo que Cline detectó en lugar de un registro de lo que tú planeabas. Mantener tu propia lista es lo que te permite notar la próxima discrepancia en lugar de heredarla.

El segundo es cómo interpretas una tarea larga. Una transcripción recortada y una resumida pueden parecer similares desde dentro de la conversación, porque ambas dejan al agente trabajando con menos de lo que empezó. La diferencia es si las decisiones iniciales sobrevivieron. Cualquiera que haya visto a Cline olvidar lo que estaba haciendo antes en una tarea conoce el síntoma; este lanzamiento identifica una de sus causas.

El tercero es para qué sirve un Memory Bank. La guía de Memory Bank de Cline sugiere que "dejes que Auto Compact se encargue de la gestión rutinaria del contexto" y reserves las actualizaciones manuales para los puntos de control (consejo repetido en la guía para configurar el Memory Bank de Cline). Esa división sigue teniendo sentido, con una advertencia para cualquier versión anterior a estas: la gestión rutinaria del contexto no siempre ocurría de la forma descrita en la documentación, por lo que los archivos de puntos de control soportaban más carga de la que podrías haber supuesto.

El cuarto es cómo comparas las configuraciones de memoria para Cline: juzga cada una por lo que sobrevive a un fallo en la capa inferior, no solo por cómo se comporta cuando todo funciona.

Mantén tu propio inventario de archivos de reglas. Una lista de rutas y un propósito de una sola línea para cada una es suficiente. Es la única manera de saber si un panel está completo.

Registra la versión junto con el síntoma. Tres superficies lanzaron correcciones independientes el mismo día. Un reporte que nombre la superficie y la versión es algo sobre lo que alguien puede actuar.

Coloca las decisiones iniciales en algún lugar fuera de la transcripción. La primera hora de una tarea larga es la parte más expuesta al truncamiento. Cualquier cosa decidida allí de la que dependa el resto de la tarea debe escribirse a medida que se decide.

Marca el contexto inyectado para poder confirmar que llegó. Una sola línea con fecha en la salida de un hook convierte la pregunta "¿funcionó el hook?" en una duda que puedes resolver en un solo turno.

Comprueba el modelo antes de culpar a la función. Cline documenta que algunos modelos recurren al truncamiento basado en reglas incluso con Auto Compact activado. El truncamiento en esos modelos es el diseño, no el error.

Vuelve a auditar periódicamente lo que el agente cree. El mismo hábito detrás de auditar lo que tu IA recuerda se aplica aquí: la única comprobación confiable es preguntarle al agente qué sabe y comparar la respuesta con tu propio registro.

Las notas de la versión v4.1.20 de Cline, y las notas de escritorio y de la CLI publicadas junto a ellas, son específicas de una manera en que las notas de lanzamiento rara vez lo son. Nombran las ubicaciones que el panel omitió, el resultado del hook que se estaba descartando y la razón exacta por la que falló el resumidor. También dicen claramente que una de las brechas se remontaba a abril.

Nada de eso repara una sesión que ya se ejecutó. Lo que te da es un mapa de dónde mirar: las reglas en el disco frente al panel, el contexto del hook frente a lo que el agente puede repetir, y la llamada de resumización que deberías ver en una tarea larga.

Actualiza cada superficie, haz el inventario desde el disco y guarda las decisiones importantes en algún lugar donde una transcripción truncada no pueda llevárselas. El panel, los hooks y el resumidor están mejor hoy de lo que estaban la semana pasada. Un registro que lleves tú mismo es lo que te indicará cuándo uno de ellos vuelve a fallar.