Blog

Kimi Code Never Ask: Modi und gefährliche Befehle

Markdown

Im Modus Never Ask führt Kimi Code rm -rf und shutdown ohne Nachfrage aus. Worin unterscheiden sich die 3 Modi, und wie kannst du einen gefährlichen Befehl in config.toml verbieten?

Vollständigen Artikel lesen

In Kimi Code genehmigt der Modus Never Ask (/auto) alles automatisch: Er führt rm -rf, shutdown und reboot ohne eine einzige Nachfrage aus. Der Agent fragt nur in den 2 anderen Modi, Always Ask und Ask When Needed, bevor er diese Befehle ausführt.

Ich arbeite selbst in Claude Code mit aktiviertem „alles erlauben“; sonst würden wir dasitzen und klicken: Ja, ja, ja. Aber jedes 10. Mal macht der Agent die Dinge auf seine eigene Weise. Zum Glück gab es ein 3 Tage zuvor erstelltes Backup.

Auch ein privater Prototyp kann wertvolle Dateien und Zugangsdaten offenlegen. Nutze eine isolierte Kopie oder einen Container mit begrenzten Rechten und geprüftem Backup. Gib dem Agenten bei Kundensystemen zusätzlich eine eigene Datenbankidentität mit ausschließlich benötigten Rechten. Dann kann er die Datenbank selbst dann nicht löschen, wenn er es wirklich will.

Sehen wir uns an, was die einzelnen Modi von Kimi Code tun, wo der Schutz funktioniert und wie man ein Verbot festlegt. Los geht's.

Informationen zur Nutzung des Dienstes findest du in der Ailoot-Dokumentation.

Das Wichtigste

Kimi Code hat 3 Modi. Always Ask ist die Standardeinstellung: Das Lesen erfolgt automatisch, und alles andere bestätigst du einzeln für jede Aktion. Ask When Needed (/yolo) genehmigt gewöhnliche Änderungen selbst, fragt aber nach, bevor auf Dateien mit Schlüsseln zugegriffen, gefährliche Befehle ausgeführt oder der Planmodus verlassen wird. Never Ask (/auto) fragt nichts, und der Schutz vor gefährlichen Befehlen funktioniert in diesem Modus nicht. Ein dauerhaftes Verbot legst du mit einer deny-Regel in ~/.kimi-code/config.toml fest. Never Ask sollte besser nicht aktiviert werden, wenn eine Live-Datenbank im Spiel ist.

Worin unterscheiden sich die 3 Modi von Kimi Code?

Wenn du Kimi Code bereits installiert hast, hast du das Bestätigungsfenster gesehen: Der Agent möchte eine Datei bearbeiten oder einen Befehl ausführen und wartet auf dein „Ja“. Früher hießen die Modi Manual, YOLO und Auto. Deshalb werden dafür noch immer die alten Befehle /yolo und /auto verwendet.

Always Ask. Die Standardeinstellung. Der Agent liest Dateien, ohne nachzufragen, aber du bestätigst jede Änderung und jeden Befehl einzeln. Das ist der langsamste Modus.

Ask When Needed. Wird mit /yolo aktiviert. Der Modus genehmigt gewöhnliche Änderungen und Befehle selbst, fragt aber nach, bevor auf .env (die Datei mit den Passwörtern und Schlüsseln des Projekts) und SSH-Schlüssel des Servers zugegriffen wird, bevor gefährliche Befehle wie shutdown (den Computer herunterfahren) und rm -rf (einen ganzen Ordner löschen und dabei den Papierkorb umgehen) ausgeführt werden und bevor der Planmodus verlassen wird. Der Agent kann dir auch selbst eine Frage stellen.

Never Ask. Wird mit /auto aktiviert. Alle Aktionen werden automatisch genehmigt, auch der Zugriff auf sensible Dateien und das Verlassen des Planmodus. Der Agent stellt dir keine Fragen und entscheidet alles selbst.

Tabelle der drei Berechtigungsmodi von Kimi Code: Always Ask, Ask When Needed, Never Ask
3 Berechtigungsmodi in Kimi Code CLI.

Der Planmodus wird separat mit Shift-Tab oder /plan aktiviert: Der Agent schreibt zunächst einen Plan und wartet auf deine Zustimmung, bevor er die Dateien anfasst.

Wann ich selbst ohne Bestätigungen arbeite

In Claude Code ist „alles erlauben“ meine Standardeinstellung und in jedem neuen Chat aktiviert. Ohne diese Einstellung ist Vibe Coding zu langsam. Ein Vibe Coder versteht ohnehin schon wenig und muss dann ständig Tasten drücken: Ja, ja, ja, nein, nein, nein.

