The Pulse

Secondo un rapporto, ZCode carica cronologie Git complete senza avvisare

Un rapporto di reverse engineering afferma che ZCode impacchetta interi workspace, comprese le cronologie Git e le cache LFS, e carica snapshot cifrati su Aliyun OSS. Una segnalazione pubblica nel repository di feedback di ZCode descrive un

AI.info Team · Scritto con l’IA · verificato · 2026-09-18

Un rapporto di reverse engineering pubblicato il 18 settembre afferma che ZCode, l’agente di coding desktop di Zhipu, impacchetta e carica molti più dati dei file che uno sviluppatore invia attivamente a una sessione di IA. L’indagine descrive snapshot cifrati contenenti metadati Git completi, cache Git LFS, reflog e alcuni file di configurazione globali di ZCode, inviati direttamente ad Aliyun Object Storage mentre l’utente rimane connesso.

Il rapporto proviene da un’indagine tecnica di ferstar, che ricostruisce il comportamento attraverso file locali, log dell’applicazione e codice JavaScript incluso nel pacchetto del client. Documenta un singolo test dettagliato su macOS, senza stabilire quanti utenti o workspace siano stati interessati. Una distinta segnalazione pubblica nel repository ufficiale di feedback di ZCode, aperta lo stesso giorno, descrive evidenze simili rilevate su sistemi macOS e Linux.

Uno snapshot da 313 MB in attesa di caricamento

L’indagine è iniziata quando l’autore ha scoperto che la directory dei dati locali di ZCode aveva superato i 700 MB. Nella directory v2/checkpoints dell’applicazione si trovavano un archivio cifrato da 313.070.842 byte e un file di stato che identificava uno snapshot del workspace da 345.549.173 byte. Il workspace apparteneva a quello che l’autore descrive come un progetto commerciale e l’archivio era contrassegnato come snapshot completo «baseline».

Il file di stato locale registrava 564 tentativi di caricamento falliti. Secondo il rapporto, ZCode aveva esaminato il workspace, escluso directory come node_modules, compresso i dati rimanenti e lasciato l’archivio in una directory di attesa per un nuovo tentativo. L’autore afferma che il repository originale era di circa 10 GB, mentre il materiale selezionato per lo snapshot era di 345 MB ed era costituito in gran parte da risorse del progetto.

La segnalazione pubblica descrive un meccanismo simile. Secondo il suo autore, su ZCode Desktop versione 3.12.3 per macOS e versione 3.10.0 su un sistema Linux remoto, i file di stato locali contenevano valori lastAcceptedManifestHash insieme a manifest che elencavano un gran numero di percorsi .git. La segnalazione è ancora aperta e non risulta assegnata a nessuno.

Il percorso di caricamento passa per Aliyun OSS

Secondo l’indagine principale, ZCode richiede prima le credenziali di caricamento a zcode.z.ai attraverso /api/v1/snapshot/upload-credential. La risposta fornisce un identificativo dello snapshot, una chiave pubblica RSA, limiti di dimensione, credenziali per il modulo e un callback. ZCode crea quindi localmente un archivio tar.gz, lo cifra con AES-256-CTR e carica il file risultante direttamente su Aliyun OSS, anziché inviare l’archivio attraverso il server principale dell’applicazione ZCode.

Dopo aver accettato l’oggetto, il servizio OSS effettua una chiamata di ritorno al backend di Zhipu, secondo il rapporto. L’autore descrive anche connessioni persistenti dal client in esecuzione agli endpoint di ZCode e ai nodi di archiviazione di Aliyun durante i test. Questi riscontri mostrano l’esistenza di un processo di caricamento sul cloud, ma non stabiliscono di per sé per quanto tempo siano conservati i dati, quali membri del personale possano accedervi o se ogni snapshot accettato venga successivamente indicizzato.

Il sistema di cifratura solleva un’ulteriore preoccupazione. Il client genera una chiave simmetrica temporanea per l’archivio e la cifra con una chiave pubblica RSA fornita dal server. La chiave privata corrispondente non è stata trovata sulla macchina usata per il test. Il rapporto conclude quindi che il client locale e l’utente non possono decifrare l’archivio conservato senza la chiave custodita nel cloud.

I metadati Git costituiscono la maggior parte dell’archivio esaminato

