Codex Desktop en agencias: revisión de diff, PR y publicación

Una agencia termina una landing page, el diff parece limpio y el PR no muestra errores evidentes. Sin embargo, la staging URL conserva un formulario roto, el CTA aprobado por el cliente no coincide con el diseño y nadie ha confirmado quién puede publicar. El problema no es que falte otra revisión automática: se han mezclado la revisión técnica, la aceptación del cliente y la decisión de producción.

En el trabajo diario, el diff, el PR, la staging URL y la nota de aprobación suelen vivir en pestañas distintas. Pedir a Codex que «revise todo» no evita una mala publicación si el equipo no separa esas cuatro evidencias y asigna un responsable humano a cada decisión.

Dónde suele fallar el uso de Codex en una agencia

• En este artículo, Codex Desktop es una etiqueta práctica para el trabajo con Codex en la ChatGPT desktop app, el review pane, la CLI y la extensión del IDE.
• La revisión del diff, los comentarios del PR, las pruebas en la staging URL y la aprobación de producción no deben resolverse como si fueran una sola tarea.
• Codex puede resumir cambios, ejecutar /review, enumerar riesgos y preparar propuestas de corrección; la aceptación del cliente, el precio, el texto legal, la fecha y la publicación siguen en manos de personas.
• AGENTS.md debe contener controles reales de agencia: ancho móvil, envío del formulario, CTA, OGP, tracking y rollback.
• Para valorar el flujo conviene observar retrabajo, incidentes de publicación, fallos del formulario y tiempo de revisión del cliente, no las líneas que cambió la IA.

Las referencias de base son la documentación de OpenAI sobre la ChatGPT desktop app, la revisión de código, AGENTS.md, los subagentes, las buenas prácticas y las aprobaciones y la seguridad de agentes. Para comparar este enfoque con otro circuito de publicación, consulta el flujo de aprobación con Azure DevOps para agencias.

Qué prepara Codex y qué aprueba una persona

Codex debe recibir un alcance de diff definido, la rama base, la staging URL, la URL del PR, la lista de archivos modificados, los controles humanos y una nota de rollback. No debe recibir autoridad para aprobar precios, textos legales, aceptación del cliente, momento de publicación ni acceso a producción.

La persona conserva la decisión de negocio; Codex prepara evidencias para revisarla. Esta frontera es esencial en una agencia porque un cambio técnicamente correcto aún puede incumplir el encargo, alterar una promesa comercial o publicarse en una fecha equivocada.

Área	Codex puede preparar	Una persona debe decidir o aprobar
Diff	Resumen por archivo, cambios inesperados y riesgos para revisar	Si el alcance coincide con el pedido y si un archivo debía modificarse
PR	Hallazgos de /review, propuesta de corrección y comandos de verificación	Prioridad de comentarios, cambio de diseño, horas y alcance contractual
Staging URL	Checklist basado en los requisitos y registro de evidencias aportadas	Validación visual, formulario real, tracking, enlaces, CTA y OGP
Contenido	Comparación entre texto aprobado y texto modificado	Precio, afirmaciones comerciales, texto legal y aceptación del cliente
Producción	Lista de bloqueos pendientes y nota de rollback	Go/no-go, horario, credenciales, despliegue y comunicación al cliente

No pegues secretos, credenciales ni datos personales del cliente en la tarea. Si Codex puede ejecutar comandos, limita el acceso al repositorio y al entorno que necesita, revisa las aprobaciones solicitadas y deja fuera las operaciones de producción. Un mensaje de «sin hallazgos» no reemplaza estos límites.

Flujo de trabajo antes de publicar

1. Abrir la revisión con un alcance verificable

Anota la rama base, los archivos permitidos, los archivos que no deben tocarse, la staging URL y el pedido original. git diff --stat main...HEAD sirve para detectar un alcance anómalo; git diff main...HEAD permite leer el cambio real. Si la base no es main, sustitúyela de forma explícita en ambos comandos.

2. Separar hallazgos del diff y comentarios del PR

