Deixar o Claude Code ou o Codex editar o site em produção: ambiente de testes, cópias de segurança e verificações

O Claude Code, o Codex e agentes semelhantes já não se limitam a sugerir código. Executam o WP-CLI, enviam temas Shopify, editam componentes Astro e abrem pull requests sozinhos. Essa rapidez é a razão pela qual os donos de sites lhes entregam as chaves, e é também a razão pela qual um único comando errado chega aos clientes em segundos. Este guia descreve a ordem das salvaguardas que aplicamos antes de um agente tocar no site de um cliente: uma cópia onde trabalhar, um restauro que já testou, permissões impostas pela ferramenta, credenciais que não permitem mais do que a tarefa exige e verificações feitas por si.

Aplica-se ao WordPress, ao Shopify e a frontends baseados em Git, como Astro ou Next.js. Todo o comportamento de produto citado abaixo vem da documentação do próprio fabricante, consultada a 23 de outubro de 2026. As citações são tradução própria.

#Posso deixar um agente de IA editar o site em produção

Não, pelo menos não como primeiro passo. A razão é técnica, não uma questão de confiança no modelo. A documentação de permissões do Claude Code di-lo sem rodeios: “As regras de permissão são impostas pelo Claude Code, não pelo modelo.” Uma linha no CLAUDE.md ou no AGENTS.md a dizer “nunca toques em produção” orienta aquilo que o agente tenta fazer, mas não impede nenhum comando. Num servidor em produção, a shell do agente tem exatamente os direitos do utilizador SSH, do utilizador da base de dados ou do token de API.

Uma resposta num tópico do r/Wordpress sobre converter um design HTML feito por IA num tema resumiu a regra numa frase:

A IA é ótima a transformar HTML em peças de tema, mas eu não a deixaria ligar-se ao site em produção e editá-lo diretamente.

(u/eshbanbahadur2020, r/Wordpress, 23 de outubro de 2026, tradução própria)

Também o botão de anular faz menos do que parece. A página sobre checkpoints do Claude Code explica que um ficheiro alterado apenas por comandos Bash “não é registado e fica como está”, e diz que os checkpoints “não substituem o controlo de versões”. Uma execução de wp search-replace, a atualização de um plugin ou o envio de um tema acontecem totalmente fora desse histórico. Por isso, o trabalho começa longe da produção.

#Como dar ao agente uma cópia do site em vez da produção

Escolha a cópia adequada à sua plataforma.

WordPress. Um site de testes no mesmo alojamento, ou uma cópia local, com a base de dados exportada e importada através do WP-CLI. O nosso guia do fluxo de trabalho com ambiente de testes percorre a configuração completa. Há dois comandos que importam quando trabalha com agentes: wp db export grava a base de dados num ficheiro, e wp search-replace tem a opção --dry-run que, nas palavras do manual do WP-CLI, vai “executar toda a operação de pesquisa e substituição e mostrar o relatório, mas sem guardar as alterações na base de dados”. Obrigue o agente a fazer primeiro cada pesquisa e substituição em modo de ensaio e a mostrar-lhe o relatório.

Para experiências descartáveis, o Playground CLI arranca o WordPress localmente com npx @wp-playground/cli@latest server. Nesse modo guarda os ficheiros e a base de dados SQLite em pastas temporárias, pelo que nada sobrevive quando o para. O modo start mantém as alterações entre reinícios. O nosso artigo sobre WordPress Playground e MCP para agentes de IA trata o lado do agente nesta configuração.

