Como executar o Claude Code com segurança no servidor

O que significa executar o Claude Code com segurança num servidor

Para executar o Claude Code com segurança num servidor, mantenha os pedidos de permissão ativos, execute-o com um utilizador dedicado sem privilégios e dê às execuções não supervisionadas uma barreira real, em vez de confiar nelas: o sandbox integrado, um contentor ou um VPS descartável que não contenha nada importante. A opção --dangerously-skip-permissions remove a etapa de aprovação entre o modelo e a shell. Esta troca pode ser adequada para tarefas não supervisionadas, mas apenas dentro de uma barreira que limite o alcance de um comando incorreto. Este guia explica o que a opção realmente altera e como criar essa barreira em níveis de isolamento crescente.

O que o Claude Code pode fazer no seu servidor

O Claude Code é um agente de programação que é executado no seu terminal. Ele lê ficheiros, escreve ficheiros e executa comandos de shell com o mesmo utilizador que o iniciou. Esse é todo o valor da ferramenta: pode clonar um repositório, editar código, executar os testes, ler o erro e corrigir o código num ciclo, sem que tenha de escrever cada comando. Se ainda não o configurou num servidor, executar o Claude Code numa VPS com tmux explica a instalação e a gestão da sessão. Esta página explica os privilégios que lhe concede depois de o instalar.

O risco fica claro quando se repete a frase. Um processo que executa comandos de shell com o seu utilizador pode fazer tudo o que esse utilizador pode fazer. Pode ler ~/.ssh/id_ed25519, ~/.aws/credentials e todos os ficheiros .env que o seu utilizador consegue abrir. Pode executar curl e enviar dados para qualquer host que o servidor consiga alcançar. Pode executar git push --force. O agente não tem motivos próprios. O perigo é uma tarefa correr mal ou o texto lido durante o trabalho conter instruções escritas por outra pessoa: uma página Web que obteve ou um comentário numa issue que lhe foi pedido para corrigir. Esse segundo caso chama-se prompt injection. Por isso, "o modelo costuma ser sensato" não é um plano de segurança. As instruções também podem chegar de uma origem mais próxima, porque duas sessões do Claude Code no mesmo servidor podem enviar texto uma à outra, e uma mensagem de uma sessão irmã é apenas mais texto que o agente recetor lê. Deve preparar-se para a execução problemática, não para a execução média.

O sistema de permissões em termos simples

No modo Manual, o Claude Code pede confirmação antes de agir. A leitura de ficheiros dentro do projeto acontece silenciosamente, mas a edição de um ficheiro ou a execução de um comando shell mostra primeiro a alteração ou o comando exato e aguarda uma confirmação. Pode aprovar uma ação ou indicar que não quer que volte a perguntar. A segunda opção mantém-se até ao fim da sessão para edições de ficheiros, mas, para um comando shell, é guardada permanentemente para esse repositório e comando. Assim, uma confirmação rápida num servidor mantém-se depois de a sessão terminar. Para regras que quer manter deliberadamente, o ficheiro de definições contém listas persistentes de permissões, confirmações e recusas. Por exemplo: permitir git status, pedir confirmação para git push e recusar leituras de .env. As regras de recusa têm sempre prioridade. Essa configuração base também mudou. O modo Auto, em que um classificador analisa as ações em vez de si, tornou-se o modo predefinido para novas sessões nos planos Pro, Max e Team em 14 August 2026. A partir do Claude Code v2.1.283, também é o modo inicial integrado para sessões interativas no terminal e no VS Code em todos os planos, exceto se tiver fixado um modo predefinido. Por isso, é importante saber o que cada modo de permissão permite realmente antes de decidir qual deve ser executado num servidor que não pode monitorizar.

Este modelo pressupõe que uma pessoa está a observar o terminal. Num portátil, isso é normalmente verdade. Num servidor, muitas vezes o objetivo é precisamente não haver ninguém a observar. Inicia uma tarefa longa dentro do tmux e vai dormir. Se um agente parar para fazer uma pergunta às 2 a.m., não haverá progresso até de manhã. A pausa custa tempo e dinheiro, porque uma sessão inativa do Claude Code perde a cache de prompts aquecida e o turno seguinte tem de a reconstruir. Essa é a razão real pela qual muitas pessoas usam a flag skip nos servidores. O problema que ela resolve é real. O restante deste guia explica como resolver esse problema sem eliminar todas as salvaguardas.

