Como rodar Claude Code com segurança no server

O que significa rodar o Claude Code com segurança em um servidor

Para rodar o Claude Code com segurança em um servidor, mantenha os prompts de permissão ativados, execute-o como um usuário sem privilégios dedicado e ofereça às execuções não supervisionadas um limite real em vez de apenas confiança: o sandbox integrado, um container ou uma VPS descartável que não contenha nada importante. A flag --dangerously-skip-permissions remove a etapa de aprovação entre o modelo e o seu shell. Essa troca pode ser aceitável para trabalho não supervisionado, mas apenas dentro de um limite que restrinja o alcance de um comando mal executado. Este guia explica o que a flag realmente altera e como construir esse limite em níveis de isolamento crescentes.

O que o Claude Code pode fazer na sua máquina

O Claude Code é um agente de codificação que roda no seu terminal. Ele lê arquivos, escreve arquivos e executa comandos de shell como o usuário que o iniciou. Esse é o valor central da ferramenta: ele pode clonar um repositório, editar código, rodar testes, ler falhas e corrigir o código em um loop, sem que você precise digitar cada comando. Se você ainda não o configurou em um servidor, rodar o Claude Code em uma VPS com tmux cobre a instalação e o gerenciamento de sessão. Esta página aborda o poder que você entrega a ele uma vez instalado.

O risco é o mesmo conceito lido uma segunda vez. Um processo que executa comandos de shell como seu usuário pode fazer qualquer coisa que seu usuário pode fazer. Ele pode ler ~/.ssh/id_ed25519, ~/.aws/credentials e cada arquivo .env que seu usuário possa abrir. Ele pode executar curl e enviar dados para qualquer host que o servidor consiga alcançar. Ele pode executar git push --force. O agente não tem motivação própria. O perigo é que uma tarefa dê errado, ou que o texto que ele leu enquanto trabalhava contenha instruções escritas por outra pessoa: uma página web que ele buscou ou um comentário em um issue que ele foi solicitado a corrigir. Esse segundo caso é chamado de prompt injection, e é por isso que "o modelo geralmente é sensato" não é um plano de segurança. Planeje para a execução ruim, não para a média.

O sistema de permissões em termos simples

Por padrão, o Claude Code pergunta antes de agir. A leitura de arquivos dentro do projeto ocorre silenciosamente, mas editar um arquivo ou executar um comando de shell mostra a edição ou o comando exato primeiro e aguarda um "sim". Você pode aprovar uma ação ou aprovar esse tipo de ação para o restante da sessão. Essas aprovações têm escopo de sessão: feche o CLI e a próxima sessão começará cautelosa novamente. Para regras que você deseja manter, o arquivo de configurações armazena listas persistentes de allow, ask e deny. Por exemplo: allow git status, ask em git push, deny leituras de .env. Regras de deny sempre têm prioridade.

Este design assume que um humano está observando o terminal, o que é verdade em um laptop. Em um servidor, o ponto é que geralmente ninguém está observando. Você inicia uma tarefa longa dentro do tmux e vai dormir, e um agente que para para fazer uma pergunta às 2 a.m. não progride até a manhã. A pausa custa dinheiro e tempo, pois uma sessão ociosa do Claude Code perde seu cache de prompt quente e o próximo turno pagará para reconstruí-lo. Esse é o motivo real pelo qual as pessoas recorrem à flag de skip em servidores, e o problema que ela resolve é real. O restante deste guia é sobre resolver isso sem abrir mão de todas as proteções.

O que o --dangerously-skip-permissions altera

O claude --dangerously-skip-permissions desativa a etapa de aprovação. Edições ocorrem sem prompt. Comandos de shell rodam sem prompt. As verificações de protected-path que normalmente protegem locais sensíveis também são ignoradas. Suas regras explícitas de deny ainda se aplicam, e algumas ações extremas ainda param para perguntar, mas o resumo operacional é simples: o que quer que o modelo decida executar, será executado.

Dois fatos sobre a flag são importantes em um servidor. Primeiro, ela é bloqueada quando o Claude Code roda como root ou via sudo no Linux e macOS, porque o root sem prompts pode alterar qualquer arquivo ou serviço na máquina. O agente precisa de sua própria conta sem privilégios de qualquer maneira, e a flag reforça isso. Segundo, a flag não altera o comportamento do modelo de forma alguma. Ela remove o humano do loop e não muda mais nada, portanto, cada erro que um prompt teria detectado agora será executado.

Portanto, aqui está o cálculo real. Se você pular as permissões, a questão de segurança muda de "o agente fará algo ruim" para "quanto dano uma única ação ruim pode causar". Você para de tentar controlar cada decisão e começa a controlar o raio de explosão (blast radius). O contenimento é a resposta, e ele ocorre em níveis.

O sandbox integrado do Claude Code

