Integración con Git y GitHub: cómo hacer que Codex actúe como revisor en tus PR

📚 Navegación de la serie: El artículo anterior 25 · Aislamiento en paralelo con Worktrees le enseñó cómo usar git worktree para abrir "carriles paralelos" independientes para Codex, ejecutando varias tareas al mismo tiempo sin mezclarse. Este artículo traslada el campo de batalla de su terminal local al repositorio de GitHub: cómo permitir que Codex entre en sus Pull Requests, revise automáticamente el código, busque fallos de acuerdo con las reglas establecidas por usted y envíe las correcciones directamente a la rama. El siguiente artículo 27 · Automatización y CI/CD llevará esto a las canalizaciones de CI para lograr un funcionamiento "sin supervisión".

Hablemos de un escenario que ocurre casi todos los días en el trabajo en equipo. Desde que se abre un PR hasta que se fusiona (merge), gran parte del tiempo no se gasta en la revisión en sí, sino en "esperar a que alguien revise"; el equipo es pequeño, los revisores están ocupados y su PR se queda ahí colgado, a menudo durante todo un día.

Y cuando finalmente llega el momento de la revisión, lo que los humanos suelen detectar son cosas superficiales como "este nombre de variable no es bueno" o "falta un espacio aquí". Sin embargo, los fallos realmente críticos —condiciones de carrera bajo concurrencia, middleware de autenticación omitido, escritura de datos privados del usuario en los registros— se pasan por alto fácilmente debido al cansancio, la molestia o la distracción al leer solo tres archivos.

La integración con GitHub de Codex está pensada justamente para esto: menciónelo con un @ en los comentarios del PR y, como un compañero que nunca se cansa, escaneará las diferencias (diff), detectará riesgos de alta prioridad según las reglas definidas en su repositorio y los publicará en el PR. No tiene que salir de GitHub, y él no le quitará la acción final de "fusionar": él se encarga de la revisión y usted de pulsar el botón de aprobación. Esta línea es la misma que hemos venido defendiendo desde el artículo sobre permisos [15].

Al terminar de leer este artículo, obtendrás:

• Cómo una simple mención @codex review activa la revisión en un PR, qué responderá y qué nivel de problemas seleccionará (P0/P1, según los criterios oficiales)
• Cómo habilitar la "revisión automática": revisión automática de cada nuevo PR en cuanto se abre, sin necesidad de mencionarlo manualmente con un @
• Cómo usar Review guidelines en AGENTS.md para personalizar las reglas de revisión: no registrar ciertos datos, requerir autenticación en cada ruta... deje que busque fallos según sus propios estándares
• Cómo usar @codex fix para que corrija directamente los problemas tras revisarlos, los envíe de vuelta a la rama y los límites de permisos detrás de esta acción
• Una función local /review: autoevaluación en la terminal antes de abrir un PR, sin tocar una sola línea de código de su espacio de trabajo
• Una línea directriz en todo el artículo: qué delegar con confianza y qué límites de "envío al repositorio" debe proteger usted mismo

⚠️ La revisión activada por GitHub descrita en este artículo (@codex review, revisión automática) depende de Codex cloud, por lo que requiere un plan de pago y haber autorizado el repositorio; el comando local /review no requiere cloud. Explicaré claramente ambas opciones por separado, no las confunda.

---

01 Primero distinga dos opciones: Codex en GitHub y Codex en su terminal

Antes de empezar, aclaremos la confusión más común: Codex le ayuda a revisar código mediante dos flujos completamente diferentes en dos lugares distintos.

Analogía: El mismo profesor que puede calificar la tarea que usted entrega o sentarse a su lado a observar mientras resuelve un problema. En un caso, "usted termina de escribir, lo entrega y él lo califica después"; en el otro, "usted todavía está escribiendo y él lo mira en el acto". Ambas cosas las hace el mismo profesor, pero el escenario, los permisos y quién empieza primero son completamente diferentes.

En Codex, estas dos opciones son:

Opción 1: Activación desde GitHub (cloud). Escribe @codex review en los comentarios de un PR de GitHub, Codex inicia una tarea en la nube, lee las diferencias (diff) de ese PR y publica una revisión en el PR como si fuera un revisor humano. Todo el proceso ocurre en GitHub, y el trabajo se ejecuta en los servidores en la nube de OpenAI (esto es el Codex cloud mencionado en el artículo [10 Cloud]). Requisito: el repositorio debe estar conectado a Codex cloud y la opción Code review debe estar activada en la configuración para ese repositorio.

Opción 2: /review local (CLI). Escribe /review en la sesión de Codex en su terminal, se inicia un revisor dedicado en su máquina, lee el bloque de diferencias seleccionado (cambios sin confirmar, diferencias con alguna rama, una confirmación específica...) y le enumera los problemas encontrados. Solo lee, no escribe: no tocará ninguna línea de código en su espacio de trabajo. No se conecta a GitHub, no requiere cloud, es puramente local.

