Cosa sincronizza

KoNiMa Claude Sync organizza ciò che sincronizza in domini indipendenti. Ogni dominio è opt-in e si attiva in base alla tua edizione: lo stesso VSIX è installato ovunque, è la licenza a decidere cosa è disponibile. Tutto viaggia esclusivamente attraverso il tuo repository git.

I domini in breve

Dominio	Cosa viaggia
Configurazione	Regole, skill, comandi slash, agenti, `settings.json` e `CLAUDE.md` — opt-in per singolo dominio.
Plugin	L’inventario dei plugin installati: installi una volta, si propaga a ogni macchina.
Plugin personalizzati	I bundle di plugin che il tuo team scrive in proprio viaggiano attraverso il repository e si installano automaticamente su ogni macchina.
Server MCP	Le definizioni dei server MCP. Le credenziali vengono ripulite prima dell’export e non raggiungono mai il repository.
Memorie	Le memorie di Claude e le note di progetto, unite e deduplicate tra le macchine; i progetti sono riconosciuti dal remote git.
Hook	Gli hook personalizzati di Claude Code con le loro varianti per sistema operativo; un manifesto li ricollega su qualsiasi macchina.

Configurazione

Il cuore del prodotto. La configurazione di Claude Code che vive in ~/.claude — regole, skill, comandi, agenti, CLAUDE.md e settings.json — diventa una baseline coerente su tutte le tue macchine. Ogni categoria è opt-in: puoi sincronizzare le skill ma non i comandi, o viceversa.

Plugin

L’inventario dei plugin di Claude Code viaggia con te. Installi un plugin una sola volta e alla sincronizzazione successiva ogni altra macchina lo riceve. Allo stesso modo, rimuovere un plugin lo rimuove ovunque: è una decisione che vale per l’intero parco macchine, quindi richiede una conferma esplicita.

Plugin personalizzati

Da non confondere con il dominio Plugin: quello sincronizza l’inventario dei plugin installati da marketplace pubblici, mentre i plugin personalizzati sono bundle che il tuo team scrive in proprio, e a viaggiare nel repository sono i file del plugin stesso. Un maintainer li prepara in una cartella dedicata; alla sincronizzazione successiva ogni macchina li riceve, li installa e li abilita automaticamente, senza alcuna azione manuale. Se un plugin richiede una preparazione aggiuntiva, questa viene eseguita da sola; in caso di problema il plugin resta installato ma viene segnalato in dashboard, senza mai bloccare la sincronizzazione.

Per la guida completa vedi Plugin personalizzati.

Server MCP

Le definizioni dei server MCP si sincronizzano tra le macchine, ma con una cautela fondamentale: le credenziali non lasciano mai la tua macchina. Prima dell’export, i valori delle chiavi che corrispondono a token, secret, key, password, auth, bearer e credential vengono azzerati. Nel repository finisce la struttura del server, non i suoi segreti.

Memorie

Le memorie di Claude e le note di progetto vengono fuse e deduplicate tra le macchine: ogni macchina porta con sé ciò che le altre hanno imparato. I progetti sono identificati dal loro remote git, non dal percorso locale — così lo stesso progetto, clonato in cartelle diverse su macchine diverse, viene comunque riconosciuto e le sue memorie vengono rimappate sulla cartella locale corretta. Non fa differenza se il remote è scritto come https://…, git@host:… o ssh://…: lo stesso repository viene riconosciuto come un solo progetto, non tre. Anche i progetti clonati via SSH ora sincronizzano le loro memorie — prima venivano esclusi senza dire nulla. Il dominio Memorie richiede un’edizione che lo includa.

Le memorie di progetto si sincronizzano allo stesso modo su Windows, macOS e Linux — serve solo un Node.js di sistema recente (23.4 o più nuovo), che il controllo di sistema verifica per te. Se prima eri su macOS o Linux, le tue memorie di progetto iniziano a comparire al primo allineamento, senza nulla da riconfigurare.

Su alcuni servizi git il prodotto è in grado di capire se un repository è stato archiviato; su altri non può, e lo dice chiaramente invece di dare per scontato che il repository sia ancora attivo. Te ne accorgi quando unisci progetti, dove l’operazione si ferma per spiegare cosa non è riuscita a verificare.

L’ambito delle memorie di progetto

Non tutti i progetti sulla tua macchina hanno le memorie esportate: vengono raccolte entro un ambito deciso in base a dove è ospitato il tuo repository di sincronizzazione.

