# Kimi Code Never Ask: tilstande og farlige kommandoer
> I Never Ask-tilstand kører Kimi Code rm -rf og shutdown uden at spørge. Hvad er forskellen på de 3 tilstande, og hvordan kan du forbyde en farlig kommando i config.toml?
Source: https://ailoot.ai/blog/da/kimi-code-never-ask-mode/
Canonical: https://ailoot.ai/blog/da/kimi-code-never-ask-mode/
Language: da
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-162
Revision: sha256-a34353d1691c722da87418d7b4f0f524907dacf365c41c23465793e0c6246dbc
I Kimi Code godkender Never Ask-tilstanden (`/auto`) alt automatisk: Den udfører `rm -rf`, `shutdown` og `reboot` uden at stille et eneste spørgsmål. Agenten spørger kun, før den udfører disse kommandoer, i de 2 andre tilstande, Always Ask og Ask When Needed.
Jeg arbejder selv i Claude Code med ”tillad alt” slået til; ellers ville vi sidde og klikke: ja, ja, ja.
Selv en personlig prototype kan eksponere værdifulde filer og legitimationsoplysninger. Brug en isoleret kopi eller container med begrænsede tilladelser og en verificeret sikkerhedskopi. Giv desuden agenten en separat databaseidentitet med kun den nødvendige adgang i kundesystemer. Så kan den ikke slette databasen, selv hvis den virkelig gerne vil.
Lad os se på, hvad hver Kimi Code-tilstand gør, hvor beskyttelsen virker, og hvordan du indstiller et forbud. Lad os komme i gang.
Se [Ailoot-dokumentationen](https://ailoot.ai/docs/) for oplysninger om, hvordan du bruger tjenesten.
Vigtig pointe
Kimi Code har 3 tilstande. Always Ask er standardtilstanden: læsning sker automatisk, og du bekræfter alt andet én handling ad gangen. Ask When Needed (`/yolo`) godkender selv almindelige redigeringer, men spørger, før den får adgang til filer med nøgler, kører farlige kommandoer eller forlader planlægningstilstand. Never Ask (`/auto`) spørger ikke om noget, og beskyttelsen mod farlige kommandoer virker ikke i denne tilstand. Du indstiller et permanent forbud med en `deny`-regel i `~/.kimi-code/config.toml`, og det er bedst ikke at aktivere Never Ask, når der er en aktiv database.
## Hvad er forskellen på Kimi Codes 3 tilstande?
Hvis du allerede har [installeret Kimi Code](https://ailoot.ai/blog/da/kimi-code-install/), har du set godkendelsespanelet: Agenten vil redigere en fil eller køre en kommando og venter på dit ”ja”. Tilstandene hed tidligere Manual, YOLO og Auto, og derfor bruger de stadig de gamle kommandoer: `/yolo` og `/auto`.
**Always Ask.** Standardtilstanden. Agenten læser filer uden at spørge, men du bekræfter hver redigering og hver kommando separat. Det er den langsomste tilstand.
**Ask When Needed.** Aktiveres med `/yolo`. Den godkender selv almindelige redigeringer og kommandoer, men spørger, før den får adgang til `.env` (filen med projektets adgangskoder og nøgler) og SSH-nøgler til servere, før farlige kommandoer som `shutdown` (sluk computeren) og `rm -rf` (slet en hel mappe uden om papirkurven), og før den forlader planlægningstilstand. Agenten kan også selv stille dig et spørgsmål.
**Never Ask.** Aktiveres med `/auto`. Alle godkendelser gives automatisk, også for følsomme filer og for at forlade planlægningstilstand. Agenten stiller dig ingen spørgsmål og beslutter alt selv.
Tabel over de tre tilladelsestilstande i Kimi Code: Always Ask, Ask When Needed, Never Ask
3 tilladelsestilstande i Kimi Code CLI.
Planlægningstilstand aktiveres separat med `Shift-Tab` eller `/plan`: Agenten skriver først en plan og venter på din godkendelse, før den rører filerne.
## Når jeg selv arbejder uden bekræftelser
I Claude Code er ”tillad alt” min standardindstilling, og den er slået til i hver ny chat. Uden den går vibe coding for langsomt. En vibe coder forstår i forvejen meget lidt og skal så blive ved med at trykke på knapper: ja, ja, ja, nej, nej, nej.
Men i denne tilstand kan agenten gøre hvad som helst helt hovedløst, også slette en database. Bagefter siger den ”undskyld, jeg beklager”, men nogle gange kan det, den har gjort, ikke længere gøres godt igen. Så denne tilstand er for de frygtløse, og ansvaret er dit.
Mine regler er disse. Brug kun tilstand uden bekræftelser til personlige projekter, eksperimenter og prototyper i en isoleret kopi eller container uden værdifulde filer eller produktionshemmeligheder, med begrænsede tilladelser og en sikkerhedskopi. Fraværet af kunder beskytter ikke dine personlige filer eller nøgler, og isoleringen skal stadig kontrolleres. Men hvis du aktiverer denne tilstand i det samme projekt, som har adgang til en produktionsserver, er 1 prompt nok til, at agenten sletter databasen dér i løbet af natten og udruller ændringer til det aktive websted.
## Hvorfor et forbud med ord ikke redder dig
Mange skriver ”rør ikke databasen” i agentens instruktioner. Regn ikke med, at det redder dig. Du siger: makker, gå ikke herind. Men den går alligevel ind og tager det, den har brug for, når den har brug for det. Især den kinesiske Kimi: Den overtræder ethvert forbud, du indfører. Amerikanske modeller er meget bedre trænet til ikke at gøre det.
Jeg bruger stadig Kimi i mit arbejde. Kimi K3 er meget opmærksom; jeg bruger den til at tjekke projekter for lækkede nøgler og indsamle oplysninger. Engang brugte jeg alle dens begrænsninger op på et par dage. Kimi laver ikke ballade og gør alt, hvad du beder om. Derfor skal du isolere den, når du arbejder med den. Jeg har beskrevet, hvordan jeg testede den på mine egne opgaver [her](https://ailoot.ai/blog/da/kimi-k3-hands-on-review/).
Du har brug for 2 former for isolering:
1. **En kommandoblokliste i indstillingerne.** Den blokerer matchende værktøjskald; et mønster for én kommandostavemåde er ikke en fuldstændig grænse mod andre værktøjer eller tilsvarende handlinger. Brug den sammen med tilladelser i operativsystem, container og database.
2. **Skrivebeskyttet databaseadgang.** På den aktive database har agenten en separat bruger med skrivebeskyttede rettigheder. Så kan agenten ikke slette databasen, selv i Never Ask.
## Hvor virker beskyttelsen mod farlige kommandoer?
Kimi Codes indbyggede beskyttelse mod farlige kommandoer er slået til som standard. I Always Ask og Ask When Needed beder den om bekræftelse, før den udfører `shutdown`, `reboot` (genstart) eller `rm -rf`. I Never Ask udføres disse kommandoer uden at blive standset.
Der er 2 undtagelser:
- `rm -rf` kører uden at spørge, hvis det kun sletter indholdet i de midlertidige mapper `/tmp` eller `/temp` (siden version 0.43.0);
- i Ask When Needed spørger Kimi Code ikke om terminalkommandoer, som den ikke kan analysere på forhånd (siden version 2.0.1).
I version 0.40.0 blokerede Auto-tilstanden farlige kommandoer; blokeringen blev fjernet i 0.41.0.
Før/nu: Kimi Codes autonome tilstand blokerede tidligere farlige kommandoer, men gør det ikke længere
0.40.0: Auto blokerede farlige kommandoer. 0.41.0: blokeringen blev fjernet.
Du kan slå beskyttelsen fra med `dangerous_command_guard = false` i afsnittet `[permission]` i indstillingsfilen `~/.kimi-code/config.toml` eller med variablen `KIMI_CODE_DANGEROUS_COMMAND_GUARD=false`. Udviklerne anbefaler kun at gøre dette på steder, hvor farlige kommandoer allerede opfanges eksternt.
## Sådan indstiller du et permanent forbud i Kimi Code
Når agenten vil ændre noget, viser Kimi Code et godkendelsespanel:
- **Approve**: brug piletasterne og `Enter`, eller tryk direkte på `1`, `2` eller `3`;
- **Reject**: `Esc`, `Ctrl-C` eller `Ctrl-D`;
- **Approve for this session**: samme type kald godkendes indtil sessionens afslutning;
- **Permanent rules**: en permanent tillad- eller deny-regel i indstillingsfilen.
Permanente regler skrives i indstillingsfilen `~/.kimi-code/config.toml` i blokke med `[[permission.rules]]`. Kimi Code kontrollerer dem i rækkefølge, og den første regel, der matcher, gælder, så placér forbud over tilladelser. Hver regel har en `decision`: `allow` (tillad straks), `deny` (afvis straks) eller `ask` (spørg hver gang).
Et forbud mod `rm -rf` og et spørgsmål før alle andre terminalkommandoer:
```toml
[[permission.rules]]
decision = "deny"
pattern = "Bash(rm -rf*)"
[[permission.rules]]
decision = "ask"
pattern = "Bash"
```
For terminalkommandoer sættes mønsteret i parenteser: `Bash(command-pattern)`; ved læsning af filer bruges `Read(path-pattern)`. MCP-værktøjer, `AgentSwarm` og dine egne værktøjer kan kun forbydes ved deres fulde navne.
Hvis du ikke er teknisk anlagt og ikke vil åbne indstillingsfilen, kan du blot indsætte prompten nedenfor i agenten: Den finder selv ud af, hvad der skal begrænses. Bed den bare om først at fortælle dig, hvor meget det vil sænke dig. Hvis du er vant til at arbejde uden bekræftelser, vil noget holde op med at fungere, når du har tilføjet forbuddene. Her er min prompt:
```
Analysér mit projekt, og fortæl mig, om du har adgang til produktionsserveren, stagingdatabasen og produktionsnøglerne. Hvis du har det, skal du konfigurere beskyttelse mod farlige kommandoer: forbyd sletning af hele mapper, kommandoer, der uigenkaldeligt omskriver ændringshistorikken, og direkte kommandoer mod produktionsdatabasen. Vis først en plan i formatet ”før – efter”, og fortæl ærligt, hvor meget det vil sænke mig.
```
Jeg har beskrevet, hvordan du indstiller det samme i Claude Code [i en separat artikel](https://ailoot.ai/blog/da/claude-code-safe-overnight-setup/). Se også [hvordan Auto-tilstanden i Claude Code kontrollerer agentens handlinger](https://ailoot.ai/blog/da/claude-code-auto-mode-classifier/).
## Hvilken tilstand skal du vælge?
- **Du vil se hvert trin, agenten tager:** Always Ask, standardtilstanden. Du bekræfter alt undtagen læsning.
- **Et personligt projekt eller en prototype uden rigtige kunder:** Start med Always Ask eller Ask When Needed. Overvej kun Never Ask til en isoleret kopi, der kan kasseres, med begrænsede tilladelser og uden værdifulde data eller nøgler; projektet bliver ikke sikkert alene ved at mangle kunder.
- **Et projekt med rigtige kunder og adgang til en server:** Aktivér ikke Never Ask. Indstil `deny`-forbud i `config.toml`, og giv agenten skrivebeskyttet databaseadgang.
Tag også en sikkerhedskopi af databasen på en maskine, der er adskilt fra projektet. De øvrige sikkerhedsregler er samlet [i en separat artikel](https://ailoot.ai/blog/da/vibe-coding-security/).
Tilpas bekræftelsestilstanden efter dit projekts adgangsrettigheder, og kontrollér, hvor der er brug for forbud.
### Kilder
- [Kimi Code: Interaction and input](https://moonshotai.github.io/kimi-code/en/g%75ides/interaction.md) — 3 tilladelsestilstande, `/yolo`, `/auto`, beskyttelse mod farlige kommandoer i hver tilstand, godkendelsespanelet, planlægningstilstand.
- [Kimi Code: Configuration files](https://moonshotai.github.io/kimi-code/en/configuration/config-files.md) — `[[permission.rules]]`, rækkefølgen reglerne kontrolleres i, `dangerous_command_guard`, `KIMI_CODE_DANGEROUS_COMMAND_GUARD`, stien til `config.toml`.
- [Kimi Code: Changelog](https://moonshotai.github.io/kimi-code/en/release-notes/changelog.md) — versionerne 0.40.0, 0.41.0, 0.43.0 og 2.0.1: beskyttelse mod farlige kommandoer og omdøbning af tilstandene.
Lær [Ailoot](https://ailoot.ai/) at kende.
## Spørgsmål og svar
### Er Never Ask sikkert alene, fordi projektet ikke har kunder?
Nej. Agenten kan stadig beskadige personlige filer eller eksponere nøgler. Brug begrænsede tilladelser, en isoleret kopi eller container, der kan kasseres, og en sikkerhedskopi, før du overvejer tilstand uden bekræftelser.
### Erstatter en deny-regel for rm -rf isolering?
Nej. Den blokerer matchende værktøjskald, ikke enhver tilsvarende måde at ændre filer på. Hold værdifulde data og produktionshemmeligheder uden for agentens adgang, og brug en separat databaseidentitet med kun de rettigheder, opgaven kræver.
## Ailoot · Virksomheden og dens projektportefølje
Ailoot bygger på solid driftserfaring, en stor kundebase, stabil service og løbende kontrol af KPI.
Virksomheden og dens projektportefølje: millioner af kunder; månedligt salg for milliarder.
Ailoot bruger denne driftserfaring til API-adgang til AI-funktioner i kundernes produkter, agenter, applikationer og automatiseringer.