Dimensión	@codex review activado en GitHub	/review local
Dónde se activa	En los comentarios de un PR de GitHub	En la sesión de Codex de la terminal
Dónde se ejecuta	Codex cloud (nube)	Su máquina local
Qué revisa	Las diferencias (diff) del PR	Las diferencias seleccionadas (sin confirmar / comparadas con rama / commit específico)
Dónde se guarda	Como comentarios de revisión en el PR	Se enumeran en el panel de revisión de la terminal
Requisitos	Conexión cloud + activar la opción Code review	Ninguno, uso inmediato local
¿Modifica código?	No (a menos que use @codex fix)	De ninguna manera, es puramente de lectura

Este artículo se centrará en la Opción 1 (Activada en GitHub), ya que es el núcleo de la "integración con Git y GitHub"; la Opción 2 /review se detalla en la sección 06 como un paso de "autoevaluación" muy útil antes de abrir un PR.

💡 Resumen en una frase: Codex ofrece dos opciones de revisión: @codex review en GitHub se ejecuta en la nube y publica comentarios en el PR (requiere cloud y activar la opción); /review en la terminal se ejecuta localmente y es puramente de lectura (no requiere nada más). Este artículo trata principalmente de la primera, siendo la segunda una autoevaluación antes de abrir PR.

---

02 Escribir @codex review: hacer que busque fallos en el PR

El uso principal se resume en una línea: escriba @codex review en el cuadro de comentarios del PR y pulse Enter.

¿Por qué vale la pena dejar esto en sus manos? Porque "revisar minuciosamente un PR" es una tarea típica que agota mentalmente y se pospone con facilidad. Cuando la gente está ocupada, su PR se queda en cola esperando revisión hasta el final del día; y cuando finalmente se revisa, la atención empieza a dispersarse tras leer un par de archivos. Este tipo de tareas "importantes pero agotadoras" son precisamente las que debe filtrar primero un compañero que nunca se cansa.

Analogía: El editor de "errores graves" al que acude antes de publicar. Cuando termina de escribir un borrador, no detecta los errores aunque lo lea tres veces, porque su cerebro autocompleta con "lo que quería expresar originalmente". Si se lo entrega a un editor especializado en buscar errores graves, este no se fijará en la belleza de su redacción, sino en fallos como "aquí se rompe la lógica" o "estos datos no coinciden". Codex en un PR actúa como ese editor: no le elogiará lo elegante de su código, sino que buscará fallos donde las cosas puedan salir mal.

Para probarlo, vaya a GitHub y escriba en el cuadro de comentarios de su PR:

@codex review

¿Qué sucede después de enviarlo? El proceso suele ser el siguiente:

1. Codex reacciona primero agregando un 👀 al comentario, indicando "recibido, empiezo a revisar" (oficialmente: siempre reacciona con un 👀 antes de enviar la revisión).
2. Inicia una tarea en la nube, lee las diferencias (diff) del PR y las contrasta con las reglas de revisión del repositorio (se explica en la siguiente sección).
3. Una vez revisado, publica una revisión en el PR como si fuera un compañero de equipo, colocando los problemas línea por línea en las secciones de código correspondientes.

Hay una configuración clave y oficial que debe conocer para no pensar que "se le pasaron muchas cosas por alto":

En GitHub, Codex solo marca problemas de nivel P0 y P1, permitiendo que los comentarios de revisión se concentren en riesgos de alta prioridad.

En lenguaje sencillo: evita deliberadamente quejarse de detalles menores (nits). P0 y P1 son las prioridades de los problemas (P0 es el más crítico, P1 es importante); solo selecciona estas dos categorías. Los detalles como "este nombre de variable podría ser mejor" o "aquí sobra un espacio" no saturarán su pantalla por defecto. Esta decisión de diseño me resulta muy cómoda: el año pasado, cuando usaba ciertas herramientas de revisión con IA, lo que más me molestaba era que un PR pequeño terminara con cuarenta 'sugerencias' donde los bugs reales se ahogaban por completo. La moderación de Codex al "reportar solo P0/P1" hace que valga la pena leer cada comentario.

Un caso de uso real: el mes pasado, el PR de un colega modificó la lógica de confirmación de pagos. Mientras yo me concentraba en si el cálculo de los montos era correcto, @codex review detectó y publicó un problema P1: la interfaz de confirmación carecía de validación de idempotencia, por lo que las confirmaciones duplicadas añadirían saldo repetidamente. Ese fallo se me habría pasado por alto.

