# Kimi Code Never Ask: modos e comandos perigosos

> No modo Never Ask, o Kimi Code executa rm -rf e shutdown sem perguntar. Em que diferem os 3 modos e como pode proibir um comando perigoso em config.toml?

Source: https://ailoot.ai/blog/pt-pt/kimi-code-never-ask-mode/
Canonical: https://ailoot.ai/blog/pt-pt/kimi-code-never-ask-mode/
Language: pt-PT
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-162
Revision: sha256-c7f4fcb798aa97f056fb3dd50a8a96573f28dd2756c92d9a5b82b88e94b06f9c


No Kimi Code, o modo Never Ask (`/auto`) aprova tudo automaticamente: executa `rm -rf`, `shutdown` e `reboot` sem fazer uma única pergunta. O agente só pergunta antes destes comandos nos outros 2 modos, Always Ask e Ask When Needed.

Eu próprio trabalho no Claude Code com a opção «permitir tudo» ativada; caso contrário, ficaríamos ali a clicar: sim, sim, sim. Mas uma vez em cada 10, o agente faz as coisas à sua maneira.

Mesmo um protótipo pessoal pode expor ficheiros e credenciais valiosos. Use uma cópia isolada ou um contentor com permissões limitadas e uma cópia de segurança verificada; nos sistemas de clientes, atribua também ao agente uma identidade de base de dados separada, apenas com o acesso necessário.

Vamos ver o que faz cada modo do Kimi Code, onde funciona a proteção e como configurar uma proibição. Vamos a isso.

