La versión 2.1.238 de Claude Code trae dos correcciones de naturaleza muy distinta y ambas conviene mirarlas. La primera es de estabilidad: se acaba el crecimiento ilimitado de memoria en sesiones interactivas largas. La segunda es de seguridad y es la importante: ejecutar el headersHelper de un servidor MCP definido en el .mcp.json de un proyecto ahora exige pasar por el diálogo de confianza de carpeta. La versión toca además la seguridad de los marketplaces de plugins, aunque el detalle de ese apartado no se ha publicado.
La sesión que crecía hasta que la matabas
Empecemos por lo que se nota a diario. Una fuga de memoria en una herramienta de terminal tiene un patrón muy reconocible: todo va bien durante la primera hora y se degrada después. La sesión se vuelve lenta, el equipo empieza a tirar de intercambio, el ventilador se dispara, y al final acabas cerrando y abriendo de nuevo sin saber muy bien por qué.
Ese reinicio tiene un coste que casi nunca se contabiliza: pierdes el contexto de la sesión. Todo lo que la herramienta había ido acumulando sobre el proyecto, sobre lo que ya habíais intentado y sobre lo que no funcionó desaparece, y volver al punto donde estabas exige reconstruirlo a mano. Quien deja Claude Code abierto toda la jornada sobre el mismo proyecto es quien más lo sufría, que es justamente el perfil de uso que la herramienta lleva meses fomentando.
No es una función nueva y no va a aparecer en ningún resumen del año, pero es de esas correcciones que cambian la relación con una herramienta: la diferencia entre algo que abres para una tarea y algo que puedes dejar corriendo mientras trabajas.
El vector: un repositorio ajeno que ejecuta un comando tuyo
La corrección de seguridad exige entender qué es un headersHelper, porque el nombre no ayuda. Cuando configuras un servidor MCP que requiere autenticación, necesitas enviarle cabeceras —un token, normalmente— y esas cabeceras a menudo no son fijas: caducan, se renuevan, se obtienen de otro sitio. Para resolverlo se define un helper: un comando que Claude Code ejecuta para obtener las cabeceras antes de hablar con el servidor.
Hasta aquí, un mecanismo perfectamente razonable. El problema aparece al combinarlo con dónde puede vivir esa configuración. Un .mcp.json de proyecto es un fichero que está dentro del repositorio, y por tanto viaja con el código: lo escribe quien creó el repositorio, no necesariamente quien lo abre.
Junta las dos piezas y el vector se ve solo. Clonas un repositorio —una plantilla de WordPress, un plugin que te pasa un cliente, un proyecto de ejemplo que encontraste para resolver algo rápido—, lo abres con Claude Code y, si ese repositorio traía un .mcp.json con un helper definido, se ejecuta un comando que tú no has escrito ni has leído. No hace falta que apruebes una acción del modelo: basta con abrir la carpeta.
No hacía falta aprobar nada. Bastaba con clonar el repositorio y abrirlo en la carpeta equivocada.
Por qué la confianza de carpeta es la barrera adecuada
La solución elegida —exigir el diálogo de confianza de carpeta— es la correcta, y merece la pena explicar por qué frente a otras alternativas posibles. Podrían haber pedido una confirmación específica para cada helper, pero eso habría añadido un aviso más a una herramienta que ya pide bastantes, y los avisos que se repiten se aprueban sin leer. Podrían haberlo prohibido directamente, y habrían roto configuraciones legítimas de mucha gente.
La confianza de carpeta acierta porque coloca la decisión en el momento en que el usuario ya está decidiendo eso mismo: cuando abres una carpeta nueva y te preguntan si te fías de su contenido, esa es la pregunta correcta, formulada una vez y en el instante en que tiene sentido. Un repositorio en el que confías puede ejecutar sus helpers; uno que acabas de clonar sin mirar, no. Es el mismo principio que aplican los editores de código desde hace años, y funciona porque no fragmenta la decisión en veinte confirmaciones que nadie lee.
⚠️ Revisa esto antes de seguir
Busca los .mcp.json que tengas en proyectos que no hayas creado tú —plantillas, repositorios de clientes, ejemplos clonados— y mira si definen algún helper. Y a partir de ahora, cuando el diálogo de confianza aparezca al abrir una carpeta ajena, léelo en lugar de aceptarlo por reflejo: es el único punto del proceso donde esta decisión se toma.
La configuración de proyecto es superficie de ataque
Esta corrección encaja en un patrón que se repite y que conviene interiorizar. Durante años dimos por sentado que abrir un proyecto era una operación inofensiva: ver ficheros no ejecuta nada. Esa premisa dejó de ser cierta cuando las herramientas empezaron a leer configuración del propio repositorio para saber cómo comportarse. Desde ese momento, el repositorio dejó de ser datos y pasó a ser, en parte, instrucciones.
Y el ecosistema de extensiones amplifica el problema. Cada servidor MCP, cada plugin y cada configuración compartida es un sitio más donde alguien puede colocar algo que se ejecute en tu máquina. Que esta misma versión toque también la seguridad de los marketplaces de plugins apunta en la misma dirección: el fabricante está cerrando, uno a uno, los puntos donde contenido de terceros podía actuar sin una decisión explícita del usuario.
Para quien trabaja con proyectos ajenos a diario —y ese es el día a día de cualquiera que mantenga sitios de clientes— la conclusión práctica es sencilla y no depende de ninguna versión: actualiza, y trata los ficheros de configuración de un repositorio con la misma desconfianza con la que tratarías un script. Porque, a efectos de lo que pueden llegar a ejecutar, es exactamente lo que son.