💡 Resumen en una frase: Escriba @codex review en los comentarios del PR; reaccionará con un 👀, leerá el diff y publicará una revisión como un compañero de equipo; solo seleccionará problemas graves P0/P1 sin saturar con detalles menores, haciendo que cada comentario sea valioso.

---

03 Revisión automática: actuar en cuanto se abre un PR

@codex review requiere una "mención manual". Pero es fácil de olvidar, especialmente con los PR creados por otros miembros del equipo. Oficialmente se ofrece una opción definitiva: revisiones automáticas (Automatic reviews).

Analogía: Pasar de "hacerse un chequeo médico solo cuando se acuerda" a "un plan de chequeo anual programado por la empresa para todo el personal". La revisión manual depende de su memoria, por lo que es probable que se le olvide con frecuencia; la revisión automática integra el proceso en el flujo de trabajo, notificándole automáticamente cuando corresponde, sin depender de su iniciativa. Delegue lo que pueda olvidarse a un mecanismo automatizado, no a su memoria.

¿Cómo se activa? La documentación oficial lo explica directamente:

Si desea que Codex revise automáticamente cada PR, active Automatic reviews en la configuración de Codex. De este modo, cada vez que alguien abra un nuevo PR para revisión, Codex enviará una revisión sin necesidad del comentario @codex review.

El proceso consta de solo dos pasos (la página de configuración está en chatgpt.com, no en GitHub):