Antes dos níveis, saiba que o Claude Code agora inclui um sandbox de nível de OS para os comandos que executa, o que remove a maioria dos motivos pelos quais as pessoas recorriam à flag de skip. No Linux, ele usa bubblewrap para isolamento de filesystem, além de socat para rotear o tráfego de rede através de um proxy. Dentro do sandbox, um comando pode escrever apenas no diretório do projeto e em um diretório temporário de sessão, e pode alcançar a rede apenas através de um proxy que verifica cada domínio contra uma lista de permissões. A primeira vez que um comando solicita um novo domínio, o Claude Code pergunta a você.

Ative-o com o comando /sandbox dentro de uma sessão. No Ubuntu e Debian, instale primeiro os dois pacotes necessários:

sudo apt install bubblewrap socat

No Ubuntu 24.04 e versões posteriores, a política padrão do AppArmor impede que o bubblewrap crie os user namespaces de que precisa. O painel do sandbox avisa quando algo está faltando, e a documentação de sandboxing do Claude Code contém o perfil curto do AppArmor que corrige isso.

O sandbox possui um modo auto-allow: comandos em sandbox rodam sem qualquer prompt, porque o limite imposto agora faz o trabalho que o prompt fazia. Comandos que não podem rodar dentro do sandbox revertem para o fluxo de permissão normal, então ações genuinamente incomuns ainda perguntam. Para a maioria dos workflows de servidor, esta é a substituição correta para a flag de skip, pois você recebe muito menos perguntas com um limite imposto pelo OS em vez de nenhuma.

Seja honesto sobre os limites. Por padrão, um comando em sandbox ainda pode ler a maior parte do filesystem, incluindo arquivos de credenciais, a menos que você negue esses caminhos; a configuração sandbox.credentials existe exatamente para isso. O proxy de rede verifica nomes de domínio e não inspeciona o tráfego em si, então um allow amplo como github.com ainda deixa margem para extração de dados. O Docker não funciona dentro dele. O sandbox eleva muito o nível de segurança base. Não é um limite de isolamento completo, por isso os níveis abaixo ainda importam.

A escada de contenção

Três níveis, em ordem crescente de isolamento. Escolha o nível mais baixo que corresponda ao que mais reside na máquina.

Nível 1: um usuário sem privilégios dedicado. O agente recebe sua própria conta, seu próprio home directory, seu próprio diretório de projeto e nenhum sudo:

sudo adduser --disabled-password --gecos "" agent

O limite da conta mantém o agente fora dos seus arquivos: suas chaves SSH e todos os outros projetos na máquina. Isso também torna a flag de skip utilizável, já que a flag recusa rodar como root. Este é o mesmo princípio de rodar cada serviço como um usuário sem privilégios, aplicado a um agente. O que o nível 1 não limita: a rede e qualquer coisa na máquina que seja legível por todos (world-readable).

Nível 2: um container. A Anthropic publica um devcontainer de referência que roda o Claude Code como um usuário não-root, com regras de firewall que limitam quais hosts o agente pode alcançar; um container que você mesmo constrói faz o mesmo trabalho. O filesystem encolhe para os volumes que você monta, e o tráfego de saída encolhe para o que as regras do container permitem. Este é o nível intermediário correto quando o servidor hospeda outros serviços importantes. Seu limite é que containers compartilham o kernel do host, e um mount descuidado anula o limite; entregue ao container /var/run/docker.sock e ele poderá alcançar todo o host.

Nível 3: uma VPS dedicada. O nível mais forte é o mais direto: dê ao agente uma máquina inteira que não contenha nada importante para você. Uma pequena VPS custa poucos dólares por mês. Configure-a com o runbook de dez minutos iniciais em uma nova VPS, tire um snapshot do estado limpo e deixe o agente trabalhar. Nada mais vive lá. Sem chaves SSH pessoais, apenas uma deploy key restrita a um único repositório. Sem credenciais de nuvem, sem dados de produção. Se uma execução der errado, ou se você simplesmente quiser um estado limpo, restaure o snapshot ou destrua e reconstrua a máquina em minutos. O raio de explosão é o custo do aluguel. Este é o setup onde o --dangerously-skip-permissions deixa de ser assustador, pois o pior resultado realista é um servidor reconstruído e um token revogado.

Os níveis se acumulam. Um agente em sandbox, rodando como um usuário sem privilégios, em uma VPS descartável, custa quase nada extra e torna as histórias de falhas entediantes. Entediante é o objetivo.

Proteja as credenciais

A regra que paga por todo o resto: o usuário do agente não deve ser capaz de ler segredos que pertencem a qualquer outra coisa.

Dê a chave de API ao agente e a mais nada. Coloque-a em um arquivo pertencente ao usuário do agente com modo 600, e carregue-a quando um shell iniciar:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