In diesem Modus kann der Agent aber absolut alles Rücksichtslose tun, auch eine Datenbank löschen. Dann sagt er zwar „sorry, entschuldige bitte“, aber manchmal lässt sich das, was er getan hat, nicht mehr beheben. Dieser Modus ist also etwas für Furchtlose, und du trägst dafür die Verantwortung.

Meine Regeln sind folgende. Nutze bei privaten Projekten, Experimenten und Prototypen einen Modus ohne Bestätigungen nur in einer isolierten Kopie oder einem Container ohne wertvolle Dateien und Produktionszugangsdaten, mit begrenzten Rechten und Backup. Fehlende Kunden schützen weder Privatdateien noch Schlüssel; auch die Isolation muss geprüft werden. Wenn du diesen Modus aber in demselben Projekt aktivierst, das Zugriff auf einen Produktionsserver hat, genügt 1 Prompt, damit der Agent dort über Nacht die Datenbank löscht und Änderungen auf der Live-Site bereitstellt.

Warum ein Verbot in Worten dich nicht schützt

Viele schreiben „rühr die Datenbank nicht an“ in die Anweisungen des Agenten. Verlass dich nicht darauf, dass dich das schützt. Du sagst ihm: Kumpel, geh da nicht rein. Aber er geht trotzdem hinein und nimmt sich, was er braucht, wann immer er es braucht. Besonders der chinesische Kimi: Er wird jedes Verbot missachten, das du festlegst. Amerikanische Modelle sind viel besser darauf trainiert, das nicht zu tun.

Ich verwende Kimi weiterhin bei meiner Arbeit. Kimi K3 ist sehr aufmerksam; ich nutze es, um Projekte auf durchgesickerte Schlüssel zu prüfen und Informationen zu sammeln. Einmal hatte ich innerhalb von ein paar Tagen alle seine Limits aufgebraucht. Kimi stellt sich nicht quer und macht alles, worum man es bittet. Deshalb braucht man beim Arbeiten damit Isolation. Wie ich es bei meinen eigenen Aufgaben getestet habe, beschreibe ich hier.

Du brauchst 2 Formen der Isolation:

  1. Eine Befehls-Blockliste in den Einstellungen. Sie sperrt passende Toolaufrufe. Ein Muster für eine Befehlsschreibweise bildet keine vollständige Grenze gegen andere Tools oder gleichwertige Aktionen. Kombiniere es mit Betriebssystem-, Container- und Datenbankrechten.
  2. Lesezugriff auf die Datenbank. Auf der Live-Datenbank hat der Agent einen separaten Benutzer mit Leseberechtigung. Dann kann er die Datenbank selbst im Modus Never Ask nicht löschen.

Wo der Schutz vor gefährlichen Befehlen funktioniert

Der integrierte Schutz von Kimi Code vor gefährlichen Befehlen ist standardmäßig aktiviert. In den Modi Always Ask und Ask When Needed fragt er vor shutdown, reboot (Neustart) oder rm -rf nach einer Bestätigung. In Never Ask werden diese Befehle ohne Unterbrechung ausgeführt.

Es gibt 2 Ausnahmen:

  • rm -rf wird ohne Nachfrage ausgeführt, wenn damit nur der Inhalt der temporären Ordner /tmp oder /temp gelöscht wird (seit Version 0.43.0);
  • in Ask When Needed fragt Kimi Code nicht nach Terminalbefehlen, die es nicht im Voraus analysieren kann (seit Version 2.0.1).

In Version 0.40.0 blockierte der Auto-Modus gefährliche Befehle; diese Blockierung wurde in Version 0.41.0 entfernt.

Vorher/nachher: Der autonome Modus von Kimi Code blockierte früher gefährliche Befehle, tut es jetzt aber nicht mehr
0.40.0: Auto blockierte gefährliche Befehle. 0.41.0: Die Blockierung wurde entfernt.

Du kannst den Schutz mit dangerous_command_guard = false im Abschnitt [permission] der Einstellungsdatei ~/.kimi-code/config.toml oder mit der Variable KIMI_CODE_DANGEROUS_COMMAND_GUARD=false deaktivieren. Die Entwickler empfehlen, dies nur dort zu tun, wo gefährliche Befehle bereits extern abgefangen werden.

So legst du in Kimi Code ein dauerhaftes Verbot fest

Wenn der Agent etwas ändern möchte, zeigt Kimi Code ein Bestätigungsfenster an:

  • Genehmigen: Mit den Pfeiltasten und Enter oder direkt mit 1, 2 oder 3;
  • Ablehnen: Esc, Ctrl-C oder Ctrl-D;
  • Für diese Sitzung genehmigen: Ein Aufruf derselben Art wird bis zum Ende der Sitzung genehmigt;
  • Dauerhafte Regeln: Eine dauerhafte Zulassungs- oder Verbotsregel in der Einstellungsdatei.