O que --dangerously-skip-permissions altera

claude --dangerously-skip-permissions desativa a etapa de aprovação. As edições são feitas sem confirmação. Os comandos shell são executados sem confirmação. As verificações de caminhos protegidos, que normalmente protegem localizações sensíveis, também são ignoradas. As suas regras explícitas de negação continuam a aplicar-se e algumas ações extremas ainda param para pedir confirmação, mas o resumo prático é simples: tudo o que o modelo decidir executar será executado.

Há dois factos importantes sobre esta flag num servidor. Primeiro, ela é bloqueada quando o Claude Code é executado como root ou através de sudo no Linux e no macOS, porque root sem confirmações pode alterar qualquer ficheiro ou serviço da máquina. O agente precisa de uma conta não privilegiada própria de qualquer forma, e a flag impõe essa condição. Segundo, a flag não altera o comportamento do modelo. Remove o ser humano do circuito e não muda mais nada, pelo que todos os erros que uma confirmação teria detetado passam agora a ser executados.

Por isso, este é o cálculo honesto. Se ignorar as permissões, a questão de segurança muda de "o agente fará algo prejudicial?" para "qual é o impacto máximo de uma ação errada?". Deixa de tentar controlar cada decisão e passa a controlar o raio de impacto. A contenção é a resposta, e pode ser aplicada em vários níveis.

A sandbox integrada do Claude Code

Antes dos níveis, saiba que o Claude Code agora inclui uma sandbox ao nível do sistema operativo para os comandos que executa. Isto elimina a maior parte das razões pelas quais as pessoas recorriam à flag de ignorar. No Linux, utiliza bubblewrap para o isolamento do sistema de ficheiros e socat para encaminhar o tráfego de rede através de um proxy. Dentro da sandbox, um comando só pode escrever no diretório do projeto e num diretório temporário da sessão. Também só pode aceder à rede através de um proxy que verifica cada domínio numa lista de permissões. Na primeira vez que um comando precisa de um domínio novo, o Claude Code pergunta-lhe. No modo automático, o classificador analisa o novo host.

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

sudo apt install bubblewrap socat

No Ubuntu 24.04 e posteriores, a política AppArmor predefinida impede que o bubblewrap crie os namespaces de utilizador necessários. O painel da sandbox informa quando falta algum componente. A documentação de sandboxing do Claude Code inclui o perfil AppArmor curto que resolve o problema.

A sandbox tem um modo de permissão automática. Os comandos executados na sandbox correm sem qualquer pedido de confirmação, porque o limite aplicado passa a fazer o trabalho que antes era feito pelo pedido. Os comandos que não podem ser executados dentro da sandbox recorrem ao fluxo normal de permissões. Assim, as ações realmente invulgares continuam a pedir confirmação. Para a maioria dos fluxos de trabalho em servidores, esta é a substituição correta da flag de ignorar. Obtém muito menos perguntas com um limite imposto pelo sistema operativo, em vez de não ter limite nenhum.

Seja claro quanto às limitações. Por predefinição, um comando executado na sandbox ainda pode ler a maior parte do sistema de ficheiros, incluindo ficheiros de credenciais, salvo se bloquear esses caminhos. A definição sandbox.credentials existe exatamente para isso. O proxy de rede verifica os nomes dos domínios, mas não inspeciona o tráfego. Por isso, uma permissão ampla como github.com ainda permite retirar dados. O Docker não funciona dentro dela. A sandbox aumenta bastante o nível mínimo de segurança. Não é um limite completo de isolamento. É por isso que os níveis abaixo continuam a ser importantes.

A escada de contenção

Três níveis, por ordem crescente de isolamento. Escolha o nível mais baixo que corresponda ao que existe no servidor.

Nível 1: um utilizador sem privilégios dedicado. O agente recebe a sua própria conta, o seu próprio diretório pessoal, o seu próprio diretório de projeto e nenhum acesso a sudo:

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

A separação por conta impede o agente de aceder aos seus ficheiros: às suas chaves SSH e a todos os outros projetos da máquina. Também permite usar a opção de ignorar, porque essa opção recusa executar como root. Este é o mesmo princípio de executar todos os serviços como utilizador sem privilégios, aplicado a um agente. O que o nível 1 não limita: a rede e tudo o que no servidor possa ser lido por qualquer utilizador.

