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.

Actualización, 4 de noviembre de 2026. El equipo de Playground describió que WordPress Playground ahora puede clonar un sitio en producción en el navegador, sin servidor local. Eliges New Playground > Clone a live site, introduces la dirección y compruebas el sitio. El sitio de origen necesita el plugin Reprint activo y tú necesitas una cuenta de administrador. La dirección por sí sola no da acceso a los archivos ni a la base de datos: pegas la clave de migración que muestra Playground en Tools > Reprint Server > Migration Token y eliges Authorize client. Los cambios en la copia no llegan al sitio en producción, y la copia terminada se guarda en el navegador. Reprint transfiere archivos y contenido de la base de datos en partes pequeñas y ajusta las direcciones guardadas del sitio. La importación en el navegador acepta actualmente hasta 2 GiB. Playground ejecuta WordPress en un entorno distinto al de tu hosting, así que algunos plugins y servicios externos pueden comportarse de otra manera; la publicación aconseja combinar estas comprobaciones con pruebas en tu hosting. Para trabajar con un agente, es una copia para una sesión, sin servidor propio. La publicación también advierte de que una copia puede contener contenido privado, datos de usuarios y credenciales de plugins, así que trátala como cualquier copia de base de datos con datos de clientes y elimina esa información antes de compartir una exportación.

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.
• Webs de desarrollo y de pruebas (actualización del 24 de octubre de 2026): el plugin SnapShots, versión 3.0.0, guarda la base de datos y, por defecto, la carpeta de uploads, y restaura ambas con un clic desde la barra de administración o con wp snapshot restore. Los plugins, los temas y el núcleo no entran en la instantánea, y los archivos se quedan en el mismo servidor. La página del plugin lo presenta como herramienta de desarrollo para deshacer cambios mientras pruebas, no como copia fuera del servidor. Necesita WP-CLI y la función PHP exec, que muchos alojamientos desactivan. Úsalo entre intentos del agente en una copia local o de pruebas, y para producción guarda la exportación de arriba y una copia en otro sitio.
• 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.

#¿Puedo pasarle a un agente de IA una copia con los datos de mis clientes?

Una copia de pruebas de una tienda WooCommerce o Shopify es una copia de nombres, direcciones y pedidos de clientes. Si el agente envía el contenido de los archivos a un modelo en la nube, esos datos salen de tu servidor. En la UE, el RGPD se aplica a esto como a cualquier otro tratamiento. El artículo 5, apartado 1, letra c) exige que los datos personales sean “limitados a lo necesario en relación con los fines para los que son tratados”, y el artículo 28, apartado 1, obliga al responsable a elegir “únicamente un encargado que ofrezca garantías suficientes”. Para arreglar la plantilla de la cabecera no hacen falta clientes reales en la base de datos.

En la práctica: anonimiza o vacía las tablas de clientes y pedidos en la copia antes de la sesión con el agente, o entrégale una copia que solo contenga las tablas que toca la tarea. Con wp db export --tables=... y --exclude_tables=..., descritos en la referencia de exportación, la segunda opción cabe en un solo comando. Antes de que ningún dato personal real llegue a tu proveedor de IA, contrasta sus condiciones de tratamiento de datos con el artículo 28.

El mismo reglamento respalda el simulacro de restauración de la sección anterior. Entre las medidas que el artículo 32, apartado 1, pide tener en cuenta están “la capacidad de restaurar la disponibilidad y el acceso a los datos personales de forma rápida” y “un proceso de verificación, evaluación y valoración regulares” de las medidas de seguridad. Una copia de seguridad que nadie ha restaurado no cumple ninguna de las dos.

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

Las reglas de Bash tienen un segundo hueco que conviene probar antes de fiarse de ellas. Una regla compara el texto del comando que escribe Claude, no el programa que acaba ejecutándose. La propia tabla de la documentación muestra que Bash(git push *) frena git push origin main pero no git -C . push origin main, y que Bash(rm *) no frena bash -c 'rm -rf build/'. Trata una lista deny como un reductor de velocidad para los comandos que el agente suele escribir, y levanta el muro de verdad en un sitio que el texto del comando no pueda esquivar.

Ese muro es el sandbox. Viene desactivado por defecto; lo activas con /sandbox dentro de una sesión o con "sandbox": {"enabled": true} en settings.json. Lo impone el sistema operativo (Seatbelt en macOS, bubblewrap en Linux y WSL2) y cubre los comandos de terminal que lanza Claude “y los procesos que estos inician”, de modo que el script de Python que se colaba por delante de una regla Read también queda dentro. La escritura se limita al directorio de trabajo, a los directorios añadidos y al directorio temporal. El tráfico de red pasa por un proxy cuya lista de dominios permitidos “empieza vacía” (traducción propia). La misma página señala dos límites: en Windows nativo los comandos se ejecutan sin sandbox, y los hooks, los servidores MCP locales y los comandos auxiliares funcionan fuera de él con todos tus permisos.

Para comprobaciones que necesitan lógica, un hook PreToolUse se ejecuta antes de cada llamada a una herramienta y puede bloquearla. La página de permisos aclara que un hook no puede suavizar una regla deny: una llamada que una regla deny rechaza sigue rechazada aunque el hook devuelva “allow”. Por eso los hooks son un buen lugar para reglas propias del proyecto, como rechazar cualquier comando que contenga el nombre del servidor de producción.

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.