En modo interactivo, abre /review y selecciona la revisión contra la rama base; en CLI no interactiva usa codex review --base main. Trátalo como revisión del diff, no como autorización de publicación. Registra cada hallazgo con archivo, motivo, corrección propuesta y comando de comprobación. Los comentarios del PR se tratan aparte: pueden introducir una decisión de cliente o un cambio de alcance que el diff, por sí solo, no explica.

3. Revisar la staging URL con evidencia concreta

La persona responsable abre la staging URL en los anchos acordados y comprueba navegación, CTA, OGP, formulario y tracking. La tabla de publicación debe indicar resultado, evidencia y responsable. Una captura ayuda con el diseño, pero no demuestra que el formulario haya enviado datos ni que el evento de analítica haya llegado a su destino.

4. Obtener la aceptación del cliente sin ambigüedad

La nota «se ve bien» no basta si no identifica versión, URL y puntos aceptados. Guarda la confirmación junto al PR o enlázala desde la tabla de publicación. Si después cambia el precio, un texto legal o la fecha, esa parte vuelve a revisión humana aunque el código no cambie.

5. Cerrar con go/no-go y rollback

Antes de producción, una persona confirma que no quedan bloqueos, nombra a quien despliega y comprueba que la nota de rollback corresponde a esa versión. Codex puede ordenar la información y señalar campos vacíos; no decide si el riesgo comercial es aceptable ni ejecuta la publicación por iniciativa propia.

Reglas mínimas para AGENTS.md

Un AGENTS.md útil transforma criterios repetidos en instrucciones que se pueden comprobar. No debe decir solo «revisa bien la página».

Control	Regla concreta para el repositorio
Alcance	No modificar archivos fuera de la lista aprobada; informar si hace falta ampliar el alcance
Texto	No reescribir precios, textos legales ni copy aprobado por el cliente sin revisión explícita
Responsive	Comprobar los anchos definidos por el proyecto y registrar cualquier desbordamiento
Formulario	Validar campos, estado de éxito, estado de error y destino sin usar datos reales de clientes
Marketing	Revisar CTA, OGP y tracking sin inventar identificadores ni resultados
Publicación	No tocar producción; entregar bloqueos, verificación y nota de rollback para aprobación humana

Estas reglas deben adaptarse al repositorio. Si el proyecto no usa OGP o tracking, no añadas un control ficticio; si tiene varios formularios o dominios de staging, nómbralos. La precisión evita que una regla genérica dé una falsa sensación de cobertura.

Tres casos de uso para agencias

Caso de uso 1: revisión de una landing page de campaña

Entrada: URL del PR, rama base, archivos modificados, staging URL, solicitud de cambio y nota del cliente. Salida de Codex: tabla con hallazgos de código, controles pendientes en staging y puntos que requieren aceptación. Aprobación humana: precio, copy publicitario, fecha, conformidad del cliente y publicación en producción.

Este caso evita que un cambio pequeño de copy o estilos oculte modificaciones en el formulario o en el tracking. La corrección consiste en revisar primero el alcance del diff y después recorrer la staging URL contra la versión concreta del PR.

Caso de uso 2: resolución de comentarios de un PR

Entrada: comentarios del PR, archivos y líneas afectadas, archivos que no se pueden tocar y comando de validación. Salida de Codex: un plan por comentario, lista de archivos cambiados, resultado de verificación y decisiones aún abiertas. Aprobación humana: alcance contratado, cambios de diseño, impacto en la estimación y fecha de entrega.

Codex puede preparar un parche, pero el comentario «haz el bloque más comercial» no contiene un criterio verificable. La persona responsable debe convertirlo en una instrucción concreta o pedir aclaración al cliente antes de aceptar una reescritura extensa.

Caso de uso 3: control final de la staging URL

Entrada: staging URL, anchos de viewport, ejemplo de formulario, CTA principal, tracking, nota de rollback y revisor asignado. Salida de Codex: checklist de escritorio y móvil, resultado documentado del formulario, lista de enlaces, capturas aportadas y bloqueos. Aprobación humana: cliente, horario de anuncios, dirección de contacto y go/no-go de producción.

