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

Por predefinição, o Claude Code pede confirmação antes de agir. A leitura de ficheiros dentro do projeto ocorre sem confirmação, 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 resposta afirmativa. Pode aprovar uma ação ou aprovar esse tipo de ação para o resto da sessão. Essas aprovações aplicam-se à sessão: saia da CLI e a sessão seguinte volta a iniciar com uma postura cautelosa. Para regras que pretende manter, o ficheiro de definições contém listas persistentes de permissões, confirmações e bloqueios. Por exemplo: permitir git status, pedir confirmação para git push e bloquear leituras de .env. As regras de bloqueio têm sempre prioridade. Essa configuração base também está a mudar, porque o modo automático passa a ser a predefinição em 14 August 2026. Por isso, é importante saber o que cada modo de permissão permite efetivamente antes de decidir qual deve ser executado num servidor que não pode monitorizar.

Este modelo pressupõe que uma pessoa está a acompanhar o terminal. Num portátil, isso é normalmente verdade. Num servidor, muitas vezes, o objetivo é precisamente não haver ninguém a acompanhar. 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 a interação seguinte tem de a reconstruir. Essa é a razão real pela qual as pessoas usam a flag de skip nos servidores, e o problema que ela resolve é real. O resto deste guia explica como resolver o problema sem abdicar de 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.

O sandbox integrado do Claude Code

Antes dos níveis, saiba que o Claude Code agora inclui um sandbox ao nível do sistema operativo para os comandos que executa. Isso elimina a maioria das razões que levavam as pessoas a usar a opção skip. No Linux, utiliza bubblewrap para isolar o sistema de ficheiros e socat para encaminhar o tráfego de rede através de um proxy. Dentro do 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 quiser aceder a um domínio novo, o Claude Code pergunta-lhe.

Ative-o 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 o bubblewrap de criar os namespaces de utilizador necessários. O painel do sandbox informa quando falta alguma coisa, e a documentação sobre o sandbox do Claude Code inclui o perfil AppArmor curto que corrige o problema.

O sandbox tem um modo de permissão automática: os comandos executados no sandbox correm sem pedir confirmação, porque a fronteira aplicada pelo sistema operativo passou a desempenhar a função que antes cabia à confirmação. Os comandos que não podem ser executados dentro do sandbox seguem o fluxo normal de permissões. Assim, as ações realmente fora do comum continuam a pedir confirmação. Para a maioria dos fluxos de trabalho em servidores, esta é a substituição correta da opção skip, porque reduz muito o número de perguntas sem eliminar a fronteira imposta pelo sistema operativo.

Seja claro sobre as limitações. Por predefinição, um comando no sandbox ainda pode ler a maior parte do sistema de ficheiros, incluindo ficheiros com credenciais, a menos que negue o acesso a esses caminhos. A definição sandbox.credentials existe precisamente para isso. O proxy de rede verifica os nomes dos domínios, mas não inspeciona o tráfego. Por isso, uma permissão abrangente como github.com ainda permite extrair dados. O Docker não funciona dentro do sandbox. O sandbox aumenta bastante o nível mínimo de segurança. Não é uma fronteira completa 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 outro componente.

Dê 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, feche o acesso no sentido contrário. Em Debian e Ubuntu, os diretórios pessoais são frequentemente criados com permissões de leitura para 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 conseguir 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 específica por repositório, significa que uma credencial exposta compromete um projeto, não a conta inteira. Se utilizar a sandbox, adicione as definições das credenciais para que ~/.ssh e ~/.aws sejam negados até mesmo para leituras. Mantenha também as credenciais de produção completamente fora deste sistema, porque um agente não consegue expor um segredo que nunca esteve presente. Se esses segredos estiverem num gestor de palavras-passe self-hosted, mantenha-o num sistema diferente daquele onde o agente executa e faça uma revisão própria, porque os pontos fracos do Vaultwarden são o token de administrador e o ficheiro de backup, não o vault cifrado em si.

O Git é a rede de segurança

Todas as alterações feitas pelo agente devem poder ser revistas e revertidas. O Git oferece ambas as capacidades sem custo adicional quando o agente trabalha numa branch:

git switch -c agent/refactor-auth

Reveja a execução depois com git diff main...agent/refactor-auth, faça merge do que estiver correto e elimine a branch se a execução não tiver produzido nada útil. Uma execução que alterou três ficheiros é muito mais fácil de ler ao pequeno-almoço do que uma que reescreveu metade do módulo. Este é o caso prático de uma skill que obriga o agente a fazer a menor alteração 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 destino. O histórico de commits também funciona como um registo de auditoria do que aconteceu enquanto dormia. Isso vale mais do que qualquer quantidade de saída acumulada 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.