Nível 2: um contentor. A Anthropic disponibiliza um devcontainer de referência que executa o Claude Code como utilizador não root, com regras de firewall que limitam os hosts a que o agente pode aceder. Um contentor criado por si faz o mesmo. O sistema de ficheiros fica limitado aos volumes que montar, e o tráfego de saída fica limitado ao que as regras do contentor permitem. Este é o nível intermédio adequado quando o servidor aloja outros serviços importantes. A limitação é que os contentores partilham o kernel do host, e uma montagem descuidada elimina a separação; se der /var/run/docker.sock ao contentor, ele poderá aceder ao host inteiro.

Nível 3: um VPS dedicado. O nível mais forte é também o mais simples: dê ao agente uma máquina inteira que não contenha nada importante para si. Um VPS pequeno custa alguns dólares por mês. Configure-o com o runbook dos primeiros dez minutos num VPS novo, crie um snapshot do estado limpo e deixe o agente trabalhar. Não existe mais nada nesse servidor. Não use uma chave SSH pessoal; use apenas uma deploy key limitada ao único repositório. Não inclua credenciais cloud nem dados de produção. Quando uma execução correr mal, ou quando simplesmente quiser um estado limpo, restaure o snapshot ou destrua e recrie o servidor em minutos. O raio de impacto limita-se ao custo do VPS. É neste cenário que --dangerously-skip-permissions deixa de ser assustador, porque o pior resultado realista é reconstruir o servidor e revogar um token.

Os níveis acumulam-se. Um agente em sandbox, executado como utilizador sem privilégios num VPS descartável, custa quase nada a mais e torna as falhas pouco interessantes. Esse é o objetivo.

Proteja as credenciais

A regra que sustenta todo o resto: o utilizador do agente não pode ler segredos pertencentes a qualquer outra coisa.