Para obter informações sobre como utilizar o serviço, consulte a [documentação do Ailoot](https://ailoot.ai/docs/).



<div class="aside" data-semantic="key-takeaway" role="note" aria-label="Ponto principal desta secção">

Ponto principal

O Kimi Code tem 3 modos. Always Ask é o modo predefinido: a leitura acontece automaticamente e confirma todas as restantes ações, uma de cada vez. Ask When Needed (`/yolo`) aprova por si só as edições comuns, mas pergunta antes de aceder a ficheiros com chaves, executar comandos perigosos ou sair do modo de planeamento. Never Ask (`/auto`) não pergunta nada e, neste modo, a proteção contra comandos perigosos não funciona. Configure uma proibição permanente com uma regra `deny` em `~/.kimi-code/config.toml`; é melhor não ativar Never Ask quando o agente tem acesso a uma base de dados ativa.

</div>

## Em que diferem os 3 modos do Kimi Code?

Se já [instalou o Kimi Code](https://ailoot.ai/blog/pt-pt/kimi-code-install/), já viu o painel de aprovação: o agente quer editar um ficheiro ou executar um comando e fica à espera do seu «sim». Os modos chamavam-se anteriormente Manual, YOLO e Auto, daí continuarem a utilizar os comandos antigos: `/yolo` e `/auto`.

**Always Ask.** O modo predefinido. O agente lê ficheiros sem perguntar, mas confirma cada edição e cada comando separadamente. É o modo mais lento.

**Ask When Needed.** Ativa-se com `/yolo`. Aprova por si só as edições e os comandos comuns, mas pergunta antes de aceder a `.env` (o ficheiro que contém as palavras-passe e as chaves do projeto) e às chaves SSH do servidor, antes de comandos perigosos como `shutdown` (desligar o computador) e `rm -rf` (apagar uma pasta inteira, sem passar pelo lixo), e antes de sair do modo de planeamento. O agente também pode fazer-lhe perguntas.

**Never Ask.** Ativa-se com `/auto`. Todas as aprovações acontecem automaticamente, incluindo as de ficheiros sensíveis e a saída do modo de planeamento. O agente não lhe faz perguntas e decide tudo por si.

<figure>
Tabela dos três modos de permissões do Kimi Code: Always Ask, Ask When Needed, Never Ask
<figcaption>3 modos de permissões no Kimi Code CLI.</figcaption>
</figure>

O modo de planeamento é ativado separadamente, com `Shift-Tab` ou `/plan`: primeiro, o agente escreve um plano e aguarda a sua aprovação; só depois mexe nos ficheiros.

## Quando trabalho sem confirmações

No Claude Code, a opção «permitir tudo» é a minha predefinição e fica ativada em cada conversa nova. Sem ela, programar desta forma é demasiado lento. Quem programa assim já percebe muito pouco e ainda tem de estar sempre a carregar em botões: sim, sim, sim, não, não, não.

Mas, neste modo, o agente pode fazer qualquer coisa imprudente, incluindo apagar uma base de dados. Depois diz «desculpe, peço imensa desculpa», mas por vezes já não é possível corrigir o que fez. Por isso, este modo é para quem não tem medo, e a responsabilidade é sua.

Estas são as minhas regras. Em projetos pessoais, experiências e protótipos, use o modo sem confirmações só numa cópia isolada ou num contentor sem ficheiros valiosos nem credenciais de produção, com permissões limitadas e cópia de segurança. A ausência de clientes não protege os seus ficheiros ou chaves, e o isolamento também precisa de ser verificado. Mas, se ativar este modo no mesmo projeto que tem acesso a um servidor de produção, basta 1 pedido para o agente apagar a base de dados durante a noite e implementar alterações no site em produção.





## Porque é que uma proibição escrita por palavras não o protege

Muitas pessoas escrevem «não mexas na base de dados» nas instruções do agente. Não conte com isso para se proteger. Diz-lhe: amigo, não entres aqui. Mas ele entra na mesma e vai buscar o que precisa quando precisa. Isto acontece sobretudo com o Kimi chinês: viola qualquer proibição que configure. Os modelos americanos são muito mais bem treinados para não o fazer.

Continuo a usar o Kimi no meu trabalho. O Kimi K3 é muito atento; uso-o para verificar se há chaves expostas nos projetos e para recolher informações. Uma vez, esgotei todos os seus limites em poucos dias. O Kimi não se porta mal e faz tudo o que lhe pedimos. Por isso, precisa de isolamento quando trabalha com ele. Descrevi [aqui](https://ailoot.ai/blog/pt-pt/kimi-k3-hands-on-review/) como o testei nas minhas próprias tarefas.



Precisa de 2 formas de isolamento:

1.  **Uma lista de bloqueio de comandos nas definições.** Bloqueia chamadas correspondentes às ferramentas; um padrão para uma forma de escrever um comando não cobre outras ferramentas ou ações equivalentes. Combine-a com permissões do sistema operativo, do contentor e da base de dados.
2.  **Acesso à base de dados só de leitura.** Na base de dados em produção, o agente tem um utilizador separado com permissões apenas de leitura. Assim, nem mesmo no modo Never Ask o agente consegue apagar a base de dados.

## Onde funciona a proteção contra comandos perigosos

A proteção integrada do Kimi Code contra comandos perigosos está ativada por predefinição. Nos modos Always Ask e Ask When Needed, pede confirmação antes de `shutdown`, `reboot` (reiniciar) ou `rm -rf`. No modo Never Ask, estes comandos são executados sem interrupção.

Há 2 exceções:

- `rm -rf` é executado sem perguntar se apagar apenas o conteúdo das pastas temporárias `/tmp` ou `/temp` (desde a versão 0.43.0);
- no modo Ask When Needed, o Kimi Code não pergunta sobre comandos de terminal que não consegue analisar antecipadamente (desde a versão 2.0.1).

Na versão 0.40.0, o modo Auto bloqueava comandos perigosos; esse bloqueio foi removido na versão 0.41.0.

<figure>
Antes/agora: o modo autónomo do Kimi Code costumava bloquear comandos perigosos, mas já não o faz
<figcaption>0.40.0: o Auto bloqueava comandos perigosos. 0.41.0: o bloqueio foi removido.</figcaption>
</figure>

Pode desativar a proteção com `dangerous_command_guard = false` na secção `[permission]` do ficheiro de definições `~/.kimi-code/config.toml` ou com a variável `KIMI_CODE_DANGEROUS_COMMAND_GUARD=false`. Os programadores recomendam fazê-lo apenas nos casos em que os comandos perigosos já são intercetados externamente.

## Como configurar uma proibição permanente no Kimi Code

Quando o agente quer alterar alguma coisa, o Kimi Code mostra um painel de aprovação:

- **Aprovar**: utilize as teclas de seta e `Enter`, ou prima diretamente `1`, `2` ou `3`;
- **Rejeitar**: `Esc`, `Ctrl-C` ou `Ctrl-D`;
- **Aprovar para esta sessão**: o mesmo tipo de chamada é aprovado até ao fim da sessão;
- **Regras permanentes**: uma regra permanente de autorização ou proibição no ficheiro de definições.

As regras permanentes são escritas no ficheiro de definições `~/.kimi-code/config.toml`, em blocos `[[permission.rules]]`. O Kimi Code verifica-as por ordem e aplica a primeira correspondência; por isso, coloque as proibições antes das permissões. Cada regra tem uma opção `decision`: `allow` (permitir imediatamente), `deny` (negar imediatamente) ou `ask` (perguntar sempre).

Uma proibição para `rm -rf` e uma pergunta antes de qualquer outro comando de terminal:

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

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

Para comandos de terminal, o padrão fica entre parênteses: `Bash(command-pattern)`; para ler ficheiros, `Read(path-pattern)`. As ferramentas MCP, `AgentSwarm` e as suas próprias ferramentas só podem ser proibidas pelos respetivos nomes completos.

Se não tem conhecimentos técnicos e não quer abrir o ficheiro de definições, basta colar o pedido abaixo no agente: ele descobrirá o que precisa de ser restringido. Peça-lhe apenas que lhe diga primeiro o quanto isso o vai atrasar. Se está habituado a trabalhar sem confirmações, algumas coisas deixarão de funcionar depois de adicionar as proibições. Eis o meu pedido:

```
Analisa o meu projeto e diz-me se tens acesso ao servidor de produção, à base de dados de staging e às chaves de produção. Se tiveres, configura a proteção contra comandos perigosos: proíbe a eliminação de pastas inteiras, os comandos que reescrevem irreversivelmente o histórico de alterações e os comandos diretos para a base de dados de produção. Mostra primeiro um plano no formato «antes - depois» e diz-me honestamente quanto isso me vai atrasar.
```

Expliquei como configurar a mesma coisa no Claude Code [num artigo separado](https://ailoot.ai/blog/pt-pt/claude-code-safe-overnight-setup/). Veja também [como o modo Auto no Claude Code verifica as ações do agente](https://ailoot.ai/blog/pt-pt/claude-code-auto-mode-classifier/).

## Que modo escolher

- **Quer ver cada passo que o agente executa:** Always Ask, o modo predefinido. Confirma tudo, exceto a leitura.
- **Um projeto pessoal ou protótipo sem clientes reais:** comece por Always Ask ou Ask When Needed. Considere Never Ask apenas numa cópia isolada e descartável, com permissões restritas e sem dados ou chaves valiosos; a ausência de clientes não lhe confere segurança.
- **Um projeto com clientes reais e acesso ao servidor:** não ative Never Ask. Configure proibições `deny` em `config.toml` e dê ao agente acesso à base de dados apenas para leitura.

E faça uma cópia de segurança da base de dados num computador separado do projeto. As restantes regras de segurança estão reunidas [num artigo separado](https://ailoot.ai/blog/pt-pt/vibe-coding-security/).

Adapte o modo de confirmação às permissões de acesso do seu projeto e verifique onde precisa de proibições.

<div class="section" role="doc-bibliography" aria-label="Fontes">

### Fontes

- [Kimi Code: interação e introdução de dados](https://moonshotai.github.io/kimi-code/en/g%75ides/interaction.md) — 3 modos de permissões, `/yolo`, `/auto`, proteção contra comandos perigosos em cada modo, o painel de aprovação e o modo de planeamento.
- [Kimi Code: ficheiros de configuração](https://moonshotai.github.io/kimi-code/en/configuration/config-files.md) — `[[permission.rules]]`, a ordem pela qual as regras são verificadas, `dangerous_command_guard`, `KIMI_CODE_DANGEROUS_COMMAND_GUARD` e o caminho para `config.toml`.
- [Kimi Code: registo de alterações](https://moonshotai.github.io/kimi-code/en/release-notes/changelog.md) — versões 0.40.0, 0.41.0, 0.43.0 e 2.0.1: proteção contra comandos perigosos e mudança dos nomes dos modos.

</div>





Conheça o [Ailoot](https://ailoot.ai/).

## Perguntas frequentes

### O Never Ask é seguro só porque o projeto não tem clientes?

Não. O agente pode danificar ficheiros pessoais ou expor chaves. Antes de considerar o modo sem confirmações, use permissões restritas, uma cópia descartável ou contentor isolado e uma cópia de segurança.

### Uma regra deny para rm -rf substitui o isolamento?

Não. Bloqueia chamadas correspondentes às ferramentas, não todas as formas equivalentes de alterar ficheiros. Mantenha dados valiosos e credenciais de produção fora do alcance do agente e use uma identidade de base de dados separada, só com as permissões necessárias à tarefa.


## Ailoot · A empresa e a sua carteira de projetos

A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI.

A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões.

A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.