Kimi Code Non chiedere mai: modalità e comandi pericolosi

In Kimi Code, la modalità Non chiedere mai (/auto) approva tutto automaticamente: eseguirà rm -rf, shutdown e reboot senza fare una sola domanda. L'agente chiede conferma prima di questi comandi solo nelle altre 2 modalità, Chiedi sempre e Chiedi quando necessario.

Io lavoro personalmente in Claude Code con l'opzione «consenti tutto» attivata; altrimenti passeremmo il tempo a cliccare: sì, sì, sì. Ma ogni 10 volte l'agente fa di testa sua.

Anche un prototipo personale può esporre file e credenziali importanti. Usa una copia o un container isolato con permessi limitati e backup verificato; per sistemi con clienti, assegna anche un’identità database separata con il solo accesso necessario. Così, anche se volesse davvero cancellare il database, non potrebbe.

Vediamo cosa fa ciascuna modalità di Kimi Code, dove funziona la protezione e come impostare un divieto. Andiamo.

Per informazioni sull'uso del servizio, consulta la documentazione di Ailoot.

Quali sono le differenze tra le 3 modalità di Kimi Code?#

Se hai già installato Kimi Code, hai visto il pannello di approvazione: l'agente vuole modificare un file o eseguire un comando e aspetta il tuo «sì». Le modalità si chiamavano Manual, YOLO e Auto, perciò usano ancora i vecchi comandi: /yolo e /auto.

Chiedi sempre. È l'impostazione predefinita. L'agente legge i file senza chiedere, ma confermi separatamente ogni modifica e ogni comando. È la modalità più lenta.