Su un host condiviso — GitHub, GitLab, Bitbucket, Codeberg, Gitea.com, SourceHut o Azure DevOps — l’ambito predefinito è la tua organizzazione: i repository sotto lo stesso proprietario del tuo repository di sincronizzazione. I tuoi repository personali sullo stesso host restano fuori dall’ambito, così le loro memorie non vengono mai esportate nel repository condiviso. Su Azure DevOps questo vale per entrambe le forme di indirizzo — dev.azure.com/<organizzazione>/… e la vecchia <organizzazione>.visualstudio.com/….
Sul server git della tua azienda (un host self-hosted), l’intero host è la tua azienda, quindi l’ambito è l’intero host — il comportamento resta invariato.

I progetti fuori dall’ambito non sono nascosti. Sono elencati nella scheda Progetti come fuori dall’ambito aziendale, ciascuno con il motivo, e un interruttore per progetto ti permette di includerne uno deliberatamente se vuoi davvero che le sue memorie viaggino.

Hook

Gli hook personalizzati di Claude Code viaggiano con le loro varianti per sistema operativo: un unico manifesto sa quale variante eseguibile usare su Windows, macOS o Linux. Se un hook non ha una variante valida per la macchina corrente, l’app lo segnala invece di eseguirlo a vuoto.

Tenere dei file fuori da una cartella — `.knmsyncignore`

Alcuni file semplicemente non devono viaggiare: indici generati dalla macchina, output di build, cache — tutto ciò che viene ricostruito in locale e tra le macchine creerebbe solo rumore. Per dichiararli, metti un file .knmsyncignore nella radice di qualsiasi cartella sincronizzata. Usa la stessa sintassi familiare di un .gitignore e viaggia con la cartella — così l’intero team condivide un’unica dichiarazione, invece di configurare le esclusioni uno per uno.

Una riga per pattern; # inizia un commento.
nome esclude un file o una cartella chiamata nome a qualsiasi profondità; cartella/ esclude un’intera directory; *.log esclude per estensione; uno / iniziale ancora alla radice della cartella; !pattern re-include qualcosa escluso da una regola più ampia.

Per esempio, se un hook genera un file indice dentro hooks/, aggiungi lì un .knmsyncignore che lo elenca e quel file resterà sulla macchina che lo produce. La cartella dei plugin personalizzati include già un .knmsyncignore pronto all’uso (vedi Plugin personalizzati), che sei libero di modificare. Puoi aprire e modificare il file direttamente dalla dashboard.

Progettato per essere sicuro

La sincronizzazione segue alcuni principi che evitano la perdita di lavoro:

Le tue modifiche vincono sempre. Un pull non sovrascrive mai ciecamente il lavoro locale: viene fatta una riconciliazione a tre vie contro una baseline per-macchina, e prima di applicare qualsiasi cosa viene salvato uno snapshot di backup locale.
Nessun force-push, mai. I conflitti vengono mostrati nella dashboard e non risolti in silenzio.
Idempotente. Ogni operazione è dichiarativa e ri-eseguibile senza danni.
Consapevole delle finestre multiple. Una sola finestra di VS Code guida la sincronizzazione; le altre seguono senza collisioni.
Tollerante all’offline. I push falliti vengono accodati e ritentati; la licenza funziona offline fino a sette giorni dall’ultima validazione riuscita.

Cosa non viaggia mai

I tuoi dati non transitano dai server KoNiMa. L’unico endpoint contattato è l’API di licenza, e solo per la validazione (e, in fase di richiesta prova, un hash anonimo e monodirezionale della macchina per prevenire abusi). Le credenziali del repository e la chiave di licenza restano nel secret store di VS Code, mai scritte su disco.

Restano fuori dalla sincronizzazione anche due elementi legati alla singola macchina:

Il file ~/.claude.json resta nella tua cartella home: Claude Code non lo sposta mai (nemmeno con una cartella di configurazione personalizzata) e Claude Sync non lo sincronizza.
La scelta della cartella di Claude — l’impostazione legata alla macchina — non viaggia mai da una macchina all’altra.
L’area di lavoro .knm-sync dentro la cartella di Claude — dove Claude Sync tiene le proprie baseline, i backup di sicurezza e i lock — è strettamente locale a ogni macchina e non viene mai sincronizzata.