Partindo do princípio de que o Claude Code pode ler e modificar arquivos e executar comandos, este artigo reúne as verificações de segurança que iniciantes devem fazer antes, durante e depois do trabalho. Ele conecta em uma única lista as diferenças entre os modos de permissão, as mudanças que os checkpoints não conseguem restaurar, a diferença de função em relação ao git e a regra de não inserir informações secretas.
Para quem éUsuários iniciantes que querem entender o alcance das permissões e da recuperação e criar hábitos de trabalho seguros antes de usar Claude Code em um projeto real
O uso seguro começa antes de enviar o prompt. Primeiro, confirme se o terminal está na pasta correta e, se estiver praticando, use uma pasta separada do repositório real de trabalho. Se o projeto contiver arquivos sensíveis como `.env`, certificados ou materiais pessoais, revise primeiro quais informações ficarão acessíveis à ferramenta de IA. Mesmo que o exemplo pareça exigir uma chave de API, use apenas um valor claramente fictício como `sk-EXAMPLE-NOT-REAL`, nunca uma chave real.
Verificações antes de começar
- A pasta atual é o projeto que eu pretendia usar?
- Os arquivos de exemplo não contêm dados pessoais reais, senhas nem chaves de API?
- Revisei com git o estado anterior à mudança ou fiz um commit, se necessário?
- Se for uma tarefa nova para mim, estou começando com um fluxo focado em revisão, como plan ou Manual?A existência de checkpoints no Claude Code não elimina a necessidade de controle de versão independente. A documentação oficial afirma explicitamente que checkpoints não substituem um sistema como git. Em projetos importantes, mantenha práticas normais de controle de versão, como fazer um commit antes do trabalho ou usar uma branch separada.
Os modos de permissão descritos na documentação oficial são Manual, acceptEdits, plan, auto, dontAsk e bypassPermissions. A Worknote recomenda que iniciantes comecem com Manual ou plan. Isso não significa que o risco desapareça; é uma escolha voltada a criar o hábito de ler primeiro o escopo das mudanças e decidir conscientemente.
| Modo | Comportamento confirmado | Observação para iniciantes |
|---|---|---|
| Manual | Valor de configuração default; leitura automática, edição e comandos com confirmação | Avançar revisando mudanças e comandos |
| acceptEdits | Edição de arquivos e comandos comuns como mkdir, touch, mv e cp de forma automática | Usar somente depois de entender o escopo das mudanças automáticas |
| plan | Análise e planejamento centrados em leitura | Usar para revisar o escopo antes de implementar |
| auto | Um modelo classificador revisa as ações no lugar da pessoa e a maioria é executada sem perguntar | Verificar separadamente os resultados e o escopo das mudanças |
| dontAsk | Usar apenas ferramentas permitidas previamente | Entender o escopo das ferramentas permitidas |
| bypassPermissions | Ignorar todas as verificações | Usar somente em contêineres ou VMs isolados |
O modo inicial padrão varia conforme o plano. Na documentação oficial revisada em 2026-09-22, o modo inicial padrão do terminal interativo para os planos Pro, Max e Team é descrito como auto, enquanto para outros planos é Manual. Portanto, não presuma que o mesmo fluxo de aprovação sempre aparecerá; verifique o modo atual.
claude --permission-mode planO Claude Code pode ler por conta própria os arquivos necessários e solicitar aprovação antes de modificar arquivos ou executar comandos. Porém, o simples aparecimento de uma janela de aprovação não garante que o comando seja seguro. Leia primeiro quais arquivos serão alterados, se há operações de exclusão, movimentação ou cópia e se aparece alguma instalação ou expansão de escopo que você não solicitou.
Antes de alterar qualquer coisa, informe somente o seguinte.
1. Os nomes dos arquivos que serão modificados
2. O que será alterado em cada arquivo
3. Os comandos de shell que pretende executar
4. Se existe alguma operação que exclua, mova ou sobrescreva arquivos originais
Ainda não modifique arquivos nem execute comandos.O Claude Code cria um checkpoint automático a cada prompt enviado. Você pode abrir o menu de restauração com `/rewind` ou pressionando Esc duas vezes quando a caixa de entrada estiver vazia, e escolher opções como restaurar código e conversa, somente a conversa, somente o código ou um resumo. Porém, esse recurso não registra todas as mudanças de arquivos.
/rewind| Tipo de mudança | Limitação do checkpoint | Medida adicional |
|---|---|---|
| Mudanças rastreadas pelo Claude Code | Podem estar disponíveis para restauração | Usar também git em trabalhos importantes |
| Arquivos alterados por comandos Bash como rm, mv ou cp | Não são rastreados nem restaurados | Verificar o alvo antes do comando e preparar um meio de recuperação independente |
| Arquivos modificados diretamente fora do Claude Code | Não são rastreados | Verificar separadamente com git diff ou outras ferramentas |
| Histórico de versões do projeto | Não substitui git | Manter controle de versão com commits, branches ou outros mecanismos |
Em especial, não espere que `/rewind` restaure completamente arquivos excluídos ou movidos por comandos de shell. Considere os checkpoints um recurso auxiliar para reverter trabalho dentro do Claude Code e gerencie o histórico do projeto e a recuperação com ferramentas independentes como git.
Não coloque senhas, chaves de API, informações reais de clientes nem dados reais de pesquisa em prompts ou arquivos de exemplo apenas porque o código parece precisar deles. Em tutoriais e reproduções de erros, use dados sintéticos e tokens claramente fictícios. Em um projeto real, verifique separadamente quais dados podem ser fornecidos à ferramenta de acordo com a política da organização e o ambiente de uso.
Valor fictício para prática:
API_KEY=sk-EXAMPLE-NOT-REAL
Dados fictícios:
date,category,amount
2026-09-01,food,12000Se o projeto já contiver informações sensíveis, não presuma que basta pedir “não olhe esse arquivo”. Revise o alcance dos arquivos aos quais a ferramenta pode acessar e a política de segurança; se necessário, reproduza o problema em uma cópia de trabalho da qual as informações sensíveis tenham sido removidas.
Depois que o trabalho terminar, avalie o resultado pelos arquivos reais e pela execução, não pelo fato de a IA dizer que “concluiu”. Como no artigo anterior, leia git diff, execute novamente os comandos e compare com os valores esperados. Se for uma correção de erro, não verifique apenas se o problema desapareceu: confirme também se a entrada que antes funcionava corretamente ainda produz o mesmo resultado.
Verificações depois do trabalho
- No git diff, somente os arquivos esperados foram alterados?
- O resultado da execução corresponde aos valores esperados dos requisitos?
- Não ficaram arquivos temporários nem informações secretas fictícias entre os itens que serão commitados?
- O motivo da mudança e a forma de execução ficaram registrados para que outra pessoa possa entender?As explicações em linguagem natural do Claude Code são material de apoio para a revisão. A decisão final é tomada comparando o diff real, os resultados da execução e as regras do projeto. Esse princípio pode ser mantido mesmo se o modelo ou o modo de permissão mudar.
| Momento | Pergunta de verificação | Se houver um problema |
|---|---|---|
| Antes do trabalho | É a pasta correta, não há informações sensíveis e existe um meio de recuperação? | Preparar primeiro a pasta de prática, os dados fictícios e o estado do git |
| Durante o trabalho | Você entende quais arquivos e comandos está aprovando? | Interromper a aprovação e revisar novamente o escopo em plan |
| Antes de restaurar | É uma mudança de Bash ou externa que o checkpoint não rastreia? | Verificar meios de recuperação independentes, como git ou backup |
| Depois do trabalho | O diff e os resultados da execução correspondem aos requisitos? | Identificar a causa e modificar novamente apenas o necessário |
O princípio comum desta série é definir primeiro requisitos pequenos, começar pela leitura e pelo planejamento, verificar o escopo das mudanças e fazer com que uma pessoa confira os resultados da execução. À medida que o alcance da automação aumenta, o papel humano não desaparece: ele se desloca para verificar o que foi permitido e se o resultado corresponde aos critérios definidos.
Redigido com base na documentação oficial do Claude Code, revisada em 2026-09-22 · Claude Code não foi realmente executado · Não há código Python executável
Este artigo foi redigido com base na documentação oficial do Claude Code revisada em 2026-09-22 e não constitui registro de teste real dos modos de permissão ou dos checkpoints do Claude Code. Antes de aplicá-lo a um projeto real, verifique separadamente a política de segurança da organização e a documentação oficial mais recente.