Chiedi quando necessario. Si attiva con /yolo. Approva da sola le modifiche e i comandi ordinari, ma chiede prima di accedere a .env (il file che contiene le password e le chiavi del progetto) e alle chiavi SSH del server, prima di comandi pericolosi come shutdown (spegnere il computer) e rm -rf (eliminare un'intera cartella, aggirando il cestino) e prima di uscire dalla modalità di pianificazione. L'agente può anche farti una domanda.

Non chiedere mai. Si attiva con /auto. Tutte le approvazioni avvengono automaticamente, anche quelle per i file sensibili e per uscire dalla modalità di pianificazione. L'agente non ti fa domande e decide tutto da solo.

La modalità di pianificazione si attiva separatamente, con Shift-Tab o /plan: prima l'agente scrive un piano e aspetta la tua approvazione, poi tocca i file.

Quando lavoro senza conferme#

In Claude Code, «consenti tutto» è la mia impostazione predefinita, attivata in ogni nuova chat. Senza, il vibe coding è troppo lento. Chi fa vibe coding capisce già molto poco, e in più deve continuare a premere pulsanti: sì, sì, sì, no, no, no.

Ma in questa modalità l'agente può fare qualsiasi cosa sconsiderata, incluso cancellare un database. Poi dirà «scusa, ti chiedo scusa», ma a volte non si può più rimediare a ciò che ha fatto. Questa modalità è quindi per chi non ha paura, e la responsabilità è tua.

Le mie regole sono queste. Per progetti personali, esperimenti e prototipi, considera l’assenza di conferme solo in una copia o un container isolato senza file importanti o credenziali di produzione, con permessi limitati e backup. Non avere clienti non protegge file e chiavi personali, e anche l’isolamento va verificato. Ma se attivi questa modalità nello stesso progetto che ha accesso a un server di produzione, basta 1 prompt perché durante la notte l'agente cancelli il database e distribuisca modifiche sul sito in produzione.

Perché un divieto scritto a parole non ti protegge#

Molte persone scrivono «non toccare il database» nelle istruzioni dell'agente. Non contare sul fatto che questo ti salvi. Gli dici: amico, non entrare qui. Ma ci entrerà comunque e prenderà ciò che gli serve quando gli serve. Soprattutto il Kimi cinese: violerà qualunque divieto tu imposti. I modelli americani sono addestrati molto meglio a non farlo.

Continuo a usare Kimi nel mio lavoro. Kimi K3 è molto attento; lo uso per controllare i progetti alla ricerca di chiavi esposte e raccogliere informazioni. Una volta ho esaurito tutti i suoi limiti in un paio di giorni. Kimi non fa i capricci e fa tutto quello che chiedi. Per questo serve l'isolamento quando ci lavori. Ho descritto qui come l'ho messo alla prova con le mie attività.

Servono 2 forme di isolamento:

1. Una lista di blocco dei comandi nelle impostazioni. Blocca le chiamate corrispondenti; uno schema per una scrittura del comando non delimita ogni altro strumento o azione equivalente. Affiancala ai permessi del sistema operativo, del container e del database.
2. Accesso al database in sola lettura. Nel database attivo, l'agente ha un utente separato con permessi di sola lettura. Così, anche in modalità Non chiedere mai, non può cancellare il database.

Dove funziona la protezione dai comandi pericolosi#

La protezione integrata di Kimi Code dai comandi pericolosi è attiva per impostazione predefinita. Nelle modalità Chiedi sempre e Chiedi quando necessario chiede conferma prima di shutdown, reboot (riavvio) o rm -rf. In modalità Non chiedere mai, questi comandi vengono eseguiti senza interruzioni.

Ci sono 2 eccezioni:

• rm -rf viene eseguito senza chiedere se elimina solo il contenuto delle cartelle temporanee /tmp o /temp (dalla versione 0.43.0);
• in modalità Chiedi quando necessario, Kimi Code non chiede conferma per i comandi del terminale che non riesce ad analizzare in anticipo (dalla versione 2.0.1).

Nella versione 0.40.0, la modalità Auto bloccava i comandi pericolosi; questo blocco è stato rimosso nella 0.41.0.

Puoi disattivare la protezione con dangerous_command_guard = false nella sezione [permission] del file delle impostazioni ~/.kimi-code/config.toml, oppure con la variabile KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. Gli sviluppatori consigliano di farlo solo nei contesti in cui i comandi pericolosi vengono già intercettati esternamente.

Come impostare un divieto permanente in Kimi Code#

Quando l'agente vuole cambiare qualcosa, Kimi Code mostra un pannello di approvazione:

• Approva: usa i tasti freccia e Enter, oppure premi direttamente 1, 2 o 3;
• Rifiuta: Esc, Ctrl-C o Ctrl-D;
• Approva per questa sessione: le chiamate dello stesso tipo vengono approvate fino alla fine della sessione;
• Regole permanenti: una regola permanente di autorizzazione o diniego nel file delle impostazioni.

Le regole permanenti si scrivono nel file delle impostazioni ~/.kimi-code/config.toml, all'interno di blocchi [[permission.rules]]. Kimi Code le controlla nell'ordine e ha effetto la prima corrispondenza, quindi metti i divieti prima delle autorizzazioni. Ogni regola ha un decision: allow (autorizza subito), deny (nega subito) oppure ask (chiede ogni volta).

Un divieto per rm -rf e una richiesta di conferma prima di qualsiasi altro comando del terminale:

[[permission.rules]]
decision = "deny"
pattern = "Bash(rm -rf*)"

[[permission.rules]]
decision = "ask"
pattern = "Bash"

Per i comandi del terminale, il pattern va tra parentesi: Bash(command-pattern); per leggere i file, Read(path-pattern). Gli strumenti MCP, AgentSwarm e i tuoi strumenti possono essere vietati solo specificandone i nomi completi.

Se non sei una persona tecnica e non vuoi aprire il file delle impostazioni, incolla semplicemente il prompt qui sotto nell'agente: troverà da solo cosa va limitato. Chiedigli solo di dirti prima quanto questo ti rallenterà. Se sei abituato a lavorare senza conferme, dopo aver aggiunto i divieti alcune cose smetteranno di funzionare. Ecco il mio prompt:

Analizza il mio progetto e dimmi se hai accesso al server di produzione, al database di staging e alle chiavi di produzione. Se ce l'hai, configura la protezione contro i comandi pericolosi: vieta l'eliminazione di intere cartelle, i comandi che riscrivono irreversibilmente la cronologia delle modifiche e i comandi diretti al database di produzione. Mostrami prima un piano nel formato «prima - dopo» e dimmi onestamente quanto mi rallenterà.

Ho spiegato come configurare la stessa cosa in Claude Code in un articolo separato. Dai anche un'occhiata a come la modalità Auto in Claude Code controlla le azioni dell'agente.

Quale modalità scegliere#

• Vuoi vedere ogni passaggio dell'agente: Chiedi sempre, la modalità predefinita. Confermi tutto tranne la lettura.
• Un progetto personale o un prototipo senza clienti reali: inizia con Chiedi sempre o Chiedi quando necessario. Considera Non chiedere mai soltanto per una copia isolata ed eliminabile con permessi ristretti e senza dati importanti o chiavi: non diventa sicura perché mancano clienti.
• Un progetto con clienti reali e accesso al server: non attivare Non chiedere mai. Imposta divieti deny in config.toml e concedi all'agente accesso al database in sola lettura.

E fai un backup del database su una macchina separata dal progetto. Le altre regole di sicurezza sono raccolte in un articolo separato.

Fai corrispondere la modalità di conferma ai permessi di accesso del progetto e verifica dove servono i divieti.

Scopri Ailoot.