Kimi Code Never Ask: tryby i niebezpieczne polecenia

W Kimi Code tryb Never Ask (/auto) automatycznie zatwierdza wszystko: wykona rm -rf, shutdown i reboot bez zadania choćby jednego pytania. Agent pyta przed tymi poleceniami tylko w 2 pozostałych trybach: Always Ask i Ask When Needed.

Sam pracuję w Claude Code z włączoną opcją „zezwalaj na wszystko”; w przeciwnym razie siedzielibyśmy i klikali: tak, tak, tak. Ale za każdym 10. razem agent robi coś po swojemu.

Nawet osobisty prototyp może ujawnić cenne pliki i poświadczenia. Użyj izolowanej kopii lub kontenera z ograniczonymi uprawnieniami i sprawdzoną kopią zapasową; dla systemów klientów daj też agentowi oddzielną tożsamość bazy danych z dostępem wyłącznie potrzebnym do zadania. Wtedy agent nie może usunąć bazy, nawet jeśli naprawdę tego chce.

Sprawdźmy, co robi każdy tryb Kimi Code, gdzie działa ochrona i jak ustawić zakaz. Zaczynajmy.

Informacje o korzystaniu z usługi znajdziesz w dokumentacji Ailoot.

Czym różnią się 3 tryby Kimi Code?#

Jeśli masz już zainstalowane Kimi Code, widziałeś panel zatwierdzania: agent chce edytować plik lub uruchomić polecenie i czeka na twoje „tak”. Tryby dawniej nazywały się Manual, YOLO i Auto, dlatego nadal używają starych poleceń: /yolo i /auto.

Always Ask. Tryb domyślny. Agent czyta pliki bez pytania, ale każdą edycję i każde polecenie zatwierdzasz osobno. To najwolniejszy tryb.

Ask When Needed. Włączany poleceniem /yolo. Sam zatwierdza zwykłe edycje i polecenia, ale pyta przed dostępem do pliku .env (zawierającego hasła i klucze projektu) oraz kluczy SSH serwera, przed niebezpiecznymi poleceniami, takimi jak shutdown (wyłącza komputer) i rm -rf (usuwa cały folder z pominięciem kosza), a także przed opuszczeniem trybu planowania. Agent może też sam zadać ci pytanie.

Never Ask. Włączany poleceniem /auto. Wszystkie działania są automatycznie zatwierdzane, także dostęp do poufnych plików i opuszczenie trybu planowania. Agent nie zadaje pytań i o wszystkim decyduje samodzielnie.

Tryb planowania włącza się osobno, za pomocą Shift-Tab lub /plan: agent najpierw przygotowuje plan i czeka na twoją zgodę, a dopiero potem modyfikuje pliki.

Kiedy sam pracuję bez potwierdzeń#

W Claude Code domyślnie mam włączoną opcję „zezwalaj na wszystko” — włączam ją w każdym nowym czacie. Bez niej vibe coding jest zbyt powolny. Osoba programująca w ten sposób i tak niewiele rozumie, a do tego musi bez przerwy naciskać przyciski: tak, tak, tak, nie, nie, nie.

W tym trybie agent może jednak zrobić dosłownie wszystko, co lekkomyślne, włącznie z wyczyszczeniem bazy danych. Potem powie „przepraszam, bardzo mi przykro”, ale czasem tego, co zrobił, nie da się już naprawić. Ten tryb jest więc dla nieustraszonych, a odpowiedzialność spoczywa na tobie.

Moje zasady są takie: przy projektach osobistych, eksperymentach i prototypach używaj trybu bez potwierdzeń wyłącznie w izolowanej kopii lub kontenerze bez cennych plików i poświadczeń produkcyjnych, z ograniczonymi uprawnieniami i kopią zapasową. Brak klientów nie chroni prywatnych plików ani kluczy, a izolację nadal trzeba sprawdzić. Jeśli jednak włączysz ten tryb w projekcie, który ma dostęp do serwera produkcyjnego, wystarczy 1 prompt, by agent w nocy usunął tam bazę danych i wdrożył zmiany na działającej stronie.

Dlaczego zakaz zapisany słowami cię nie ochroni#

Wiele osób wpisuje w instrukcjach agenta „nie ruszaj bazy danych”. Nie licz na to, że cię to ochroni. Mówisz mu: stary, nie wchodź tam. Ale i tak wejdzie i weźmie to, czego potrzebuje. Zwłaszcza chiński Kimi — naruszy każdy ustawiony zakaz. Modele amerykańskie są znacznie lepiej wytrenowane, by tego nie robić.

Nadal korzystam z Kimi w pracy. Kimi K3 jest bardzo uważny; używam go do sprawdzania projektów pod kątem wycieków kluczy i do zbierania informacji. Pewnego razu w ciągu kilku dni wykorzystałem wszystkie jego limity. Kimi nie robi problemów i wykonuje wszystko, o co go poprosisz. Dlatego podczas pracy z nim potrzebujesz izolacji. Opisałem tutaj, jak testowałem go na własnych zadaniach.

Potrzebujesz 2 form izolacji:

1. Blokady poleceń w ustawieniach. Blokują dopasowane wywołania narzędzi; wzorzec jednego zapisu polecenia nie jest pełną granicą przed innymi narzędziami lub równoważnymi czynnościami. Łącz je z uprawnieniami systemu operacyjnego, kontenera i bazy danych.
2. Dostępu do bazy danych w trybie tylko do odczytu. W przypadku działającej bazy danych agent ma osobnego użytkownika z uprawnieniami tylko do odczytu. Dzięki temu nawet w trybie Never Ask nie może jej wyczyścić.

Gdzie działa ochrona przed niebezpiecznymi poleceniami#

Wbudowana ochrona Kimi Code przed niebezpiecznymi poleceniami jest domyślnie włączona. W trybach Always Ask i Ask When Needed przed shutdown, reboot (ponownym uruchomieniem) lub rm -rf pojawia się prośba o potwierdzenie. W trybie Never Ask polecenia te wykonują się bez zatrzymania.

Istnieją 2 wyjątki:

• rm -rf wykonuje się bez pytania, jeśli usuwa tylko zawartość folderów tymczasowych /tmp lub /temp (od wersji 0.43.0);
• w trybie Ask When Needed Kimi Code nie pyta o polecenia terminala, których nie potrafi wcześniej przeanalizować (od wersji 2.0.1).

W wersji 0.40.0 tryb Auto blokował niebezpieczne polecenia; tę blokadę usunięto w wersji 0.41.0.

Ochronę można wyłączyć, ustawiając dangerous_command_guard = false w sekcji [permission] pliku ustawień ~/.kimi-code/config.toml albo używając zmiennej KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. Twórcy zalecają robić to wyłącznie tam, gdzie niebezpieczne polecenia są już przechwytywane zewnętrznie.

Jak ustawić stały zakaz w Kimi Code#

Gdy agent chce coś zmienić, Kimi Code wyświetla panel zatwierdzania:

• Zatwierdź: użyj klawiszy strzałek i Enter albo naciśnij bezpośrednio 1, 2 lub 3;
• Odrzuć: Esc, Ctrl-C lub Ctrl-D;
• Zatwierdź na tę sesję: podobny rodzaj wywołania będzie zatwierdzany do końca sesji;
• Reguły stałe: stała reguła zezwalająca lub zabraniająca w pliku ustawień.

Reguły stałe zapisuje się w pliku ustawień ~/.kimi-code/config.toml, w blokach [[permission.rules]]. Kimi Code sprawdza je po kolei i stosuje pierwszą pasującą, więc zakazy umieszczaj nad zezwoleniami. Każda reguła ma pole decision: allow (zezwól od razu), deny (odrzuć od razu) lub ask (pytaj za każdym razem).

Zakaz wykonania rm -rf i pytanie przed każdym innym poleceniem terminala:

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

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

W przypadku poleceń terminala wzorzec umieszcza się w nawiasach: Bash(command-pattern); przy odczycie plików używa się Read(path-pattern). Narzędzia MCP, AgentSwarm i własne narzędzia można zablokować wyłącznie, podając ich pełne nazwy.

Jeśli nie znasz się na technice i nie chcesz otwierać pliku ustawień, po prostu wklej agentowi poniższy prompt — sam znajdzie to, co należy ograniczyć. Poproś go tylko, by najpierw powiedział, o ile cię to spowolni. Jeśli przywykłeś do pracy bez potwierdzeń, po dodaniu zakazów niektóre rzeczy przestaną działać. Oto mój prompt:

Przeanalizuj mój projekt i powiedz, czy masz dostęp do serwera produkcyjnego, testowej bazy danych i kluczy produkcyjnych. Jeśli tak, skonfiguruj ochronę przed niebezpiecznymi poleceniami: zabroń usuwania całych folderów, poleceń, które nieodwracalnie przepisują historię zmian, oraz bezpośrednich poleceń skierowanych do produkcyjnej bazy danych. Najpierw pokaż plan w formacie „przed - po” i szczerze powiedz, o ile spowolni to twoją pracę.

Opisałem, jak skonfigurować to samo w Claude Code, w osobnym artykule. Zobacz też, jak tryb Auto w Claude Code sprawdza działania agenta.

Który tryb wybrać#

• Chcesz widzieć każdy krok agenta: wybierz domyślny Always Ask. Potwierdzasz wszystko poza odczytem.
• Projekt osobisty lub prototyp bez prawdziwych klientów: zacznij od Always Ask lub Ask When Needed. Never Ask rozważaj tylko dla izolowanej, jednorazowej kopii z ograniczonymi uprawnieniami, bez cennych danych i kluczy; brak klientów sam nie daje bezpieczeństwa.
• Projekt z prawdziwymi klientami i dostępem do serwera: nie włączaj Never Ask. Ustaw zakazy deny w config.toml i przyznaj agentowi dostęp do bazy danych w trybie tylko do odczytu.

Twórz też kopię zapasową bazy danych na maszynie oddzielonej od projektu. Pozostałe zasady bezpieczeństwa zebrano w osobnym artykule.

Dopasuj tryb potwierdzania do uprawnień dostępu w projekcie i sprawdź, gdzie trzeba ustawić zakazy.

Poznaj Ailoot.