Dejar que Claude Code o Codex editen tu web en producción: entorno de pruebas, copias y comprobaciones

Claude Code, Codex y otros agentes parecidos ya no se limitan a sugerir código. Ejecutan WP-CLI, suben temas de Shopify, editan componentes de Astro y abren pull requests por su cuenta. Esa rapidez es la razón por la que los propietarios de webs les dan las llaves, y también la razón por la que un solo comando equivocado llega a los clientes en cuestión de segundos. Esta guía recoge, en orden, las protecciones que aplicamos antes de que un agente toque la web de un cliente: una copia sobre la que trabajar, una restauración que ya has probado, permisos que impone la propia herramienta, credenciales que no permiten más de lo que exige la tarea y comprobaciones que haces tú.

Sirve para WordPress, Shopify y frontends basados en Git como Astro o Next.js. Todo comportamiento de producto citado aquí procede de la documentación oficial de cada fabricante, consultada el 23 de octubre de 2026. Las citas son traducción propia.

#¿Es seguro dejar que un agente de IA edite la web en producción?

No, al menos no como primer paso. El motivo es técnico, no una cuestión de confianza en el modelo. La documentación de permisos de Claude Code lo dice sin rodeos: “Las reglas de permisos las aplica Claude Code, no el modelo”. Una línea en CLAUDE.md o AGENTS.md que diga “no toques nunca producción” orienta lo que el agente intenta hacer, pero no detiene ningún comando. En un servidor en producción, la terminal del agente tiene exactamente los derechos que tenga el usuario SSH, el usuario de la base de datos o el token de la API.

Una respuesta en un hilo de r/Wordpress sobre convertir un diseño HTML hecho con IA en un tema resumió la regla en una frase:

La IA es genial para convertir tu HTML en piezas del tema, pero yo no la dejaría conectarse a tu web en producción y editarla directamente.

(u/eshbanbahadur2020, r/Wordpress, 23 de octubre de 2026, traducción propia)

El botón de deshacer también cubre menos de lo que parece. La página sobre puntos de control de Claude Code indica que un archivo modificado solo por comandos de Bash “no se registra y se queda como está”, y añade que los puntos de control “no sustituyen al control de versiones”. Un wp search-replace, la actualización de un plugin o la subida de un tema ocurren completamente fuera de ese historial. Por eso todo el proceso empieza lejos de producción.

#Cómo trabajar con una copia de la web en lugar de producción

Elige la copia que corresponda a tu plataforma.

WordPress. Un entorno de pruebas en el mismo alojamiento o una copia local, con la base de datos exportada e importada mediante WP-CLI. Nuestra guía del flujo de trabajo con entorno de pruebas explica la configuración completa. Para los agentes importan dos comandos: wp db export guarda la base de datos en un archivo, y wp search-replace tiene la opción --dry-run que, según el manual de WP-CLI, “ejecuta toda la operación de búsqueda y sustitución y muestra el informe, pero no guarda los cambios en la base de datos”. Haz que el agente lance cada search-replace primero en modo de prueba y te enseñe el informe.

Para experimentos desechables, Playground CLI arranca WordPress en local con npx @wp-playground/cli@latest server. En ese modo guarda los archivos y la base de datos SQLite en directorios temporales, así que nada sobrevive cuando lo detienes. El modo start, en cambio, conserva los cambios entre reinicios.

Shopify. shopify theme dev sube tu tema local como tema de desarrollo y sirve una vista previa en http://127.0.0.1:9292. La documentación de la CLI de Shopify describe los temas de desarrollo como “temas temporales y ocultos” que no cuentan para tu límite de temas y que “se eliminan de la tienda tras siete días de inactividad”. También se borran al ejecutar shopify auth logout. Si necesitas una vista previa que dure lo suficiente para que el cliente la revise, Shopify recomienda subir el trabajo a un tema sin publicar. En ambos casos, el agente nunca necesita permiso para publicar en el tema activo.

