Kimi Code Never Ask: lägen och farliga kommandon

I Kimi Code godkänner läget Never Ask (/auto) allt automatiskt: det kör rm -rf, shutdown och reboot utan en enda fråga. Agenten frågar bara innan dessa kommandon i de 2 andra lägena, Always Ask och Ask When Needed.

Jag arbetar själv i Claude Code med ”tillåt allt” aktiverat; annars skulle vi sitta och klicka: ja, ja, ja. Men var tionde gång gör agenten som den själv vill.

Även en personlig prototyp kan exponera värdefulla filer och autentiseringsuppgifter. Använd en isolerad kopia eller container med begränsade behörigheter och verifierad säkerhetskopia; ge också agenten en separat databasidentitet med bara nödvändig åtkomst för kundsystem. Då kan den inte radera databasen, även om den verkligen vill.

Låt oss gå igenom vad varje Kimi Code-läge gör, var skyddet fungerar och hur du ställer in ett förbud. Då kör vi.

Information om hur tjänsten används finns i Ailoot-dokumentationen.

Hur skiljer sig Kimi Codes 3 lägen åt?#

Om du redan har installerat Kimi Code har du sett bekräftelsepanelen: agenten vill redigera en fil eller köra ett kommando och väntar på ditt ”ja”. Lägena kallades tidigare Manual, YOLO och Auto, vilket är anledningen till att de fortfarande använder de gamla kommandona: /yolo och /auto.

Always Ask. Standardläget. Agenten läser filer utan att fråga, men du bekräftar varje redigering och varje kommando separat. Det här är det långsammaste läget.

Ask When Needed. Aktiveras med /yolo. Det godkänner vanliga redigeringar och kommandon själv, men frågar innan åtkomst till .env (filen som innehåller projektets lösenord och nycklar) och SSH-nycklar till servrar, innan farliga kommandon som shutdown (stäng av datorn) och rm -rf (radera en hel mapp utan att använda papperskorgen), och innan planläget avslutas. Agenten kan också själv ställa en fråga till dig.

Never Ask. Aktiveras med /auto. Alla åtgärder godkänns automatiskt, även sådana som gäller känsliga filer och att avsluta planläget. Agenten ställer inga frågor till dig och fattar alla beslut själv.

Planläget aktiveras separat med Shift-Tab eller /plan: agenten skriver först en plan och väntar på ditt godkännande, innan den börjar ändra filer.

När jag själv arbetar utan bekräftelser#

I Claude Code är ”tillåt allt” standardläget för mig, aktiverat i varje ny chatt. Utan det går vibe coding för långsamt. En vibe coder förstår redan väldigt lite och måste sedan fortsätta trycka på knappar: ja, ja, ja, nej, nej, nej.

Men i det här läget kan agenten göra precis vad som helst på ett vårdslöst sätt, inklusive att radera en databas. Då säger den ”förlåt, jag ber om ursäkt”, men ibland går det inte längre att åtgärda det den har gjort. Så det här läget är för de orädda, och ansvaret är ditt.

Mina regler är följande. För personliga projekt, experiment och prototyper använder du läget utan bekräftelser bara i en isolerad kopia eller container utan värdefulla filer eller produktionsuppgifter, med begränsade behörigheter och säkerhetskopia. Avsaknad av kunder skyddar inte personliga filer eller nycklar, och isoleringen behöver fortfarande kontrolleras. Men om du aktiverar det här läget i samma projekt som har åtkomst till en produktionsserver räcker det med 1 prompt för att agenten ska radera databasen där över natten och driftsätta ändringar på den aktiva webbplatsen.

Varför ett förbud i ord inte skyddar dig#

Många skriver ”rör inte databasen” i agentens instruktioner. Räkna inte med att det skyddar dig. Du säger till den: kompis, gå inte in här. Men den går ändå in och hämtar det den behöver när den behöver det. Särskilt den kinesiska Kimi: den bryter mot alla förbud du ställer upp. Amerikanska modeller är mycket bättre tränade på att inte göra det.

Jag använder fortfarande Kimi i mitt arbete. Kimi K3 är mycket uppmärksam; jag använder den för att kontrollera om projekt har läckta nycklar och för att samla in information. En gång gjorde jag av med alla dess begränsningar på ett par dagar. Kimi ställer inte till med problem och gör allt du ber om. Därför behöver du isolering när du arbetar med den. Jag beskrev hur jag testade den på mina egna uppgifter här.

Du behöver 2 former av isolering:

1. En blocklista för kommandon i inställningarna. Den blockerar matchande verktygsanrop; ett mönster för ett skrivsätt är ingen fullständig gräns mot andra verktyg eller likvärdiga åtgärder. Använd den tillsammans med operativsystems-, container- och databasbehörigheter.
2. Skrivskyddad databasåtkomst. På den aktiva databasen har agenten en separat användare med skrivskyddade behörigheter. Då kan agenten inte radera databasen, inte ens i Never Ask.

Var fungerar skyddet mot farliga kommandon?#

Kimi Codes inbyggda skydd mot farliga kommandon är aktiverat som standard. I Always Ask och Ask When Needed ber systemet om bekräftelse innan shutdown, reboot (starta om) eller rm -rf. I Never Ask körs dessa kommandon utan att stoppas.

Det finns 2 undantag:

• rm -rf körs utan att fråga om det bara raderar innehållet i de tillfälliga mapparna /tmp eller /temp (sedan version 0.43.0);
• i Ask When Needed frågar Kimi Code inte om terminalkommandon som det inte kan tolka i förväg (sedan version 2.0.1).

I version 0.40.0 blockerade Auto-läget farliga kommandon; blockeringen togs bort i 0.41.0.

Du kan stänga av skyddet med dangerous_command_guard = false i avsnittet [permission] i inställningsfilen ~/.kimi-code/config.toml, eller med variabeln KIMI_CODE_DANGEROUS_COMMAND_GUARD=false. Utvecklarna rekommenderar att bara göra detta där farliga kommandon redan fångas upp externt.

Hur ställer man in ett permanent förbud i Kimi Code?#

När agenten vill ändra något visar Kimi Code en bekräftelsepanel:

• Approve: använd piltangenterna och Enter, eller tryck direkt på 1, 2 eller 3;
• Reject: Esc, Ctrl-C eller Ctrl-D;
• Approve for this session: samma typ av anrop godkänns tills sessionen avslutas;
• Permanent rules: en permanent tillåt- eller neka-regel i inställningsfilen.

Permanenta regler skrivs till inställningsfilen ~/.kimi-code/config.toml i block med [[permission.rules]]. Kimi Code kontrollerar dem i ordning, och den första matchningen gäller, så placera förbud före tillåtelser. Varje regel har ett decision: allow (tillåt direkt), deny (neka direkt) eller ask (fråga varje gång).

Ett förbud mot rm -rf och en fråga före alla andra terminalkommandon:

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

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

För terminalkommandon anges mönstret inom parenteser: Bash(command-pattern); för filläsning används Read(path-pattern). MCP-verktyg, AgentSwarm och dina egna verktyg kan bara förbjudas med sina fullständiga namn.

Om du inte är teknisk och inte vill öppna inställningsfilen kan du helt enkelt klistra in prompten nedan i agenten: den hittar själv vad som behöver begränsas. Be den bara först tala om hur mycket detta kommer att sakta ner dig. Om du är van vid att arbeta utan bekräftelser kommer vissa saker att sluta fungera när du lagt till förbuden. Här är min prompt:

Analysera mitt projekt och berätta om du har åtkomst till produktionsservern, stagingdatabasen och produktionsnycklarna. Om du har det, konfigurera skydd mot farliga kommandon: förbjud radering av hela mappar, kommandon som oåterkalleligt skriver om ändringshistoriken och direkta kommandon mot produktionsdatabasen. Visa först en plan i formatet ”före – efter” och berätta ärligt hur mycket detta kommer att sakta ner mig.

Jag har beskrivit hur du konfigurerar samma sak i Claude Code i en separat artikel. Läs också om hur Auto-läget i Claude Code granskar agentens åtgärder.

Vilket läge ska du välja?#

• Du vill se varje steg agenten tar: Always Ask, standardläget. Du bekräftar allt utom läsning.
• Ett personligt projekt eller en prototyp utan riktiga kunder: börja med Always Ask eller Ask When Needed. Överväg Never Ask bara för en isolerad kopia som kan kastas, med begränsade behörigheter och utan värdefulla data eller nycklar; läget blir inte säkert för att projektet saknar kunder.
• Ett projekt med riktiga kunder och serveråtkomst: aktivera inte Never Ask. Ställ in deny-förbud i config.toml och ge agenten skrivskyddad databasåtkomst.

Säkerhetskopiera dessutom databasen på en annan dator än den där projektet finns. De andra säkerhetsreglerna finns samlade i en separat artikel.

Anpassa bekräftelseläget efter projektets åtkomstbehörigheter och kontrollera var det behövs förbud.

Lär känna Ailoot.