Filtración del código de Claude Code expone su acceso al sistema y el alcance de la telemetría
La Filtración del código de Claude Code ha puesto bajo la lupa el cliente de agente de programación de Anthropic al detallar, a nivel de implementación, el alcance del acceso local, la captura de contexto y los canales de telemetría que pueden operar en dispositivos donde se instala. Aunque no se describe como un rootkit ni implica “kernel persistence”, el análisis del código filtrado sugiere capacidades de control y recopilación de información más amplias de lo que muchos usuarios asumirían al aceptar términos de uso en entornos no aislados.
El informe original parte de un análisis de código que, según se indica, llevaba meses circulando entre quienes habían realizado ingeniería inversa del binario. En paralelo, el debate se intensifica por referencias en documentación judicial vinculada a un litigio de Anthropic con el gobierno de EE. UU., donde se discutieron riesgos de “supply chain” y escenarios de control o alteración del comportamiento del modelo durante operaciones, afirmaciones que la compañía ha negado en ese contexto.
Filtración del código de Claude Code: qué revela sobre acceso y control
Según el análisis, en entornos comerciales y de consumo fuera de nubes gubernamentales aisladas o despliegues “air-gapped”, Claude Code puede operar con un conjunto de funciones que amplían su visibilidad sobre prompts, respuestas y datos derivados de herramientas (tools) ejecutadas en la máquina: lectura y escritura de archivos, resultados de búsquedas locales, comandos shell y trazas asociadas a ejecución. El punto crítico no es solo la ejecución local, sino la posibilidad de que parte de ese contexto termine incorporándose a solicitudes que viajan hacia la API, dependiendo de la configuración, flags y features activadas.
Telemetría persistente y analítica de producto
El código analizado describe un sistema de analítica y feature gating que puede registrar eventos y metadatos de sesión (por ejemplo, identificadores de usuario y sesión, versión de la app, plataforma, tipo de terminal y señales organizacionales). También se menciona la coexistencia o migración entre plataformas de experimentación/analítica como Statsig y GrowthBook, con capacidad para operar incluso cuando hay cortes de red mediante almacenamiento local de eventos y reintento posterior.
Políticas remotas y “remote managed settings”
Otro bloque relevante es la presencia de “remote managed settings” para despliegues enterprise: un servidor de configuración que, según la descripción, podría empujar un objeto de políticas (policySettings) y aplicar cambios tras un ciclo de sondeo periódico. En el análisis se afirma que esas políticas podrían impactar variables de entorno y comportamiento del cliente con “hot reload”, con avisos solo bajo ciertas condiciones definidas por el propio software.
Actualizaciones automáticas y control de versiones
El componente de auto-updater se describe como una verificación en el arranque que consulta configuración de versión asociada al sistema de feature flags/experimentos. En términos operativos, esto puede permitir exigir versiones mínimas o deshabilitar versiones concretas, algo común en software gestionado, pero sensible en herramientas que operan con acceso a repositorios y archivos locales.
Filtración del código de Claude Code y el “computer use” (control de escritorio)
El análisis menciona un conjunto de capacidades con nombre en clave asociado a “computer use” y control de escritorio, atribuyéndole acciones como clicks de ratón, entrada de teclado, acceso al portapapeles y captura de screenshots. Este tipo de funciones, cuando se combinan con agentes que ejecutan herramientas, eleva el listón de riesgo: la superficie de exposición no se limita a lo que el usuario copia/pega en un chat, sino a lo que la automatización puede observar o accionar durante una sesión.
Errores, trazas y posible exposición de rutas
En el bloque de “error reporting” se indica el uso de un sistema de reporte de excepciones capaz de adjuntar datos como el directorio de trabajo actual, lo que puede revelar nombres de proyectos, rutas locales u otros metadatos del entorno de desarrollo, además de estados de feature flags y detalles de la sesión.
Entornos “clasificados”: condiciones para reducir el “phoning home”
El análisis sostiene que una organización podría recortar comunicación remota si el tráfico de inferencia y servicios asociados se canaliza por proveedores y entornos controlados (por ejemplo, nubes sector público), se bloquean endpoints de analítica/telemetría con firewall, se desactiva la actualización automática y se fijan versiones. También se citan flags de configuración orientados a limitar memoria/telemetría y a redirigir endpoints de API a destinos privados. La conclusión implícita es que, sin estas barreras, el cliente mantiene más vías para intercambio de datos y cambios de comportamiento gestionados.
Retención de datos: paralelismos con el debate de Microsoft Recall
La cobertura compara el debate con el caso de Microsoft Recall, por similitudes en la captura de actividad y su persistencia. En este caso, se describe que el cliente puede guardar registros locales en texto plano (formato JSONL) de tool calls y acciones (lecturas, búsquedas, ediciones, ejecución de comandos), material que, dependiendo de features como consolidación de “memory”, podría terminar inyectado en prompts futuros y por tanto viajar a la API.
El artículo original también cita políticas de retención: para planes de consumo se menciona una ventana más larga si el usuario opta por compartir datos para entrenamiento y una retención más corta si no, mientras que en planes comerciales se habla de retención estándar limitada y una opción de “zero-data retention”. Estos puntos deben verificarse siempre contra la documentación vigente del proveedor.
Instrucciones “UNDERCOVER” en repositorios open source
Entre los hallazgos más llamativos se menciona un archivo de instrucciones para operar “UNDERCOVER” en repositorios públicos/open source, evitando referencias internas y ocultando la autoría por IA en mensajes de commit y descripciones de PR. En un momento en que algunos proyectos han restringido contribuciones generadas por IA, esta directriz apunta a un choque directo entre normas comunitarias y automatización asistida.
Fuentes, contexto y respuesta del proveedor
La discusión se apoya en un análisis externo del código filtrado y en documentación judicial citada por el medio original. Según la cobertura, Anthropic rechazó comentar detalles específicos sobre funciones internas y señaló que prueba prototipos que no siempre llegan a producción. Para seguimiento oficial, la referencia primaria sobre el producto y sus políticas debe contrastarse con documentación de Anthropic y, cuando aplique, con páginas de privacidad y data usage publicadas por la compañía.
Enlaces de alta autoridad para contexto adicional: Anthropic (sitio oficial) y Amazon Bedrock (documentación oficial de AWS).
En síntesis, la Filtración del código de Claude Code no demuestra por sí sola un comportamiento malicioso, pero sí expone un diseño de agente con amplias capacidades locales, telemetría y mecanismos de gestión remota que, sin aislamiento de red y políticas estrictas, amplían de forma material la superficie de privacidad y seguridad en estaciones de trabajo y entornos de desarrollo.