Atualização, 4 de novembro de 2026. A equipa do Playground descreveu que o WordPress Playground consegue agora clonar um site em produção para o browser, sem servidor local. Escolhe New Playground > Clone a live site, introduz o endereço e verifica o site. O site de origem precisa do plugin Reprint ativo e é necessária uma conta de administrador. O endereço sozinho não dá acesso aos ficheiros nem à base de dados: cola a chave de migração mostrada no Playground em Tools > Reprint Server > Migration Token e seleciona Authorize client. As alterações na cópia não chegam ao site em produção e a cópia concluída fica guardada no browser. O Reprint transfere ficheiros e conteúdo da base de dados em pequenas partes e ajusta os endereços guardados do site. A importação no browser aceita atualmente até 2 GiB. O Playground executa o WordPress num ambiente diferente do seu alojamento, pelo que alguns plugins e serviços externos podem comportar-se de forma diferente; a publicação aconselha a usar estas verificações em conjunto com testes no alojamento. Para o trabalho com um agente, obtém uma cópia para uma sessão, sem servidor próprio. A publicação avisa ainda que uma cópia pode conter conteúdo privado, dados de utilizadores e credenciais de plugins, pelo que deve tratá-la como qualquer cópia de base de dados com dados de clientes e remover essa informação antes de partilhar uma exportação.

Shopify. O comando shopify theme dev carrega o seu tema local como tema de desenvolvimento e serve uma pré-visualização em http://127.0.0.1:9292. A documentação do CLI do Shopify descreve os temas de desenvolvimento como “temas temporários e ocultos” que não contam para o limite de temas e que “são eliminados da loja após sete dias de inatividade”. São também eliminados com shopify auth logout. Se precisar de uma pré-visualização que dure para a revisão do cliente, o Shopify recomenda enviar antes para um tema não publicado. Em qualquer dos casos, o agente nunca precisa de direitos de publicação no tema em produção.

Astro, Next.js e outros sites baseados em Git. O agente trabalha num ramo e o alojamento gera uma pré-visualização. No Cloudflare Pages, os URL de pré-visualização “são públicos” por omissão e cada pré-visualização envia X-Robots-Tag: noindex; o Cloudflare Access permite restringi-los à sua conta. A página de ambientes da Vercel tem um aviso que merece ser lido duas vezes: uma publicação de produção em fase de preparação usa as variáveis de ambiente de produção, “pelo que os testes podem aceder a serviços e dados de produção”. Se a pré-visualização do agente comunica com a sua base de dados real ou com as chaves de pagamento, não é um ambiente de testes.

#Como fazer uma cópia de segurança do site para poder reverter a alteração do agente

Uma cópia de segurança só conta depois de a ter restaurado. Antes de uma sessão com um agente:

• Código: faça commit ou crie uma tag do estado atual no Git. Num site WordPress sem Git, copie a pasta wp-content com a data no nome.
• Base de dados: wp db export before-agent.sql. O restauro correspondente é wp db import before-agent.sql, segundo a referência do comando import do WP-CLI.
• Sites de desenvolvimento e de testes (atualização de 24 de outubro de 2026): o plugin SnapShots, versão 3.0.0, guarda a base de dados e, por omissão, a pasta de uploads, e restaura ambas com um clique na barra de administração ou com wp snapshot restore. Plugins, temas e o núcleo ficam de fora, e os ficheiros permanecem no mesmo servidor. A página do plugin apresenta-o como ferramenta de desenvolvimento para reverter durante os testes, e não como cópia de segurança fora do servidor. Precisa do WP-CLI e da função PHP exec, que muitos alojamentos desativam. Use-o entre tentativas do agente numa cópia local ou de testes e mantenha, para a produção, a exportação acima e uma cópia de segurança noutro local.
• Shopify: duplique o tema em produção no painel de administração. Produtos, encomendas e definições alterados através da Admin API não fazem parte do tema, por isso tudo o que o agente escrever aí precisa da sua própria exportação.
• Ensaio de restauro: execute o restauro uma vez no ambiente de testes e cronometre-o. Dez minutos medidos valem mais do que um “o alojamento faz cópias de segurança” presumido.

O mesmo hábito protege as atualizações de plugins e do núcleo; o nosso artigo sobre se vale a pena atualizar o WordPress mostra como atualizar sem estragar o site.