1. Vaya a la página de configuración de Code review de Codex en chatgpt.com (dirección oficial: https://chatgpt.com/codex/settings/code-review; si el enlace cambia, búsquelo en chatgpt.com → Codex → Settings → Code review).
2. Active Automatic reviews.

Una vez activado, en cuanto se abra un nuevo PR, Codex actuará automáticamente sin que usted ni sus compañeros tengan que acordarse de mencionarlo.

¿Cuándo usar el modo manual y cuándo el automático? El criterio que sigo en mi día a día es:

• Repositorios principales del equipo con alta frecuencia de colaboración → Activar la revisión automática. Deje que actúe como un filtro permanente de "primera línea" para revisar preliminarmente cada PR.
• Proyectos personales de prueba o cambios pequeños → Usar @codex review manualmente cuando sea necesario, sin necesidad de activar el flujo por cada confirmación menor.
• Cambios grandes que requieren atención en un aspecto específico → Aunque esté activada la revisión automática, puede añadir un comentario manual con instrucciones específicas (por ejemplo, @codex review for security regressions, ver sección siguiente) para que realice un segundo análisis enfocado en ese aspecto.

Comparación	Manual @codex review	Revisión automática
Activación	Añadir una mención @ en comentarios	Automática al abrir un nuevo PR
Fiabilidad	Depende de la memoria, se puede olvidar	Garantizada por el flujo de trabajo, no se olvida
Escenario ideal	Proyectos personales, cambios menores, adiciones temporales	Repositorios de equipo, necesidad de filtrar todos los PR
Control	Decide cuándo revisar e indicar prioridades	Cobertura total y automatizada

💡 Resumen en una frase: La revisión automática consiste en activar Automatic reviews en la configuración de Codex, permitiendo que revise cada nuevo PR de forma automática sin depender de menciones manuales; se recomienda para repositorios principales de equipo, mientras que la mención manual basta para proyectos pequeños.

---

04 Personalizar reglas de revisión: definir estándares en AGENTS.md

Llegados a este punto, cabe preguntarse: ¿quién define el "estándar" que utiliza para buscar fallos? Por defecto utiliza estándares generales de calidad de código, pero puede indicarle prioridades particulares de su repositorio usando AGENTS.md.

Como se explicó en el artículo sobre [11 AGENTS.md], AGENTS.md es la "lista de verificación" que Codex lee antes de empezar a trabajar. Las reglas de revisión se ubican en una sección específica de este archivo: un encabezado estándar llamado Review guidelines (Directrices de revisión).

Analogía: Entregar al inspector de calidad una "lista de verificación específica de la fábrica". Cualquier inspector conoce las normas generales (tornillos apretados, sin fisuras en la carcasa), pero cada línea de producción tiene puntos críticos particulares, como "este lote va a la Unión Europea, compruebe la certificación ambiental". Al escribir estas reglas en una lista de verificación y colocarla en la pared, el inspector prestará especial atención a esos puntos. Review guidelines en AGENTS.md funciona como esa "lista de verificación específica del repositorio".

Ejemplo oficial para añadir al archivo AGENTS.md en el directorio raíz de su repositorio:

## Review guidelines

- Don't log PII.
- Verify that authentication middleware wraps every route.
- Evitar registrar datos de identificación personal (PII).
- Verificar que el middleware de autenticación proteja cada ruta.

Una vez agregadas, Codex prestará especial atención a estas reglas en cada revisión.

Hay un mecanismo muy práctico que sigue el principio de proximidad explicado en el artículo [11]:

Codex aplica las directrices de la versión de AGENTS.md más cercana a cada archivo modificado. Puede colocar instrucciones más específicas en subdirectorios cuando ciertos paquetes requieran una inspección más estricta.

Esto significa que no es necesario acumular todas las reglas en el directorio raíz. Si el módulo de pagos requiere una revisión más estricta, coloque un AGENTS.md en src/payment/; al modificar el código de pagos, esas reglas específicas se aplicarán automáticamente. Comparte el mismo mecanismo de "sobrescritura por proximidad" del artículo [11].

Un ejemplo de cómo suelo configurarlo en src/payment/AGENTS.md:

## Review guidelines

- Use Decimal for monetary calculations; float is strictly forbidden for money operations.
- Ensure every charge operation has an idempotency key to prevent duplicate callbacks.
- Los cálculos monetarios deben usar Decimal; se prohíbe estrictamente el uso de float para operaciones financieras.
- Asegurar que cada operación de cobro tenga una clave de idempotencia para evitar callbacks duplicados.

De esta forma, al revisar cambios en la sección de pagos, Codex prestará especial atención a estas dos reglas, detectando de forma proactiva fallos como la omisión de idempotencia mencionada anteriormente.

También existe una opción rápida: indicar prioridades temporales. Si no desea modificar AGENTS.md y solo quiere enfocar la revisión de un PR específico, indíquelo directamente en el comentario:

@codex review for security regressions

Esto indica "enfóquese en regresiones de seguridad en esta ocasión". La documentación oficial también señala que si desea detectar errores ortográficos en la documentación, puede añadir en AGENTS.md una regla como "trate los errores tipográficos en documentos como P1" (Treat typos in docs as P1.) — si usted define que es P1, se lo reportará como tal.

💡 Resumen en una frase: Las reglas de revisión se definen en la sección Review guidelines de AGENTS.md; el principio de proximidad le permite aplicar reglas más estrictas a carpetas sensibles como pagos; para revisiones puntuales, puede usar @codex review for xxx en los comentarios.

---

05 Corregir directamente tras revisar: @codex fix y sus límites de acción

Una vez que Codex completa la revisión y marca un problema P1 en el PR, ¿cuál es el siguiente paso? Puede añadir un comentario para pedirle que corrija el problema directamente y envíe la corrección de vuelta a la rama del PR.

Analogía: El editor no solo marca los errores graves, sino que los corrige de inmediato y los guarda en el manuscrito. Un editor común suele limitarse a "marcar, escribir un comentario y dejar que usted lo corrija"; Codex puede ir más allá: si le pide "corrige esto por mí", modificará el código y colocará la nueva versión en su archivo. Sin embargo, para que pueda modificar el archivo, requiere que le haya otorgado permisos para hacerlo.

Uso oficial para solicitar correcciones en los comentarios de un PR:

@codex fix the P1 issue

La documentación oficial describe el proceso de la siguiente manera:

Codex utiliza este PR como contexto para iniciar una tarea en la nube y, si tiene los permisos necesarios, puede enviar la corrección de vuelta a la rama.

Analizando esta afirmación, encontramos dos puntos clave que se alinean con las directrices de seguridad que hemos mantenido:

Primero, @codex fix inicia una tarea en la nube. No realiza cambios directamente sobre el comentario de revisión; inicia una tarea de Codex cloud como las descritas en el artículo [10], utiliza el PR como contexto y entra en el ciclo de "pensar → hacer → observar" para modificar el código y validarlo.

Segundo, "si tiene los permisos necesarios" envía la corrección de vuelta a la rama; este es el punto clave. La capacidad de enviar cambios a su rama depende de los permisos que haya otorgado a Codex. Como se enfatiza en los artículos sobre permisos [15] y seguridad [16]: la capacidad de realizar cambios está determinada por la autorización otorgada, no por la intención del sistema. Si no otorga permisos de escritura, se limitará a mostrarle los cambios sin poder enviarlos.

Es fácil confundir el comportamiento de @codex según lo que le siga:

• @codex review → Inicia el flujo de revisión de código (solo revisa, no modifica código).
• @codex + cualquier otra instrucción (por ejemplo, @codex fix the CI failures, @codex add tests for this interface) → Inicia una tarea común en la nube utilizando el PR como contexto para realizar cambios.

La documentación oficial lo aclara:

Si escribe en un comentario @codex seguido de cualquier contenido que no sea review, Codex iniciará una tarea en la nube utilizando su PR como contexto.

Por lo tanto, review es una "palabra reservada" para el flujo de revisión, mientras que las demás instrucciones activan tareas comunes en la nube. Recordar esta distinción evitará que se pregunte por qué @codex fix realiza cambios en lugar de limitarse a revisar.

Una recomendación alineada con nuestras pautas fundamentales: delegar tareas con @codex fix para que envíe cambios a la rama es cómodo, pero la decisión de autorizar la escritura y de realizar la fusión final (merge) debe permanecer bajo su control. Mi recomendación es: permitir que realice correcciones y las envíe a la rama está bien, pero el paso de "fusionar con la rama principal" (hacer clic en Merge) debe ser realizado siempre por un humano, tal como indicamos al hablar de worktrees en el artículo [25] ("él corre en su carril, usted decide la fusión").

💡 Resumen en una frase: Solicitar una corrección con @codex fix the P1 issue inicia una tarea en la nube para modificar el código y, siempre que haya otorgado permisos de escritura, enviará la solución a la rama del PR; recuerde que @codex review es para revisar y @codex + otros textos inicia tareas de modificación; la acción de fusionar con la rama principal queda en sus manos.

El flujo de revisión en GitHub se consolida de la siguiente manera:

Este diagrama conecta las secciones 02 a 05: al crear o actualizar un PR, este se activa mediante la mención @codex review o de forma automática; Codex ejecuta la tarea en la nube leyendo el diff del PR y contrastándolo con las reglas de AGENTS.md más cercanas; finalmente, publica comentarios sobre los problemas P0/P1 encontrados en las líneas correspondientes; usted puede pedirle que los corrija con @codex fix y el proceso puede repetirse.

---

06 /review local: realizar una autoevaluación en la terminal antes de abrir el PR

Las secciones anteriores se ejecutan en GitHub. Pero existe un paso previo más rápido y directo: antes de enviar el código y abrir el PR, puede realizar una revisión local con /review sin interactuar con GitHub.

Analogía: Borrar los propios errores con una goma de borrar antes de entregar la tarea, en lugar de esperar a que el profesor llene la hoja de marcas rojas. Es preferible detectar y corregir los problemas obvios localmente antes de subir el código y exponerlo a la revisión formal (sea humana o con @codex review), reduciendo así el costo de corrección.

Para ejecutarlo, use el siguiente comando en la sesión de Codex en su terminal:

/review

Al ingresarlo, se mostrará un menú con ajustes predeterminados de revisión para elegir; Codex iniciará un revisor dedicado que leerá el diff seleccionado y reportará los problemas ordenados por prioridad, sin realizar modificaciones en su espacio de trabajo (es puramente de lectura). Los ajustes predeterminados son:

• Review against a base branch (Revisar contra rama base): seleccione una rama local para comparar, permitiendo a Codex identificar la base de fusión, calcular las diferencias y detectar los riesgos principales antes de abrir el PR.
• Review uncommitted changes (Revisar cambios sin confirmar): analiza los cambios preparados (staged), no preparados y no rastreados para corregir problemas antes de confirmar.
• Review a commit (Revisar una confirmación): permite seleccionar una confirmación específica por su hash SHA para analizar sus cambios detalladamente.
• Custom review instructions (Instrucciones de revisión personalizadas): escriba una indicación específica (por ejemplo, "enfóquese en regresiones de accesibilidad") para que el revisor analice el código bajo ese criterio.

Hay un detalle de configuración oficial que vale la pena recordar: /review utiliza por defecto el modelo de su sesión actual; si desea usar un modelo más potente específicamente para las revisiones, configúrelo en config.toml mediante review_model. En mi caso, utilizo un modelo rápido para las tareas cotidianas y configuro un modelo más potente en review_model para analizar los detalles de la revisión, lo cual compensa el costo adicional.

Mi rutina habitual consiste en usar /review como un filtro previo antes de abrir el PR:

1. Al terminar los cambios, ejecuto /review en la terminal y elijo Review uncommitted changes.
2. Corrijo localmente los problemas identificados según su prioridad.
3. Una vez limpio el código, confirmo, envío y abro el PR; de este modo, cuando se ejecute @codex review (o la revisión automática), los comentarios resultantes serán pocos y muy precisos.

Una autoevaluación local reduce significativamente los comentarios en la revisión remota. Sigo este flujo desde marzo y he logrado reducir a la mitad los comentarios en los PR.

💡 Resumen en una frase: El comando /review local es un filtro previo antes de abrir el PR; permite elegir opciones en la terminal (cambios sin confirmar, comparar con rama, commit específico o personalizado) y reporta problemas ordenados por prioridad de forma puramente de lectura; realizar las correcciones locales primero mantiene limpia la revisión remota; use review_model para asignar un modelo más potente a esta tarea.

---

07 Configurar gh: permitir que Codex acceda al contexto del PR

Si utiliza la App de escritorio de Codex (explicada en el artículo [07]) o las extensiones de IDE (artículo [09]) para su trabajo, es muy recomendable que instale la herramienta oficial de línea de comandos de GitHub, gh.

Analogía: Entregar a su asistente una credencial de acceso para entrar a la sala de archivos. Sin ella, el asistente sabe de la existencia del PR, pero no puede acceder a las conversaciones ni a los comentarios del revisor (el contexto del PR); con la credencial (la sesión iniciada en gh), puede acceder a todo el expediente y presentárselo ordenadamente.

La documentación oficial lo detalla claramente:

Instale GitHub CLI (gh) y autentíquese mediante gh auth login para que Codex pueda cargar el contexto del PR, los comentarios de revisión y los archivos modificados. Si gh no está instalado o no se ha autenticado, es posible que los detalles del PR no aparezcan en la barra lateral o en el panel de revisión.

En lenguaje sencillo: al instalar gh e iniciar sesión, la barra lateral de la App de escritorio de Codex podrá mostrar el contexto del PR, los comentarios de los revisores y los archivos modificados, permitiéndole interactuar con ellos en una misma interfaz; de lo contrario, esta información no se mostrará.

Instalación e inicio de sesión (se indican las opciones por plataforma):

# macOS (Homebrew)
brew install gh

# Windows (winget)
winget install --id GitHub.cli

# Una vez instalado, inicie sesión en cualquier plataforma ejecutando:
gh auth login

ℹ️ Para instalar en Linux, use el gestor de paquetes correspondiente a su distribución (apt, dnf, pacman, etc.) siguiendo la documentación oficial de GitHub CLI. Tras la instalación, ejecute igualmente gh auth login.

Una vez iniciada la sesión, el flujo oficial para resolver los problemas del PR en una sola interfaz es:

1. Abra el panel de revisión en la rama del PR.
2. Revise el contexto del PR, los comentarios y los archivos modificados.
3. Solicite a Codex que resuelva los comentarios seleccionados.
4. Verifique las diferencias (diff) resultantes en el panel de revisión.
5. Una vez que esté conforme con los cambios, prepare (stage), confirme (commit) y envíe (push) de vuelta a la rama del PR.

Observe que en el paso 5, la acción de enviar los cambios queda en sus manos. Es la misma directriz. El sistema le ayuda a leer los comentarios y a aplicar los cambios, pero el envío final lo realiza usted.

Una advertencia de seguridad alineada con el artículo [16]: los comentarios de los PR, los mensajes de los revisores y los issues asociados son "contenido externo" que potencialmente podrían contener instrucciones maliciosas dirigidas a la IA. Aunque es seguro dejar que lea y procese los comentarios, evite pedirle que "aplique ciegamente todo lo indicado en los comentarios y lo envíe directamente"; preste atención si en un comentario se solicita ejecutar comandos extraños o acceder a URLs sospechosas que no parezcan parte de una revisión de código normal.

💡 Resumen en una frase: Para trabajar con PR en la App de escritorio o IDE, instale gh y ejecute gh auth login para permitir que Codex acceda al contexto, comentarios y archivos del PR; el envío final de los cambios modificados permanece bajo su control y debe tener precaución con posibles inyecciones de instrucciones en comentarios externos.

---

08 Proteger los límites: no permita que la IA realice las fusiones (merge) o envíos forzados (force-push)

Hemos hablado de lo que puede delegar con confianza; en esta sección nos enfocaremos en las acciones críticas que debe realizar usted mismo, una directriz de control que va desde el artículo de permisos [15] y seguridad [16] y que debe aplicarse estrictamente en Git.

Analogía: Un asistente puede redactar y corregir un contrato hasta que quede perfecto, pero la firma y el sello que lo hacen legalmente vinculante deben ser aplicados por el representante legal. El asistente se encarga de la redacción, la comunicación y la organización de las cláusulas, pero la firma es un acto definitivo y con consecuencias legales que debe realizar el responsable. En Git, los equivalentes a esa firma definitiva son la fusión con la rama principal (merge) y el envío forzado que reescribe el historial (force-push).

¿Por qué estas dos operaciones? Comparemos el nivel de control:

Operación	¿Es reversible fácilmente si hay un error?	¿Quién la ejecuta?
@codex review / /review local	— (Lectura, no altera nada)	✅ Delegar con confianza
@codex fix enviado a una rama de PR	Sí (la rama se puede modificar o eliminar)	✅ Delegar con autorización previa y supervisión
Fusionar el PR con main (merge)	⚠️ Afecta a todo el equipo, difícil de revertir	⚠️ Ejecutado por usted
git push --force / alterar el historial	❌ Puede sobrescribir cambios ajenos	❌ Límite estricto, siempre manual

Mantengo dos reglas estrictas de forma permanente:

Primera: la fusión final debe ser realizada por usted. Codex puede revisar, proponer correcciones y enviar cambios a una rama de PR (acciones que entran en la categoría de "reversibles", ya que si no está conforme puede descartar la rama y empezar de nuevo). Sin embargo, hacer clic en Merge para incorporar los cambios a main afecta directamente a la línea de desarrollo común del equipo; por lo tanto, usted debe decidir si fusionar y cuándo hacerlo.

Segunda: el envío forzado (force-push) nunca debe delegarse a una IA. git push --force puede sobrescribir el historial remoto y borrar cambios de otros compañeros, representando un riesgo crítico. Esta operación debe ser puramente manual y requiere validar detenidamente la rama de destino antes de ejecutarla. Evite crear scripts o flujos automatizados que permitan a la IA realizar envíos forzados.

¿Recuerda lo explicado en el artículo [15]? Por defecto, codex exec se ejecuta en un sandbox de solo lectura (read-only); no se trata de una limitación de capacidad, sino de limitar al mínimo el área de acción por defecto, requiriendo autorización explícita (--sandbox workspace-write) para habilitar la escritura. Esta filosofía de diseño de "restricción por defecto y ampliación mediante autorización explícita" coincide con la regla de realizar fusiones y envíos forzados manualmente: las acciones más difíciles de revertir deben requerir una confirmación humana explícita.

💡 Resumen en una frase: Delegue con confianza las revisiones, correcciones y envíos a ramas temporales; pero la fusión final con main (merge) debe ser realizada por usted y el envío forzado (force-push) debe ser estrictamente manual, una filosofía de control alineada con el sandbox de solo lectura por defecto de codex exec.

El flujo integrado de toma de decisiones se representa de la siguiente manera:

Este diagrama representa el ciclo de desarrollo: autoevaluación local con /review (zona verde, lectura) → @codex review en la nube para identificar P0/P1 en el PR (ciclo de corrección y revisión) → decisión final de fusionar o aplicar envíos forzados (zona roja, irreversible) bajo estricto control humano.

---

09 Modelo mental: Codex revisa y propone, usted decide y aprueba

Al integrar las secciones anteriores, conserve este modelo mental: Codex actúa en el flujo de GitHub como revisor y redactor de correcciones, mientras que usted mantiene la decisión final de aprobación y fusión.

Al comprender este modelo, evitará caer en extremos: no cargará con todo el proceso de revisión manualmente por temor a fallos (perdiendo el beneficio de la automatización), ni delegará ciegamente las fusiones y envíos forzados al sistema (exponiéndose a incidentes). El revisor propone y asiste; el responsable autoriza y aprueba.

💡 Resumen en una frase: Considere a Codex como su revisor y asistente de correcciones en GitHub (autoevaluación con /review, detección con @codex review y corrección con @codex fix), y conserve para sí la decisión final de fusión y publicación (merge y force-push manuales), manteniendo un equilibrio seguro y eficiente.

---

10 Práctica: Ejecutar una autoevaluación local con /review

Dado que las revisiones en GitHub dependen de la conexión cloud y la autorización de repositorios, no es práctico simularlas en una máquina limpia; sin embargo, el comando /review local no requiere configuración previa y le permite experimentar el flujo de autoevaluación de inmediato. Este proceso se ejecuta localmente en modo lectura y puede descartarse al finalizar.

Paso 1: Crear un repositorio de práctica (ejecutar en la terminal, no en la sesión de Codex)

mkdir review-demo && cd review-demo
git init
printf 'def get_user(uid):\n    return db.query("SELECT * FROM users WHERE id=" + uid)\n' > app.py
git add app.py && git commit -m "feat: initial get_user"

Resultado esperado: Se inicializa el repositorio y se realiza la confirmación inicial mostrando un mensaje similar a [main (root-commit) xxxxxxx] feat: initial get_user. Note que he incluido intencionalmente una vulnerabilidad de inyección SQL (concatenación directa en la consulta) para verificar si Codex la detecta.

Paso 2: Realizar una nueva modificación (sin confirmar, para analizar)

printf 'def get_user(uid):\n    return db.query("SELECT * FROM users WHERE id=" + uid)\n\ndef delete_user(uid):\n    db.execute("DELETE FROM users WHERE id=" + uid)\n' > app.py

Resultado esperado: Sin errores. Ahora tiene un cambio en su área de trabajo que introduce la función delete_user, sin preparar ni confirmar, ideal para probar el modo de revisión de cambios sin confirmar.

Paso 3: Iniciar la sesión de Codex y ejecutar /review

codex

Una vez dentro de la sesión, ejecute:

/review

Resultado esperado: Se despliega el menú de preajustes de revisión; use las flechas del teclado para seleccionar Review uncommitted changes y pulse Enter.

Paso 4: Analizar los resultados reportados

Resultado esperado: Codex inicia el revisor, analiza las diferencias sin confirmar y despliega en la terminal los problemas encontrados clasificados por prioridad. Debería identificar la vulnerabilidad de inyección SQL en la función delete_user (la concatenación de uid en la consulta), clasificándola como un hallazgo de alta prioridad y recomendando el uso de consultas parametrizadas. Esta detección demuestra que comprende el cambio introducido en lugar de limitarse a análisis generales. Tenga en cuenta que su archivo app.py no ha sido modificado, cumpliendo con la naturaleza de solo lectura de /review.

ℹ️ El número exacto de comentarios, su redacción y si detecta la vulnerabilidad en la primera función (código preexistente) dependerá del análisis del modelo en ese momento; lo importante es validar que identifique la inyección SQL como un problema real sin modificar sus archivos locales.

Paso 5: Limpieza (opcional)

cd .. && rm -rf review-demo

Al completar estos pasos, habrá experimentado el flujo práctico de realizar una autoevaluación local con /review antes de enviar cambios. Una vez configurado su entorno real con Codex cloud, podrá combinar esta práctica local con la revisión remota de @codex review para obtener un flujo de control completo.

💡 Resumen en una frase: La práctica consta de cinco pasos: crear un repositorio local (con una inyección SQL intencional) → aplicar cambios sin confirmar → ejecutar /review seleccionando revisar cambios sin confirmar → validar que detecte la vulnerabilidad sin modificar archivos → limpiar el entorno; permitiendo validar localmente y de forma segura el flujo de autoevaluación.

---

11 Resumen

Este artículo ha detallado la integración de Codex con Git y GitHub, enfatizando la importancia de distinguir los flujos de lectura, corrección y las acciones críticas de fusión.

Repasemos los conceptos clave:

Objetivo	Procedimiento con Codex	Puntos clave
Revisar un PR	Comentario @codex review	Se ejecuta en la nube, selecciona problemas P0/P1 y comenta en el PR
Revisión automática en PR	Activar Automatic reviews en configuración	Garantía por flujo de trabajo, recomendado para repositorios de equipo
Personalizar criterios de revisión	Sección Review guidelines en AGENTS.md	Aplicación por principio de proximidad, permite reglas estrictas en carpetas sensibles
Aplicar correcciones propuestas	Comentario @codex fix the P1 issue	Tarea en la nube que actualiza la rama si se otorgan permisos de escritura
Autoevaluación previa a PR	Comando /review en terminal	Modo lectura local para corregir fallos antes de enviar el código
Cargar contexto de PR en App	Instalar y autenticar con GitHub CLI (gh)	Necesario para mostrar detalles de PR y comentarios en la interfaz gráfica
Controlar fusiones críticas	Fusiones (merge) y envíos forzados manuales	Las acciones definitivas e irreversibles deben ser ejecutadas por humanos

Ahora debería ser capaz de:

• Diferenciar ambos flujos: @codex review en GitHub (nube, comentarios en PR, requiere cloud) y /review local (local, lectura, sin requisitos previos).
• En el flujo de GitHub: iniciar revisiones manuales, configurar revisiones automáticas, estructurar reglas personalizadas en AGENTS.md, aplicar correcciones a la rama con @codex fix e integrar GitHub CLI para soporte en App de escritorio.
• En el flujo local: crear repositorios de prueba y evaluar cambios en la terminal mediante /review.
• Mantener el control final: realizar las fusiones (merge) y los envíos forzados manualmente, garantizando un flujo ágil pero bajo supervisión humana.

Delegar la revisión a un asistente incansable que filtra problemas críticos de acuerdo a sus estándares le ahorra tiempo y esfuerzo en el proceso de revisión; y mantener el control sobre la fusión final garantiza la estabilidad de su código principal. Este es el esquema de colaboración ideal entre humanos e inteligencia artificial en entornos Git.

---

El siguiente artículo 27 · Automatización y CI/CD: en este artículo hemos visto flujos de revisión activados manualmente o por eventos de PR; el siguiente paso es la automatización completa: usar codex exec para integrar Codex en sus flujos de trabajo de GitHub Actions, permitiendo que actúe de forma autónoma ante fallos en la compilación, aplique correcciones y abra PR sin intervención humana. Imagine que su flujo de integración continua corrige fallos automáticamente y le presenta la propuesta de solución lista para fusionar al iniciar su jornada; ese es el nivel de automatización que trataremos a continuación.

---

Lecturas recomendadas

• Skills de Codex: empaquetar conjuntos de instrucciones para que Codex las ejecute de forma autónoma
• Práctica integrada: añadir funcionalidad y confirmar cambios en una herramienta TODO desde cero
• Extensiones de IDE (VS Code y otros)