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.

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.
• 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.

#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.

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.

#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 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.

#Que acessos dar a um agente em cada fase

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