La revisión termina cuando cada control tiene responsable y evidencia, no cuando desaparecen los comentarios del PR. Si la staging URL no corresponde al commit revisado, se detiene el proceso y se vuelve a desplegar la versión correcta.

Prompt listo para copiar

Revisa el flujo de trabajo de una agencia web antes de usar Codex Desktop.
Entradas: URL del PR, rama base, staging URL, archivos modificados, nota de aprobación del cliente, checklist de publicación y nota de rollback.
Salida:
1. Trabajo que puede hacer Codex: resumen del diff, /review, lista de riesgos, borrador de corrección y comando de verificación.
2. Trabajo que deciden las personas: precio, copy publicitario, texto legal, OK del cliente, fecha de publicación y aprobación de producción.
3. Tabla de tres columnas: correcciones del PR, controles de staging y bloqueos de producción.
4. Reglas breves para el AGENTS.md de esta agencia.
5. Una primera acción que pueda completarse en 30 minutos.
Reglas: no trates los hallazgos de la revisión como aprobación de producción. No reescribas copy aprobado por el cliente sin una revisión explícita.

El prompt organiza la revisión, pero no aporta hechos que falten. Adjunta solo información autorizada y elimina datos sensibles. Si no existe una nota de aceptación o rollback, la respuesta correcta es marcar el bloqueo, no completar el campo por inferencia.

Script de comprobación

El siguiente JavaScript valida que la ficha de publicación contenga las evidencias mínimas. Se puede copiar en un archivo local y ejecutar con node; no abre el PR, no visita staging y no publica nada.

const releaseReview = {
  project: "campaign-lp",
  headBranch: "feature/lp-copy",
  baseBranch: "main",
  diffScope: "feature/lp-copy vs main",
  reviewCommand: "codex review --base main",
  stagingUrl: "https://staging.example.com/campaign",
  pullRequestUrl: "https://github.com/example/site/pull/42",
  filesChanged: ["src/pages/campaign.astro", "src/components/LeadForm.tsx"],
  humanChecks: ["mobile layout", "form submit", "tracking tag", "client approval", "rollback note"],
  productionRequirements: ["client approval", "rollback note", "analytics check"],
  clientApprovalReference: "approval-example-001",
  rollbackPlan: "Redeploy the previous production commit, then rerun form and analytics checks.",
  releaseOwner: "human release owner",
  codexCanDo: ["summarize diff", "run review", "list risks", "draft fix prompts"],
  humanMustDecide: ["publish timing", "legal wording", "pricing claim", "production approval"]
};

const hasText = (value) => typeof value === "string" && value.trim().length > 0;
const hasChecklist = (value) =>
  Array.isArray(value) && value.length > 0 && value.every(hasText);
const expectedDiffScope = `${releaseReview.headBranch} vs ${releaseReview.baseBranch}`;
const expectedReviewCommand = `codex review --base ${releaseReview.baseBranch}`;

const required = [
  ["head branch", hasText(releaseReview.headBranch)],
  ["base branch", hasText(releaseReview.baseBranch)],
  ["diff scope matches branches", releaseReview.diffScope === expectedDiffScope],
  ["review command matches base branch", releaseReview.reviewCommand === expectedReviewCommand],
  ["staging URL", hasText(releaseReview.stagingUrl)],
  ["pull request URL", hasText(releaseReview.pullRequestUrl)],
  ["changed files", hasChecklist(releaseReview.filesChanged)],
  ["human checks", hasChecklist(releaseReview.humanChecks)],
  ["production requirements", hasChecklist(releaseReview.productionRequirements)],
  ["client approval reference", hasText(releaseReview.clientApprovalReference)],
  ["rollback plan", hasText(releaseReview.rollbackPlan)],
  ["release owner", hasText(releaseReview.releaseOwner)],
  ["production approval stays human", hasChecklist(releaseReview.humanMustDecide) && releaseReview.humanMustDecide.includes("production approval")]
];

const findings = required
  .filter(([, ok]) => !ok)
  .map(([item]) => ({ item, fix: "add this before using Codex for release review" }));

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

Una tabla vacía confirma únicamente que todos los campos requeridos existen en este ejemplo. No confirma que su contenido sea verdadero, que la staging URL funcione ni que el cliente haya aprobado la versión. Esa comprobación corresponde a los responsables indicados en la ficha.