Il manifest salvato localmente elencava 42.411 file. Nella ripartizione pubblicata dall’autore dell’indagine, .git/lfs rappresentava 196,1 MB, pari al 56,8% dello snapshot; .git/objects rappresentava 102,2 MB, pari al 29,6%; e .git/logs aggiungeva 0,6 MB. Il codice sorgente e la documentazione costituivano circa 46,2 MB, pari al 13,4%.

In base a queste cifre, i dati Git rappresentavano l’86,6% del contenuto caricato. Tra questi figurano l’archivio degli oggetti contenente commit storici, alberi e blob, oltre ai file LFS e ai record dei reflog. Il rapporto avverte che tale materiale può conservare credenziali eliminate, vecchi file di configurazione, nomi di branch non ancora inviati al repository remoto, percorsi interni del repository e altre informazioni assenti dall’attuale albero di lavoro.

L’autore dell’indagine ha trovato anche un manifest separato chiamato repo_snapshot_extra_manifest. Questo calcola gli hash dei file di configurazione globali di ZCode, come settings.behavior.json, e li associa agli snapshot di diversi workspace. Analogamente, la segnalazione pubblica sostiene che potrebbero essere inclusi dati di configurazione di MCP, hook, skill e agenti a livello di utente, sebbene queste affermazioni più ampie derivino dall’ispezione locale dell’autore della segnalazione, anziché da una specifica pubblicata di ZCode.

Le impostazioni visibili non fermano l’acquisizione descritta

Il rapporto confronta due impostazioni con il comportamento rilevato nel client. Secondo l’indagine, optimizeAgentExperienceEnabled controlla se i dati raccolti possano essere usati per l’addestramento dei modelli, mentre repoSnapshotIndexingEnabled controlla l’indicizzazione lato server. Nessuna delle due impostazioni ha fermato la creazione del pacchetto locale e il caricamento nella build esaminata.

Esaminando il codice assembly dell’host dell’applicazione, l’autore afferma che il componente di acquisizione e caricamento viene creato incondizionatamente all’avvio. Secondo il rapporto, il requisito per il funzionamento del processo è un token di accesso valido. Gli eventi di acquisizione si verificano prima dei prompt e quando le attività terminano con un tag repo-wiki-update; il log di una sessione conteneva ben 62 eventi di acquisizione.

La segnalazione pubblica riferisce la stessa apparente discrepanza: repoSnapshotIndexingEnabled era impostato su false, eppure la macchina aveva comunque prodotto un indicatore di snapshot accettato. Il suo autore chiede a ZCode di rendere l’acquisizione completa dei repository soggetta a consenso esplicito, dichiarare se siano inclusi i metadati Git e la configurazione globale, fornire una disattivazione con un clic e spiegare come gli utenti possano eliminare i dati caricati in precedenza.

Non è stata trovata una spiegazione pubblica dell’azienda

La documentazione pubblica di feedback di ZCode indirizza gli utenti alle segnalazioni su GitHub, a Discord e all’assistenza nell’app, mentre la pagina delle versioni dell’azienda indica che la versione 3.12.3 è stata rilasciata il 17 settembre. Né la segnalazione pubblica né le note di rilascio esaminate per questo rapporto contengono una risposta di ZCode che spieghi il comportamento degli snapshot o la sua politica di conservazione.

Secondo l’indagine principale, l’informativa sulla privacy di ZCode fa riferimento alla raccolta di «testo, file e codice inviati durante le conversazioni», ma non descrive esplicitamente la creazione silenziosa di pacchetti contenenti workspace completi o cronologie Git. Questa distinzione è centrale nella controversia: inviare file che un utente allega deliberatamente è diverso dal creare ripetutamente in background snapshot dello stato storico di un repository.

La soluzione immediata proposta dal rapporto interviene a livello di sistema operativo, anziché tramite un controllo nell’app. Il rapporto raccomanda di eliminare la directory locale dei checkpoint, ricrearla e contrassegnarla come immutabile con chflags uchg su macOS o chattr +i su Linux. Questo blocca la fase di scrittura locale, ma disabilita anche le funzioni di ripristino dei checkpoint e di timeline di ZCode. Le evidenze pubbliche attualmente disponibili attestano un caso di test documentato e diverse segnalazioni di utenti, ma non il numero totale di account interessati, la sorte finale degli archivi caricati o se Z.ai abbia corretto il comportamento.