#Posso dar a um agente de IA uma cópia da base de dados de clientes

Uma cópia de testes de uma loja WooCommerce ou Shopify é uma cópia de nomes, moradas e encomendas de clientes. Se o agente enviar o conteúdo dos ficheiros para um modelo na nuvem, esses dados saem do seu servidor. Na UE, o RGPD aplica-se a isto como a qualquer outro tratamento. O artigo 5.º, n.º 1, alínea c) exige que os dados pessoais sejam “limitados ao que é necessário relativamente às finalidades para as quais são tratados”, e o artigo 28.º, n.º 1, determina que o responsável pelo tratamento recorre “apenas a subcontratantes que apresentem garantias suficientes”. Corrigir o modelo do cabeçalho não exige clientes reais na base de dados.

Na prática: anonimize ou apague as tabelas de clientes e de encomendas na cópia antes da sessão com o agente, ou entregue-lhe uma cópia apenas com as tabelas em que a tarefa mexe. Com wp db export --tables=... e --exclude_tables=..., descritos na referência do comando export, a segunda opção resume-se a um único comando. Confronte as condições de tratamento de dados do seu fornecedor de IA com o artigo 28.º antes de lhe chegarem quaisquer dados pessoais reais.

O mesmo regulamento sustenta o ensaio de restauro da secção anterior. O artigo 32.º, n.º 1, inclui entre as medidas a ponderar “a capacidade de restabelecer a disponibilidade e o acesso aos dados pessoais de forma atempada” e “um processo para testar, apreciar e avaliar regularmente” a eficácia das medidas de segurança. Uma cópia de segurança que ninguém restaurou não cumpre nenhuma das duas.

#Como limitar o que o Claude Code ou o Codex podem fazer

As duas ferramentas têm uma camada de permissões. Use-a, mas não confie apenas nela.

O Claude Code tem modos: default (com a etiqueta Manual) pede autorização na primeira utilização de cada ferramenta, acceptEdits aceita automaticamente edições de ficheiros na pasta de trabalho, plan explora sem editar ficheiros de código, auto deixa um classificador avaliar as ações e bypassPermissions salta os pedidos de autorização. A documentação diz para usar o bypassPermissions “apenas em ambientes isolados, como contentores ou máquinas virtuais, onde o Claude Code não possa causar danos”. As regras em settings.json são verificadas por uma ordem fixa, “deny, depois ask, depois allow”, e uma regra allow não consegue abrir uma exceção numa regra deny. Um ponto de partida para um repositório WordPress:

{
  "permissions": {
    "deny": ["Read(./.env)", "Read(./wp-config.php)", "Bash(git push *)", "Bash(wp db drop *)", "Bash(ssh *)"],
    "ask": ["Bash(wp search-replace *)", "Bash(wp plugin update *)"],
    "allow": ["Bash(git diff *)", "Bash(wp plugin list *)"]
  }
}

Há um limite que convém conhecer: as regras deny de Read e Edit abrangem as ferramentas de ficheiros do Claude e comandos como cat ou sed, mas não “um script Python ou Node que abra ficheiros por conta própria”. Para uma barreira sólida à volta de dados sensíveis, a documentação remete para a sandbox.

As regras de Bash têm uma segunda falha que convém testar antes de confiar nelas. Uma regra compara o texto do comando que o Claude escreve, não o programa que é executado. A própria tabela da documentação mostra que Bash(git push *) trava git push origin main, mas não git -C . push origin main, e que Bash(rm *) não trava bash -c 'rm -rf build/'. Encare uma lista deny como uma lomba para os comandos que o agente costuma escrever e coloque o verdadeiro muro num sítio que o texto do comando não consiga contornar.