Cómo medir si el flujo compensa

No atribuyas valor a Codex por el número de líneas modificadas. Usa datos internos de publicaciones comparables y registra: horas de retrabajo, incidentes tras publicar, formularios fallidos y tiempo hasta obtener la aceptación del cliente.

Una estimación sencilla es coste de retrabajo = horas de corrección × coste interno por hora. Compara el valor antes y después de adoptar la checklist y añade el tiempo dedicado a preparar evidencias. No prometas ahorro si la agencia todavía no tiene una línea base; primero reúne datos de sus propias entregas.

Errores frecuentes y cómo corregirlos

Error 1: interpretar /review como aprobación de producción

El primer fallo es leer una revisión sin hallazgos como un go/no-go. Corrección: nombra la salida «hallazgos del diff» y conserva una aprobación humana separada para cliente, contenido y producción.

Error 2: dejar AGENTS.md en términos vagos

El segundo fallo es escribir «revisa diseño y calidad» sin criterios. Corrección: especifica anchos móviles, envío del formulario, CTA, OGP, tracking y nota de rollback, junto con el comando o la evidencia esperada.

Error 3: editar la misma página en paralelo

El tercer fallo es repartir correcciones concurrentes sobre la misma landing page. Se pierden cambios, se contradicen decisiones o se revisa un diff distinto del publicado. Corrección: delega en subagentes las comprobaciones de lectura, como enlaces, logs y resúmenes, y devuelve las ediciones a una única tarea principal para su revisión.

Error 4: omitir la staging URL

El cuarto fallo es cerrar el PR basándose solo en código y capturas antiguas. Corrección: reúne diff del PR, staging URL, capturas actuales, resultado del formulario y nota de rollback en una sola tabla de publicación, identificando el commit revisado.

Preguntas frecuentes

¿Codex Desktop es el nombre oficial del producto?

La documentación oficial habla principalmente de ChatGPT desktop app, Codex CLI, extensión del IDE y review pane. Este artículo usa Codex Desktop como una etiqueta práctica de agencia para ese espacio de trabajo, no como un nuevo nombre oficial.

¿Una agencia debería empezar con la desktop app o con la CLI?

Los perfiles que revisan trabajo pueden empezar por el review pane de la desktop app. Quienes implementan suelen necesitar la CLI o la extensión del IDE para la verificación local. La elección depende de la tarea y de los permisos, no del cargo.

¿Basta con /review antes de publicar?

No. Ayuda a revisar el diff. La aceptación del cliente, el horario de anuncios, el precio y la aprobación de producción siguen siendo decisiones humanas.

¿Conviene usar subagentes en una agencia?

Sí, para comprobaciones centradas en lectura, como enlaces, logs y resúmenes. Evita que varios agentes editen a la vez la misma landing page y reúne las propuestas en una sola revisión antes de aplicar cambios.

Siguiente paso: formación y consultoría

Para una agencia, la mejora no consiste solo en editar más rápido, sino en reducir publicaciones que obligan a rehacer trabajo o explicar un fallo al cliente. Lleva un PR reciente, su staging URL, el AGENTS.md y la checklist actual a la formación y consultoría sobre Claude Code. El objetivo es convertir esas piezas en un flujo repetible con responsables y aprobaciones explícitas, sin prometer automatización total.

Resultado de la verificación práctica

La revisión de este artículo abarcó el manual de Codex, la documentación de la ChatGPT desktop app, revisión de código, AGENTS.md, subagentes y aprobaciones y seguridad de agentes. También se comprobaron el bloque JavaScript, el enlace interno localizado, el CTA principal, el frontmatter y el slug.

Al ejecutar el JavaScript con los datos incluidos, findings queda vacío y el proceso termina sin error porque están presentes alcance, comando, URLs, archivos, aprobación del cliente, rollback y aprobación humana de producción. Esto valida la estructura del ejemplo, no una publicación real. La primera acción aplicable es crear tres columnas separadas para revisión del diff, seguimiento del PR y aprobación de publicación.