Depois, feche a outra direção. No Debian e Ubuntu, os home directories são frequentemente criados como legíveis por todos os usuários da máquina, então restrinja o seu: chmod 750 /home/youruser. Verifique com ls -ld /home/* e corrija qualquer coisa que a conta do agente possa listar.

Limite cada token. Um token do GitHub de granularidade fina limitado a um repositório, ou uma deploy key por repositório, significa que uma credencial vazada perde apenas um projeto e não sua conta inteira. Se você usar o sandbox, adicione suas configurações de credenciais para que ~/.ssh e ~/.aws sejam negados mesmo para leituras. E mantenha credenciais de produção totalmente fora da máquina, pois um agente não pode vazar um segredo que nunca esteve lá.

Git é a rede de segurança

Cada alteração que o agente faz deve ser revisável e revertível, e o git oferece ambos gratuitamente se o agente trabalhar em uma branch:

git switch -c agent/refactor-auth

Revise a execução depois com git diff main...agent/refactor-auth, faça o merge do que estiver correto e delete a branch se a execução não levar a lugar nenhum. Proteja a branch main no lado do forge, para que o token do agente não possa dar push nela e não possa dar force-push em lugar nenhum. O histórico de commits serve também como um log de auditoria do que aconteceu enquanto você dormia, o que vale mais do que qualquer quantidade de log de terminal.

A rede faz parte do raio de explosão

Um agente pode executar curl. Essa frase é todo o problema de saída (egress): o que quer que o agente consiga ler, ele também pode enviar para algum lugar, e um agente com prompt injection pode fazer isso. Um usuário sem privilégios comum não limita isso de forma alguma, pois qualquer usuário pode alcançar qualquer coisa que o servidor alcance. O sandbox limita isso por domínio através de seu proxy. Um container pode limitar isso com suas próprias regras de firewall. Uma VPS dedicada limita o que há para vazar em primeiro lugar, que é a resposta mais robusta das três.

Não tente resolver o egress apenas com ufw. O ufw permite todo o tráfego de saída por padrão, e escrever regras de saída que ainda permitam apt, npm, git e a API do Claude é um trabalho minucioso que quebra silenciosamente. Escolha o limite no nível de sandbox, container ou máquina, onde uma lista de permissões de domínio ou uma máquina pura faz o mesmo trabalho de forma limpa.

Se você estiver construindo seu próprio agente via API em vez de rodar o Claude Code, o mesmo raciocínio se aplica sem alterações. Construindo um agente de IA com Claude em uma VPS cobre esse caminho, e seu agente merece o mesmo usuário dedicado, os mesmos tokens limitados e a mesma máquina descartável.

Endureça a máquina primeiro

Seja qual for o nível que você escolher, a máquina em si ainda precisa do básico antes do agente se instalar: apenas chaves SSH, sem login como root, um firewall de negação padrão (default-deny) e atualizações de segurança automáticas. Gere seu checklist aqui e execute-o uma vez:

FAQ

O --dangerously-skip-permissions é seguro para usar em um servidor?

Não por si só. A flag remove todos os prompts de aprovação, então o primeiro comando ruim roda no momento em que o modelo o produz. Torna-se uma troca defensável quando o raio de explosão está contido: um usuário sem privilégios dedicado no mínimo, e para trabalho genuinamente não supervisionado, um container ou uma VPS descartável que contenha apenas um projeto e um token limitado. Nunca use em uma máquina que contenha credenciais de produção ou dados que você não possa perder.

O Claude Code possui um sandbox?

Sim. O Claude Code inclui um sandbox integrado para comandos de shell, ativado com o comando /sandbox. Ele usa bubblewrap no Linux e Seatbelt no macOS, limita as escritas ao diretório do projeto e roteia o acesso à rede através de um proxy que só permite domínios aprovados. Seu modo auto-allow executa comandos em sandbox sem prompts, o que reduz interrupções da mesma forma que a flag de skip, mantendo um limite imposto pelo OS. Não é um limite de isolamento completo, portanto, combine-o com um usuário dedicado ou uma máquina dedicada para execuções não supervisionadas.

Por que a flag de skip recusa rodar como root?

Porque o root sem prompts de permissão pode modificar qualquer arquivo e qualquer serviço no sistema, o Claude Code bloqueia --dangerously-skip-permissions quando roda como root ou via sudo no Linux e macOS. A solução não é lutar contra a verificação. Crie um usuário sem privilégios para o agente e rode-o lá; esse limite de conta é a primeira e mais barata camada de contenção.

O Claude Code pode ler minhas chaves SSH e arquivos .env?

Ele pode ler o que quer que o usuário que o executa possa ler, e até a política padrão do sandbox permite leituras de caminhos de credenciais até que você os negue. Portanto, rode o agente como seu próprio usuário, mantenha seu próprio home directory em modo 750 ou mais restrito, negue caminhos de credenciais nas configurações do sandbox e mantenha segredos de produção totalmente fora da máquina. Um segredo que a máquina nunca teve não pode ser lido ou vazado.

Qual é a maneira mais segura de rodar o Claude Code sem supervisão?

Uma VPS dedicada barata usada apenas para trabalho do agente: endurecida em dez minutos, com snapshot limpo, rodando o Claude Code sob um usuário sem privilégios com o sandbox ativado, um arquivo modo-600 contendo a chave de API, uma deploy key por repositório e todo o trabalho em branches que você revisa antes de fazer o merge. Se uma execução der errado, você revoga um token e restaura o snapshot, e nada mais que você possui é afetado.