Esse muro é a sandbox. Vem desligada por omissão; liga-se com /sandbox dentro de uma sessão ou com "sandbox": {"enabled": true} no settings.json. Quem a impõe é o sistema operativo (Seatbelt no macOS, bubblewrap no Linux e no WSL2), e abrange os comandos de shell que o Claude executa “e os processos que estes iniciam”, pelo que o script Python que escapou a uma regra Read também fica lá dentro. A escrita limita-se à pasta de trabalho, às pastas adicionadas e à pasta temporária. O tráfego de rede passa por um proxy cuja lista de domínios permitidos “começa vazia”. A mesma página indica dois limites: no Windows nativo, os comandos correm sem sandbox, e os hooks, os servidores MCP locais e os comandos auxiliares correm fora da sandbox com todos os seus acessos.

Para verificações que exigem lógica, um hook PreToolUse corre antes de cada chamada a uma ferramenta e pode bloqueá-la. A página de permissões afirma que um hook não consegue afrouxar uma regra deny: uma chamada recusada por uma regra deny continua recusada mesmo que o hook devolva “allow”. Isso faz dos hooks um lugar seguro para regras próprias do projeto, como recusar qualquer comando que contenha o nome do servidor de produção.

O Codex separa a sandbox das aprovações. Segundo a página de aprovações e segurança da OpenAI, o agente “funciona com o acesso à rede desligado” por omissão, uma pasta sob controlo de versões recebe escrita no espaço de trabalho com aprovações a pedido, e uma pasta fora do controlo de versões recebe acesso read-only. O modo danger-full-access significa sem sandbox e sem aprovações; a página assinala-o como risco elevado e não recomendado. Mantenha a configuração por omissão e aprove o acesso à rede tarefa a tarefa.

As credenciais são a camada que aguenta quando tudo o resto falha. Dê ao agente um utilizador próprio da base de dados na cópia de testes e, se só precisar de analisar dados, conceda-lhe apenas SELECT, como descreve a referência de GRANT do MySQL. No Shopify, use um token de aplicação personalizada com os âmbitos de que a tarefa precisa; o Shopify nota no seu guia de âmbitos de acesso que “um âmbito de escrita inclui a leitura”, pelo que write_products já é a opção mais ampla. Revogue o token quando o trabalho terminar. A nossa auditoria de acessos remotos e chaves de API indica onde esses tokens costumam ficar esquecidos.

Atualização de 24 de outubro de 2026, um exemplo de acesso só de leitura: o servidor MCP para o Google Search Console, de código aberto (pacote open-gsc-mcp), vem com a escrita ativada. O README enumera quatro ferramentas que alteram a conta (submit_sitemap, delete_sitemap, add_site e delete_site), define GSC_ENABLE_WRITES como 1 por omissão, e o início de sessão pede à Google acesso total ao Search Console. As ferramentas estão marcadas como de escrita, mas o servidor não lhe pede confirmação; se aparece uma pergunta depende das definições de permissões do seu cliente. Se o agente só tiver de analisar cliques e pesquisas, inicie sessão com auth login --read-only ou defina GSC_ENABLE_WRITES=0, e as quatro ferramentas deixam de existir. Verifique da mesma forma o início de sessão por omissão de qualquer servidor MCP antes de o ligar.