Astro, Next.js y otras webs basadas en Git. El agente trabaja en una rama y el alojamiento genera una vista previa. En Cloudflare Pages, las URL de vista previa “son públicas” por defecto y cada una envía X-Robots-Tag: noindex; con Cloudflare Access puedes restringirlas a tu cuenta. La página de entornos de Vercel incluye una advertencia que merece una segunda lectura: un despliegue de producción preparado usa las variables de entorno de producción, “de modo que las pruebas pueden acceder a servicios y datos de producción”. Si la vista previa del agente se conecta a tu base de datos real o a tus claves de pago, no es un entorno de pruebas.

#Cómo hacer una copia de seguridad para poder deshacer lo que haga el agente

Una copia de seguridad solo cuenta cuando ya la has restaurado. Antes de una sesión con el agente:

• Código: confirma o etiqueta el estado actual en Git. En un WordPress sin Git, copia wp-content en una carpeta con la fecha en el nombre.
• Base de datos: wp db export before-agent.sql. La restauración correspondiente es wp db import before-agent.sql, según la referencia de importación de WP-CLI.
• Shopify: duplica el tema activo desde el panel de administración. Los productos, pedidos y ajustes modificados a través de la Admin API no forman parte del tema, así que todo lo que el agente escriba ahí necesita su propia exportación.
• Simulacro de restauración: ejecuta la restauración una vez en el entorno de pruebas y cronométrala. Diez minutos medidos valen más que un “el alojamiento ya guarda copias” dado por supuesto.

El mismo hábito protege las actualizaciones de plugins y del núcleo; nuestro artículo sobre si merece la pena actualizar WordPress explica cómo actualizar sin romper la web.

#Cómo limitar los permisos de Claude Code o Codex

Las dos herramientas tienen una capa de permisos. Úsala, pero no confíes solo en ella.

Claude Code funciona por modos: default (con la etiqueta Manual) pide confirmación la primera vez que usa cada herramienta, acceptEdits acepta automáticamente las ediciones de archivos en el directorio de trabajo, plan explora sin editar archivos de código, auto deja que un clasificador revise las acciones y bypassPermissions se salta las confirmaciones. La documentación recomienda usar bypassPermissions “solo en entornos aislados, como contenedores o máquinas virtuales, donde Claude Code no pueda causar daños”. Las reglas de settings.json se comprueban en un orden fijo, “deny, luego ask, luego allow”, y una regla allow no puede abrir una excepción dentro de una regla deny. Un punto de partida para un repositorio de 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 *)"]
  }
}

Hay un límite que conviene conocer: las reglas deny de Read y Edit cubren las herramientas de archivos de Claude y comandos como cat o sed, pero no “un script de Python o Node que abra archivos por su cuenta”. Para un muro firme alrededor de los secretos, la documentación remite al sandbox.

Codex separa el sandbox de las aprobaciones. Según la página de aprobaciones y seguridad de OpenAI, el agente “se ejecuta con el acceso a la red desactivado” por defecto, una carpeta bajo control de versiones recibe escritura en el espacio de trabajo con aprobaciones a petición, y una carpeta fuera del control de versiones recibe solo lectura. danger-full-access significa sin sandbox y sin aprobaciones; la página lo marca como riesgo elevado y no recomendado. Mantén la configuración por defecto y aprueba el acceso a la red tarea a tarea.

Las credenciales son la capa que aguanta cuando todo lo demás falla. Dale al agente su propio usuario de base de datos en la copia de pruebas y, si solo tiene que analizar datos, concédele únicamente SELECT, como describe la referencia de GRANT de MySQL. En Shopify, un token de app personalizada con los permisos que necesite la tarea; Shopify advierte en su guía de permisos de acceso que “un permiso de escritura incluye el de lectura”, así que write_products ya es la opción amplia. Revoca el token cuando termine el trabajo. Nuestra auditoría de accesos remotos y claves API enumera dónde suelen esconderse esos tokens.

