ZCode, la herramienta de programación con IA de Zhipu, fue denunciada por un desarrollador el 18 de septiembre por empaquetar y subir en segundo plano todo el espacio de trabajo del usuario, incluido el historial completo de Git, la caché de archivos grandes de LFS y la configuración local del equipo. Esa misma noche, ZCode publicó una disculpa en la que reconoció que las subidas ocurrieron, atribuyó el problema a una función de "indexación del repositorio" y afirmó que ya estaba corregido.
Lo que descubrieron los desarrolladores
El primero en exponer los detalles fue el bloguero de tecnología Ferstar. En su blog desmontó el mecanismo de snapshots locales de ZCode: tras iniciar sesión, un proceso en segundo plano que arranca junto con el programa empaqueta todo el espacio de trabajo, cifra el contenido de los archivos con AES-256-CTR y luego envuelve la clave con una clave pública RSA emitida por el servidor, para finalmente enviarlo directamente a Alibaba Cloud OSS mediante una subida por formulario. La clave privada para descifrar solo existe en la nube: el propio usuario no puede abrir sus archivos .enc.
La muestra que presentó es concreta: el espacio de trabajo sin comprimir pesaba 345MB, y tras cifrarse quedó en 313MB, con 42411 archivos en el listado. La mayor parte corresponde al directorio .git, que suma un 86,6% del total, con 196,1MB de caché de LFS y 102,2MB de objetos de Git; el código fuente y la configuración apenas suman unos 46MB. Hay dos momentos de activación: uno antes de cada envío de un prompt, y otro al finalizar una tarea, cuando se actualiza el Repo Wiki; en una sola sesión se llegaron a registrar hasta 62 snapshots.
Ese mismo día, un desarrollador abrió un issue en el repositorio público de feedback de Zhipu, con un título que encadena tres preguntas de "por qué": por qué se sube en silencio todo el historial de Git, por qué se cifra de forma que ni el propio usuario puede abrirlo, y por qué ni siquiera existe un interruptor para desactivarlo. El issue menciona además que, tras fallos en la subida local, el sistema reintentaba repetidamente, con hasta 564 intentos registrados. Otro desarrollador reprodujo el comportamiento en su propia máquina: un snapshot de proyecto de 748MiB, con un 98,91% ocupado por .git, en la versión ZCode 3.12.3.
El interruptor que no funciona es el punto más polémico de todo este episodio. Según Ferstar, los interruptores de "optimizar experiencia" e "indexación de snapshots del repositorio" en la interfaz solo controlan si el servidor usará los datos para entrenar modelos; el empaquetado y la subida locales siguen ocurriendo igualmente. En el historial de Git pueden quedar claves eliminadas hace tiempo, configuraciones antiguas abandonadas, registros de ramas que nunca se hicieron push y dominios de red interna, cosas que ya no aparecen en el código actual pero que siguen intactas dentro de .git.
Lo que dice Zhipu
La disculpa de ZCode atribuye las subidas a la función de "indexación del repositorio": al generar la página del Repo Wiki puede activarse una subida de datos del repositorio, que se destruyen en la nube inmediatamente después de generar el Wiki, sin guardarse. La función venía activada por defecto al lanzarse, lo que afectó a algunos usuarios, y ya ha sido corregida.
Las medidas correctivas anunciadas son tres: abrir próximamente el código del repositorio de ZCode, invitando a una evaluación externa y haciendo público el avance de la revisión; y, ese mismo día, otorgar a todos los usuarios un reinicio extra de la cuota semanal. Varios puntos que la nota no aclara siguen sin poder verificarse: cuántos usuarios y repositorios se vieron afectados, cuánto tiempo permanecieron realmente los datos en OSS, si la "destrucción" fue auditada de forma independiente, y qué número de versión corresponde tras la corrección. El calendario de apertura del código también quedó solo como "próximamente".
Ese mismo día, Zhipu también presentó un nuevo modelo, GLM-5.3-FlashX, destacando una velocidad de salida de 200 tokens por segundo. Un desarrollador comentó en su blog, uniendo ambos hechos con ironía, que mientras toda la red pregunta adónde fue a parar el código, Zhipu está ocupada lanzando un modelo nuevo.
Qué pueden hacer ahora los desarrolladores en China
Buena parte de los usuarios de ZCode prueban la herramienta en proyectos de empresa, y el historial de Git suele ser más sensible para una compañía que el propio código actual. Para quienes todavía tienen instaladas versiones antiguas, se recomiendan tres pasos: primero, actualizar a la versión corregida; después, comprobar si la carpeta local ~/.zcode/v2/checkpoints todavía guarda snapshots pendientes de subir; y por último, rotar todas las claves y tokens que hayan aparecido en el historial, sin dar por hecho que la supuesta "destrucción" cubra lo que ya se llegó a subir.
Ferstar propone un método aún más drástico: en macOS, usar chflags uchg; en Linux, chattr +i, para bloquear la carpeta de snapshots como de solo lectura e impedir la generación de snapshots ya desde el sistema de archivos. El costo es que las funciones de reversión de checkpoints y de línea de tiempo dejan de funcionar.
Los agentes de programación necesitan leer el repositorio para funcionar, y la indexación local en sí misma no tiene nada de extraño. La disputa está en los límites: leer localmente y subir a la nube son dos cosas distintas, igual que subir el código actual y subir todo el historial también lo son. Si la apertura de código que promete Zhipu llega a materializarse, al menos el público podrá comprobar por sí mismo qué rutas empaquetaba realmente el módulo de snapshots y dónde están conectados de verdad los interruptores.
Fuentes: análisis de ingeniería inversa del blog de tecnología Ferstar sobre el mecanismo de snapshots y la composición de los archivos, issue pública en zai-org/feedback, Ifeng Tech, CocoLoop, Elliot's Harness Lab; comunicado de disculpa de ZCode para verificar la atribución, el estado de la corrección y las medidas de compensación.