Atualização de 6 de novembro de 2026, endereço de e-mail no cabeçalho User-Agent: a 5 de novembro, um utilizador reportou no repositório do Claude Code (issue #107757) que o agente enviava o endereço de e-mail da sua conta a sites de terceiros no cabeçalho User-Agent. Lydia Hallie, da equipa do Claude Code, explicou a causa no Hacker News: o endereço da conta foi incluído no contexto do modelo para que deixasse de inventar nomes em etiquetas @author, e quando o modelo escrevia ele próprio um comando curl, por vezes colocava esse endereço como contacto no User-Agent. A Anthropic anunciou que o endereço sai do contexto na próxima versão. Até lá, as versões 2.1.317 e posteriores trazem um módulo integrado que pede confirmação antes de uma chamada a uma ferramenta web ou de um comando do tipo curl com esse endereço. A própria equipa reconhece que o módulo não cobre scripts que o agente escreve e executa sozinho, e na mesma issue duas pessoas descrevem testes nas versões 2.1.317 e 2.1.318 (macOS e Windows) em que o módulo não travou nada. O princípio vai além deste erro: tudo o que o agente tem no contexto pode acabar num pedido enviado para fora, incluindo dados de clientes de uma cópia da base de dados. Atualize o Claude Code pelo menos para a 2.1.317 e acrescente o seu próprio hook PreToolUse que recuse comandos com o seu endereço e a palavra User-Agent (um utilizador descreve um hook assim na issue). Depois procure nos registos do seu servidor cabeçalhos User-Agent com um endereço de e-mail, para ver o que os agentes enviam para os seus sites.

#Que credenciais dar a um agente de IA no WordPress, WooCommerce, Shopify e Cloudflare

Cada plataforma permite emitir uma credencial com menos poderes do que o seu próprio acesso. Use-a e crie-a só para o agente, para a poder revogar sem ficar trancado fora do site.

No WordPress, quem limita é a função. A documentação sobre funções descreve o Administrador como alguém com acesso a todas as funcionalidades de administração de um site, e o Editor como alguém que pode publicar e gerir artigos, incluindo os de outros utilizadores. Um agente que edita conteúdo através da REST API precisa, no máximo, da função de Editor. Um agente com a palavra-passe de um Administrador tem todas as funcionalidades de administração, incluindo a instalação de plugins, e um plugin é código PHP que corre no seu servidor.

No Shopify, o CLI tem uma salvaguarda que nunca deve deixar um agente levantar. A referência do theme push diz que --allow-live é “obrigatório em ambientes não interativos quando o destino é o tema em produção”, e --publish publica o tema enviado (tradução própria). Um agente corre de forma não interativa, por isso uma regra deny para as duas opções mantém-no em temas não publicados. O comando shopify theme push --unpublished cria um novo tema não publicado e envia para ele, e é esse o destino a dar ao agente.

#Como rever as alterações feitas por um agente de IA

Leia a lista de alterações antes de qualquer coisa passar para produção. O comando git diff --stat mostra que ficheiros mudaram; um agente a quem se pediu para corrigir uma ligação no rodapé e que tocou em quarenta ficheiros fez mais alguma coisa. Depois leia o git diff completo de cada ficheiro. Esteja atento a:

• verificações desativadas: uma validação de nonce comentada, uma verificação de capacidades substituída por is_admin(), um teste apagado “porque estava a falhar”;
• novas dependências, plugins ou pacotes Composer que ninguém pediu;
• dados sensíveis ou chaves de API colados no código;
• alterações em migrações da base de dados, .htaccess, redirecionamentos ou robots.txt.

No WordPress, compare wp plugin list e wp option get active_plugins antes e depois: algumas alterações vivem na base de dados, não nos ficheiros. Para código de plugins escrito pelo agente, a nossa lista de verificação para auditar código de plugins WordPress gerado por IA percorre oito erros comuns.

#Como confirmar que a alteração do agente funciona mesmo

O agente dizer “feito, testado, está tudo a funcionar” é um relatório, não uma prova. Um teste que o agente escreveu para si próprio pode passar pela razão errada. Faça as suas próprias verificações:

Uma publicação marcada como [PROMO] no r/Wordpress, escrita pelo criador de um plugin de testes A/B que promovia competências de agente para ele, tinha como título: “O Claude tornou tão fácil alterar o meu site WordPress que deixei de verificar se as alterações funcionavam mesmo”. Uma das respostas:

‘Deixei de verificar se as minhas alterações funcionavam mesmo’ é exatamente a forma como chegámos a boa parte da confusão em que estamos agora. Confiar, claro, se se quiser, mas verificar.

(u/SoItBegins_n, r/Wordpress, 22 de outubro de 2026, tradução própria)

1. curl -sI em cada URL alterado e na página inicial: código de estado, redirecionamentos, cabeçalhos de cache.
2. O registo de erros do PHP ou a consola do navegador nessas mesmas páginas.
3. O envio real de um formulário e, numa loja, uma encomenda de teste até ao fim do checkout.
4. A página num telemóvel, e não apenas no navegador headless do agente.
5. Para alterações com impacto em SEO: o title, o canonical e a meta robots tal como são apresentados, já que os agentes editam os modelos que os geram.

Faça isto no ambiente de testes e repita em produção logo após a publicação. Se algo falhar em produção, restaure primeiro e investigue depois.

#O agente diz que funcionou, mas o site mostra outra coisa

#O agente de IA deixou código esparguete: o que fazer

Os sinais são conhecidos: a mesma função em três ficheiros, correções empilhadas sobre correções, um plugin por cada pequena funcionalidade, estilos inline porque o agente não encontrou a folha de estilos. Não peça ao mesmo agente para “limpar tudo” no site em produção; isso multiplica as alterações que vai ter de rever. Congele o estado atual no Git, liste o que o site tem de fazer e decida, área a área, se é para refatorar ou reconstruir.

Um principiante que não programava há 20 anos descreveu no r/Wordpress duas semanas com o Codex como “um ciclo de pesadelo: estragar, remendar, estragar outra vez e remendar outra vez” (tópico, 21 de outubro de 2026, tradução própria). Uma das respostas apontou a saída:

Usar o Codex para alterações pequenas e revisíveis no ambiente de testes, não para reescritas abertas do site em produção.

(u/NakanoNoNeko, r/Wordpress, 22 de outubro de 2026, tradução própria)

O nosso artigo sobre vibecoding e WordPress explica porque é que os sites feitos com IA se tornam difíceis de manter. Se preferir entregar o problema a outros, o nosso serviço de recuperação de sites feitos por IA assume o site a partir desse ponto, e um plano de manutenção mantém depois a funcionar o ambiente de testes, as cópias de segurança e as verificações de atualizações. Quando quiser agentes no seu fluxo de trabalho de forma permanente, a implementação de IA inclui a configuração de permissões, tokens e passos de revisão.

#Exemplo prático: uma sessão com um agente num site WordPress de testes

Tarefa: passar um formulário de subscrição da newsletter da barra lateral para o rodapé de um site WordPress com um tema próprio no Git. A sequência abaixo usa apenas as ferramentas descritas acima.

1. No ambiente de testes, git tag before-agent no repositório do tema e wp db export before-agent.sql para a base de dados.
2. Inicie o Claude Code no modo plan e peça um plano. Leia-o. Se, para uma alteração no rodapé, o plano mencionar plugins, a base de dados ou ficheiros fora do tema, pare e pergunte porquê.
3. Mude para acceptEdits, com as regras deny e ask indicadas antes e a sandbox ligada. O agente edita os ficheiros do tema; qualquer comando wp continua a pedir-lhe autorização.
4. Quando terminar, git diff --stat. Para esta tarefa, dois ficheiros de modelo e uma folha de estilos são plausíveis. Qualquer coisa no functions.php que registe novos scripts merece uma leitura completa.
5. Verifique pessoalmente: envie o formulário no ambiente de testes, confirme que o subscritor chega à ferramenta de envio de emails, veja o rodapé num telemóvel e procure com grep novas entradas no registo de erros do PHP.
6. Faça pessoalmente a integração e a publicação do tema. Repita as mesmas cinco verificações em produção.
7. Se algo falhar em produção: git revert da integração, ou volte a publicar a tag before-agent. A base de dados não foi tocada, por isso não precisa de restauro. Se tivesse sido, o passo seria wp db import before-agent.sql, e esse passo teria de ter funcionado antes no ambiente de testes.

O agente escreveu o código no passo 3. Todos os passos que tocaram na produção foram seus.

#Que acessos dar a um agente em cada fase

O agente escreve. A produção continua a ser um passo que dá pessoalmente.