Dauerhafte Regeln werden in der Einstellungsdatei ~/.kimi-code/config.toml in Blöcken [[permission.rules]] festgelegt. Kimi Code prüft sie der Reihe nach; die erste passende Regel gilt. Setze Verbote daher oberhalb von Zulassungen. Jede Regel hat eine decision: allow (sofort zulassen), deny (sofort ablehnen) oder ask (jedes Mal nachfragen).

Ein Verbot für rm -rf und eine Nachfrage vor allen anderen Terminalbefehlen:

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

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

Bei Terminalbefehlen steht das Muster in Klammern: Bash(command-pattern); beim Lesen von Dateien: Read(path-pattern). MCP-Tools, AgentSwarm und eigene Tools können nur über ihren vollständigen Namen verboten werden.

Wenn du technisch nicht versiert bist und die Einstellungsdatei nicht öffnen möchtest, füge dem Agenten einfach den folgenden Prompt ein: Er findet selbst heraus, was eingeschränkt werden muss. Lass ihn nur zuerst sagen, wie sehr dich das verlangsamen wird. Wenn du es gewohnt bist, ohne Bestätigungen zu arbeiten, funktionieren nach dem Hinzufügen der Verbote manche Dinge nicht mehr. Hier ist mein Prompt:

Analysiere mein Projekt und sag mir, ob du Zugriff auf den Produktionsserver, die Staging-Datenbank und Produktionsschlüssel hast. Wenn ja, richte einen Schutz vor gefährlichen Befehlen ein: Verbiete das Löschen ganzer Ordner, Befehle, die den Änderungsverlauf unwiderruflich umschreiben, und direkte Befehle an die Produktionsdatenbank. Zeig zuerst einen Plan im Format „vorher – nachher“ und sag ehrlich, wie sehr mich das verlangsamen wird.

Wie du dasselbe in Claude Code einstellst, habe ich in einem separaten Artikel beschrieben. Sieh dir auch an, wie der Auto-Modus in Claude Code die Aktionen des Agenten prüft.

Welchen Modus solltest du wählen?

  • Du möchtest jeden Schritt des Agenten sehen: Always Ask, die Standardeinstellung. Du bestätigst alles außer dem Lesen.
  • Ein persönliches Projekt oder ein Prototyp ohne echte Kunden: Beginne mit Always Ask oder Ask When Needed. Ziehe Never Ask nur für eine isolierte entbehrliche Kopie mit eingeschränkten Rechten ohne wertvolle Daten und Schlüssel in Betracht. Fehlende Kunden machen den Modus nicht sicher.
  • Ein Projekt mit echten Kunden und Serverzugriff: Aktiviere Never Ask nicht. Lege deny-Verbote in config.toml fest und gib dem Agenten Lesezugriff auf die Datenbank.

Und sichere die Datenbank auf einem Rechner, der vom Projekt getrennt ist. Die übrigen Sicherheitsregeln findest du in einem separaten Artikel.

Stimme den Bestätigungsmodus auf die Zugriffsberechtigungen deines Projekts ab und prüfe, wo Verbote nötig sind.

Quellen

  • Kimi Code: Interaction and input — 3 Berechtigungsmodi, /yolo, /auto, Schutz vor gefährlichen Befehlen in den einzelnen Modi, das Bestätigungsfenster und der Planmodus.
  • Kimi Code: Configuration files — [[permission.rules]], die Reihenfolge, in der Regeln geprüft werden, dangerous_command_guard, KIMI_CODE_DANGEROUS_COMMAND_GUARD und der Pfad zu config.toml.
  • Kimi Code: Changelog — Versionen 0.40.0, 0.41.0, 0.43.0 und 2.0.1: Schutz vor gefährlichen Befehlen und die Umbenennung der Modi.

Lerne Ailoot kennen.

Weitere Details

Fragen und Antworten

Ist Never Ask sicher, weil mein Projekt keine Kunden hat?

Nein. Der Agent kann weiterhin private Dateien beschädigen oder Schlüssel offenlegen. Verwende eingeschränkte Rechte, eine isolierte entbehrliche Kopie oder einen Container und ein Backup, bevor du einen Modus ohne Bestätigungen erwägst.

Ersetzt eine deny-Regel für rm -rf die Isolation?

Nein. Sie blockiert passende Toolaufrufe, nicht jeden gleichwertigen Weg zur Dateiänderung. Halte wertvolle Daten und Produktionszugangsdaten außerhalb der Agentenreichweite. Verwende eine eigene Datenbankidentität mit nur den für die Aufgabe nötigen Rechten.

Alle Artikel