Forneça a chave da API ao agente e a mais ninguém. Coloque-a num ficheiro pertencente ao utilizador do agente, com o modo 600, e carregue-a quando uma shell for iniciada:

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, restrinja o acesso no sentido contrário. Em instalações antigas de Debian e Ubuntu, e para a conta criada durante a instalação, os diretórios pessoais podem ser legíveis por todos os utilizadores do sistema. Por isso, restrinja o seu próprio diretório: chmod 750 /home/youruser. Verifique com ls -ld /home/* e corrija tudo o que a conta do agente puder listar.

Defina o âmbito de cada token. Um token do GitHub com permissões granulares, limitado a um único repositório, ou uma deploy key por repositório, faz com que uma credencial exposta comprometa um projeto, e não a sua conta inteira. Se utilizar o sandbox, adicione as respetivas definições de credenciais para que ~/.ssh e ~/.aws sejam negados, mesmo em operações de leitura. Mantenha também as credenciais de produção completamente fora do sistema, porque um agente não pode expor um segredo que nunca esteve presente. Se esses segredos estiverem num gestor de palavras-passe self-hosted, mantenha-o num sistema diferente do agente e faça uma revisão própria, porque os pontos fracos do Vaultwarden são o token de administração e o ficheiro de backup, e não o cofre encriptado.

O Git é a rede de segurança

Todas as alterações que o agente confirma podem ser revistas e revertidas. O Git oferece ambas as opções sem custo adicional se o agente trabalhar numa branch e fizer commits à medida que avança:

git switch -c agent/refactor-auth

O trabalho que o agente nunca confirma não tem essa proteção. Um git reset --hard elimina as alterações não confirmadas em ficheiros monitorizados, e o Git não abrange nada que esteja fora do repositório. Reveja a execução depois de terminar com git diff main...agent/refactor-auth para ver o que foi confirmado. Em seguida, execute git status e git diff HEAD na branch para identificar o que ficou por confirmar. Faça o merge do que estiver correto e elimine a branch se a execução não produzir resultados úteis. É muito mais fácil ler ao pequeno-almoço uma execução que alterou três ficheiros do que uma que reescreveu metade do módulo. Este é o caso prático de uma skill que obriga o agente a fazer a alteração mínima que funciona. Proteja a branch principal no forge, para que o token do agente não possa fazer push para ela nem force-push para qualquer local. O histórico de commits funciona também como um log de auditoria do que aconteceu enquanto dormia. Isso vale mais do que qualquer quantidade de texto que tenha ficado no terminal.

A rede faz parte do raio de impacto

Um agente pode executar curl. Essa frase resume todo o problema do tráfego de saída: tudo o que o agente consegue ler, também consegue enviar para algum destino, e um agente com um prompt injetado pode fazê-lo. Um utilizador normal sem privilégios não limita este acesso, porque qualquer utilizador pode alcançar tudo o que o servidor consegue alcançar. O sandbox limita o acesso por domínio através do seu proxy. Um contentor pode limitá-lo com as suas próprias regras de firewall. Um VPS dedicado limita desde logo o que pode ser divulgado, sendo esta a resposta mais robusta das três.

Não tente resolver o tráfego de saída apenas com ufw. Por predefinição, o ufw permite todo o tráfego de saída, e escrever regras de saída que continuem a permitir apt, npm, git e a Claude API é um trabalho complexo que pode falhar silenciosamente. Escolha o limite ao nível do sandbox, do contentor ou da máquina. Nesse nível, uma lista de permissões de domínios ou uma máquina dedicada cumpre a mesma função de forma clara.

Se estiver a criar o seu próprio agente através da API, em vez de executar Claude Code, aplica-se exatamente o mesmo raciocínio. Criar um agente de IA com Claude num VPS aborda esse percurso, e o agente deve ter o mesmo utilizador dedicado, os mesmos tokens com escopo limitado e a mesma máquina descartável.

Primeiro, reforce a segurança do sistema

Independentemente do nível escolhido, a própria máquina ainda precisa das medidas básicas antes de instalar o agente: apenas chaves SSH, sem login de root, uma firewall com política padrão de negar e atualizações de segurança automáticas. Gere aqui a sua lista de verificação e execute cada item uma vez:

FAQ

É seguro usar --dangerously-skip-permissions num servidor?

Não por si só. A flag remove todos os pedidos de aprovação, por isso o primeiro comando incorreto é executado assim que o modelo o produz. A opção torna-se defensável quando o impacto potencial está limitado: use, no mínimo, um utilizador dedicado sem privilégios e, para tarefas realmente não supervisionadas, um contentor ou um VPS descartável que contenha apenas um projeto e um token com permissões limitadas. Nunca a use numa máquina que contenha credenciais de produção ou dados que não possa perder.

O Claude Code tem uma sandbox?

Sim. O Claude Code inclui uma sandbox integrada para comandos shell, aberta com o comando /sandbox. Usa bubblewrap no Linux e Seatbelt no macOS, limita as escritas ao diretório do projeto e encaminha o acesso à rede através de um proxy que permite apenas domínios aprovados. O modo de permissão automática executa os comandos na sandbox sem pedidos de confirmação. Assim, reduz as interrupções tal como a flag de ignorar permissões, mantendo uma fronteira imposta pelo sistema operativo. Não é uma fronteira de isolamento completa. Para execuções não supervisionadas, combine-a com um utilizador dedicado ou uma máquina dedicada.

Porque é que a flag de ignorar permissões recusa executar como root?

Porque root sem pedidos de permissão pode modificar qualquer ficheiro e qualquer serviço do sistema. Por isso, o Claude Code bloqueia --dangerously-skip-permissions quando é executado como root ou através de sudo no Linux e no macOS. A solução não é contornar a verificação. Crie um utilizador sem privilégios para o agente e execute-o nesse contexto. Essa separação por conta é a primeira camada de contenção e a mais barata.

O Claude Code pode ler as minhas chaves SSH e os ficheiros .env?

Pode ler tudo o que o utilizador com que é executado consegue ler. Além disso, a política predefinida da sandbox permite leituras de caminhos com credenciais até que as bloqueie. Execute o agente com o seu próprio utilizador, mantenha o seu diretório pessoal com permissões 750 ou mais restritivas, bloqueie os caminhos com credenciais nas definições da sandbox e mantenha os segredos de produção totalmente fora da máquina. Um segredo que nunca esteve no servidor não pode ser lido nem divulgado.

Qual é a forma mais segura de executar o Claude Code sem supervisão?

Um VPS dedicado e barato, usado apenas para trabalho do agente: protegido em dez minutos, com um snapshot limpo, o Claude Code executado por um utilizador sem privilégios e com a sandbox ativa, um ficheiro com permissões 600 para guardar a chave da API, uma chave de deploy por repositório e todo o trabalho em branches que revê antes de fazer merge. Se uma execução correr mal, revoga um token e restaura o snapshot. Nada mais do que possui é afetado.