Actualización del 24 de octubre de 2026, un ejemplo de acceso de solo lectura: el servidor MCP para Google Search Console, de código abierto (paquete open-gsc-mcp), viene con la escritura activada. Su README enumera cuatro herramientas que modifican la cuenta (submit_sitemap, delete_sitemap, add_site y delete_site), fija GSC_ENABLE_WRITES en 1 por defecto, y el inicio de sesión pide a Google acceso completo a Search Console. Las herramientas están marcadas como de escritura, pero el servidor no te pregunta antes de usarlas; que veas una confirmación depende de los permisos de tu cliente. Si el agente solo va a analizar clics y consultas, inicia sesión con auth login --read-only o pon GSC_ENABLE_WRITES=0, y esas cuatro herramientas desaparecen. Revisa igual el inicio de sesión por defecto de cualquier servidor MCP antes de conectarlo.

Actualización del 6 de noviembre de 2026, una dirección de correo en la cabecera User-Agent: el 5 de noviembre un usuario informó en el repositorio de Claude Code (issue #107757) de que el agente enviaba la dirección de correo de su cuenta a sitios de terceros en la cabecera User-Agent. Lydia Hallie, del equipo de Claude Code, explicó la causa en Hacker News: la dirección de la cuenta se añadió al contexto del modelo para que dejara de inventar nombres en las etiquetas @author, y cuando el modelo escribía por su cuenta un comando curl, a veces ponía esa dirección como contacto en el User-Agent. Anthropic anuncia que la dirección saldrá del contexto en la próxima versión. Hasta entonces, la 2.1.317 y posteriores incluyen un módulo integrado que pide confirmación antes de una llamada a una herramienta web o de un comando tipo curl con esa dirección. El propio equipo admite que no cubre los scripts que el agente escribe y ejecuta solo, y en la misma issue dos personas describen pruebas con 2.1.317 y 2.1.318 (macOS y Windows) en las que el módulo no frenó nada. El principio va más allá de este fallo: todo lo que el agente tiene en el contexto puede acabar en una petición saliente, también los datos de clientes de una copia de la base de datos. Actualiza Claude Code al menos a la 2.1.317 y añade tu propio hook PreToolUse que rechace los comandos con tu dirección y la palabra User-Agent (un usuario describe un hook así en la issue). Después busca en los registros de tu servidor cabeceras User-Agent con una dirección de correo y verás qué envían los agentes a tus sitios.

#Qué credenciales dar a un agente de IA en WordPress, WooCommerce, Shopify y Cloudflare

Cada plataforma permite emitir una credencial que hace menos que tu propio inicio de sesión. Úsala y créala solo para el agente, así puedes revocarla sin dejarte a ti mismo fuera.

En WordPress, quien pone el límite es el rol. La documentación de roles describe al administrador como alguien con acceso a todas las funciones de administración de un sitio, y al editor como alguien que puede publicar y gestionar entradas, también las de otros usuarios. Un agente que edita contenido a través de la REST API necesita, como mucho, el rol de editor. Un agente con la contraseña de un administrador tiene todas las funciones de administración, incluida la instalación de plugins, y un plugin es código PHP que se ejecuta en tu servidor.

En Shopify, la CLI tiene un seguro que nunca deberías dejar que un agente quite. La referencia de theme push indica que --allow-live es “obligatoria en entornos no interactivos cuando el destino es el tema activo”, y --publish convierte en activo el tema subido (traducción propia). Un agente trabaja de forma no interactiva, así que una regla deny para ambas opciones lo mantiene en temas sin publicar. shopify theme push --unpublished crea un tema nuevo sin publicar y sube el trabajo a él: ese es el destino que conviene darle al agente.

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

#Por qué el agente dice que funciona y la web no

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

#Ejemplo paso a paso: una sesión con un agente en un WordPress de pruebas

Tarea: mover un formulario de suscripción al boletín de la barra lateral al pie de página, en un WordPress con un tema propio en Git. La secuencia usa solo las herramientas descritas más arriba.

1. En el entorno de pruebas, git tag before-agent en el repositorio del tema y wp db export before-agent.sql para la base de datos.
2. Arranca Claude Code en modo plan y pide un plan. Léelo. Si para un cambio en el pie de página el plan menciona plugins, la base de datos o archivos fuera del tema, para y pregunta por qué.
3. Cambia a acceptEdits con las reglas deny y ask de antes y el sandbox activado. El agente edita los archivos del tema; cualquier comando wp te sigue pidiendo confirmación.
4. Cuando termine, git diff --stat. Dos archivos de plantilla y una hoja de estilos son razonables para esta tarea. Cualquier cosa en functions.php que registre scripts nuevos se lee entera.
5. Compruébalo tú: envía el formulario en el entorno de pruebas, confirma que el suscriptor llega a la herramienta de correo, mira el pie de página en un móvil y busca con grep entradas nuevas en el registro de errores de PHP.
6. Fusiona y despliega el tema tú mismo. Repite las mismas cinco comprobaciones en producción.
7. Si algo falla en producción: git revert de la fusión o vuelve a desplegar la etiqueta before-agent. La base de datos no se tocó, así que no hay nada que restaurar. Si se hubiera tocado, el paso sería wp db import before-agent.sql, y antes tendría que haber funcionado en el entorno de pruebas.

El agente escribió el código en el paso 3. Todos los pasos que tocaron producción los diste tú.

#Qué acceso dar al agente en cada fase

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