#Cómo revisar los cambios que ha hecho un agente de IA

Lee los cambios antes de que nada pase a producción. git diff --stat muestra qué archivos han cambiado; si un agente al que pediste arreglar un enlace del pie de página ha tocado cuarenta archivos, ha hecho algo más. Después lee el git diff completo de cada archivo. Fíjate en:

• comprobaciones desactivadas: una verificación de nonce comentada, una comprobación de capacidades sustituida por is_admin(), un test borrado “porque fallaba”;
• dependencias, plugins o paquetes de Composer nuevos que nadie ha pedido;
• secretos o claves API pegados en el código;
• cambios en migraciones de base de datos, .htaccess, redirecciones o robots.txt.

En WordPress, compara wp plugin list y wp option get active_plugins antes y después: algunos cambios viven en la base de datos, no en los archivos. Si el agente ha escrito código de plugin, nuestra lista de auditoría para código de plugins de WordPress generado por IA repasa ocho errores habituales.

#Cómo comprobar que el cambio del agente funciona de verdad

Que el agente diga “hecho, probado, todo funciona” es un informe, no una prueba. Una comprobación que el agente ha escrito para sí mismo puede pasar por el motivo equivocado. Haz las tuyas:

Una publicación etiquetada como [PROMO] en r/Wordpress, escrita por el creador de un plugin de tests A/B que promocionaba habilidades para agentes basadas en él, llevaba este título: “Claude me ha puesto tan fácil cambiar mi web de WordPress que dejé de comprobar si los cambios funcionaban de verdad”. Una de las respuestas:

‘Dejé de comprobar si mis cambios funcionaban de verdad’ es justo como hemos acabado en buena parte del lío en el que estamos ahora mismo. Confía, vale, si quieres, pero verifica.

(u/SoItBegins_n, r/Wordpress, 22 de octubre de 2026, traducción propia)

1. curl -sI en cada URL modificada y en la página de inicio: código de estado, redirecciones, cabeceras de caché.
2. El registro de errores de PHP o la consola del navegador en esas mismas páginas.
3. Un envío real de formulario y, en una tienda, un pedido de prueba hasta el final del proceso de pago.
4. La página en un móvil, no solo en el navegador sin interfaz del agente.
5. En cambios que afectan al SEO: el título renderizado, la canonical y la meta robots, porque los agentes editan las plantillas que los generan.

Hazlo en el entorno de pruebas y repítelo en producción justo después de publicar. Si algo falla en producción, primero restaura y después investiga.

#Qué hacer si el agente de IA ha dejado código espagueti

Las señales son conocidas: la misma función en tres archivos, parches sobre parches, un plugin para cada pequeña funcionalidad, estilos en línea porque el agente no encontró la hoja de estilos. No le pidas al mismo agente que “lo limpie todo” en la web en producción; eso multiplica los cambios que tendrás que revisar. Congela el estado actual en Git, haz una lista de lo que la web tiene que hacer y decide, área por área, si refactorizar o rehacer.

Un principiante que llevaba 20 años sin programar describió en r/Wordpress dos semanas con Codex como “un bucle de pesadilla: romper, parchear, volver a romper y volver a parchear” (hilo, 21 de octubre de 2026, traducción propia). Una de las respuestas señaló la salida:

Usa Codex para cambios pequeños y revisables en el entorno de pruebas, no para reescrituras abiertas de la web en producción.

(u/NakanoNoNeko, r/Wordpress, 22 de octubre de 2026, traducción propia)

Si prefieres delegarlo, nuestro servicio de rescate de webs hechas con IA se hace cargo de la web a partir de ese punto, y un plan de mantenimiento mantiene en marcha el entorno de pruebas, las copias de seguridad y la revisión de actualizaciones después. Si quieres incorporar agentes a tu forma de trabajar de forma permanente, la implementación de IA incluye la configuración de permisos, tokens y pasos de revisión.

#Qué acceso dar al agente en cada fase

El agente escribe. El paso a producción lo das tú.