Code Review en Codex (/review): un tutorial con ejemplo
/review es el revisor de diff dedicado de Codex (OpenAI Codex CLI): nunca edita archivos en tu working tree, solo lee y devuelve una lista priorizada de hallazgos. Puedes ejecutarlo desde la CLI, una extensión de IDE, la app de escritorio de ChatGPT o ChatGPT web, con 4 presets según el alcance que quieras revisar. En este tutorial te muestro la mecánica: los 4 presets, las flags de CLI no interactivas para scripts/CI, un ejemplo real de diff revisado y cuándo necesitas de verdad gh para leer un PR de GitHub.
- Codex es una superficie de funciones que cambia rápido; los detalles de abajo se contrastaron con la documentación oficial al momento de escribir (08/2026) - verifica la documentación en vivo antes de depender del nombre exacto de una flag o de un comportamiento.
Qué hace realmente /review
/review ejecuta un sub-turno separado y de solo lectura: lee el diff que le indicas y nunca toca los archivos de tu working tree. La salida es una lista priorizada de hallazgos ligada a posiciones dentro del diff, no un párrafo genérico de comentarios. Esa es la diferencia clave frente a pegar un diff en el chat y preguntar "¿esto se ve bien?" - /review es un flujo distinto y estructurado, separado de tu sesión de código activa.
Según la documentación oficial (learn.chatgpt.com/docs/code-review, consultado 08/2026), está pensado para ejecutarse antes de abrir un PR o antes de hacer merge - no es un modo "arréglamelo" como una tarea normal de Codex. Si estás acostumbrada al flujo de review de Claude Code, el modelo mental se traslada igual: un paso aparte, leer antes de escribir.
Los 4 presets de review
Codex no tiene un botón genérico de "review" - eliges un preset según el alcance del diff que quieras revisar:
| Preset | Cuándo usarlo | Qué revisa |
|---|---|---|
| Rama base | Terminaste una rama y quieres revisar todo antes de abrir un PR | Codex encuentra la merge base y revisa el diff de la rama contra ella |
| Sin commitear | A media edición, todavía no corriste git add y quieres una revisión temprana | Cambios en stage + fuera del stage + sin seguimiento |
| Un commit | Necesitas revisar un commit específico, p. ej. antes de un rebase/squash | El conjunto de cambios exacto de ese commit, nada más |
| Instrucciones personalizadas | Tienes tus propios criterios, p. ej. solo seguridad o un estándar de código interno | Libre - describes los criterios y Codex revisa exactamente contra eso |
En el composer, escribe /review y elige un preset del menú. Los tres primeros son "elegir un alcance de diff ya existente"; el cuarto es donde escribes tus propios criterios cuando el alcance por defecto no alcanza - p. ej. "solo señala vulnerabilidades de autenticación" o "revisa contra el estándar de código en AGENTS.md".
Dónde puedes ejecutarlo - CLI, IDE, app, web
/review no está atado a una sola superficie. Cuatro superficies lo soportan hoy:
- CLI - escribe
/reviewen el composer durante una sesión de terminal, o corre el comando no interactivocodex reviewdesde un script/CI (mira la sección de flags más abajo). - Extensión de IDE - el mismo composer, integrado en VS Code/JetBrains, revisando justo al lado del diff que tienes abierto, sin cambiar de ventana.
- App de escritorio de ChatGPT - tiene un panel de review dedicado, útil cuando quieres la ventana de review separada de la de código.
- ChatGPT web - corre un review directo desde el navegador, práctico cuando no tienes tu máquina de desarrollo a mano.
Las cuatro superficies comparten el mismo mecanismo de review por debajo, pero la interfaz y los nombres exactos de cada una no tienen garantía de coincidir 1 a 1 - vale la pena verificar la documentación en vivo si algún nombre de botón o ubicación de menú en este artículo se ve raro.
Las flags de CLI no interactivas (para scripts/CI)
Además de /review en el composer, Codex trae un comando no interactivo codex review, hecho para scripts o un pipeline de CI. Según learn.chatgpt.com/docs/cli/reference, consultado 08/2026:
# Review the diff against a base branch
codex review --base main
# Review one specific commit, with an optional title (--title requires --commit)
codex review --commit <sha> --title "Fix invoice endpoint"
# Review uncommitted changes (staged + unstaged + untracked)
codex review --uncommitted
# Freeform prompt, read directly from stdin
git diff | codex review -
# Strict-match config.toml when you need consistent CI behavior
codex review --base main --strict-config
Regla clave: las flags de alcance son mutuamente excluyentes - elige exactamente una entre --base, --commit, --uncommitted o un PROMPT/stdin por ejecución, nunca las mezcles. Este es un lugar común de renombrados silenciosos entre releases de Codex, así que vuelve a revisar los nombres exactos de las flags antes de fijarlos en el CI.
Revisando un diff real - un ejemplo trabajado
Dejando la teoría, este es el tipo de hallazgo que /review suele detectar en una pequeña ruta de Node.js (recortada para ilustrar, no es la salida cruda literal). La ruta obtiene una factura por ID en un sistema multi-tenant:
// Before
async function getInvoice(req, res) {
const invoice = await db.invoices.findOne({ id: req.params.id });
if (!invoice) return res.status(404).end();
res.json(invoice);
}
Hallazgo 1 (severidad: alta, correcto): "Falta el filtro de alcance por tenant - la ruta consulta solo por id, así que un usuario del tenant A puede ver la factura del tenant B adivinando el ID. Agrega tenantId: req.user.tenantId al filtro de la consulta." Este es un bug de manual de IDOR (referencia directa insegura a objeto) - sintácticamente bien, corre sin errores, pero filtra datos entre tenants. La corrección:
// After
async function getInvoice(req, res) {
const invoice = await db.invoices.findOne({
id: req.params.id,
tenantId: req.user.tenantId,
});
if (!invoice) return res.status(404).end();
res.json(invoice);
}
Hallazgo 2 (severidad: media, necesitó una segunda mirada humana): /review también señaló "esta ruta no tiene rate limiting." Eso es correcto a nivel de código - pero tras revisar gateway.config.ts, la ruta ya está detrás del rate limiter global del API gateway. El hallazgo no estaba técnicamente mal, solo le faltaba contexto que /review no puede ver (configuración fuera del alcance del diff) - un caso en el que un humano debe confirmar antes de actuar, no aplicarlo automáticamente.
Dos hallazgos en una sola ejecución muestran exactamente cómo leer la salida de /review: el hallazgo 1 es un bug real, corrígelo ya; el hallazgo 2 es localmente correcto pero le falta el contexto del sistema - necesita tu confirmación, no una aplicación automática.
Revisando un PR de GitHub - qué necesita gh
Dos mecanismos distintos de GitHub son fáciles de confundir si lees por encima:
1. Leer el contexto del PR localmente (necesita gh). Cuando revisas un PR desde la CLI, la app o el IDE, Codex necesita gh instalado y autenticado para traer la información del PR (título, descripción, comentarios). Según la documentación: si falta gh o no está autenticado, los detalles del PR pueden no aparecer en la barra lateral o en el panel de review. La configuración es un solo comando:
gh auth login
2. Disparar un review en la nube por comentario (no necesita gh local). Comentar @codex review directamente en un PR de GitHub dispara un review que corre en la nube - un mecanismo completamente separado de la lectura local del contexto del PR de arriba, y no requiere gh en tu máquina. La condición es que Codex cloud ya esté configurado para tu repositorio. Este mecanismo pertenece a la configuración más profunda de Codex Cloud - si quieres configurar este tipo de disparador de review automático, eso vive en la guía de Codex Cloud; aquí es solo una línea para que no confundas los dos mecanismos.
¿Cuánto deberías confiar en un hallazgo de /review?
Para ser directa: un hallazgo de /review es una sugerencia priorizada, no una puerta de merge automática. El hallazgo 2 de arriba lo deja claro - sintácticamente correcto, con lógica localmente correcta, pero equivocado porque le falta el contexto del sistema. Ese tipo de falso positivo pasa más seguido de lo que crees cuando un review solo ve el diff, no el repositorio completo.
Así que un humano (o, si instalaste el Engineer Kit de AgentKit, su skill/agente de code-review) sigue controlando la decisión real de merge - /review solo acorta la parte del escaneo mecánico para que la persona revisora gaste esfuerzo en la parte más difícil. AgentKit trae un comando /ak:review con un flujo de review parecido que corre tanto en Claude Code como en Codex, práctico si quieres un proceso ya armado en vez de montar uno; pero, para que quede claro, es un kit de pago que se suma encima - el propio /review de Codex ya es gratis y suficiente para review individual. Si aún no lo configuraste, mira primero cómo usar AgentKit dentro de Codex.
¿Quieres un agente de review dedicado corriendo junto al /review de Codex? El Engineer Kit de AgentKit trae un skill/agente de code-review vía /ak:review, funcionando en Codex y en Claude Code - no reemplaza a /review, agrega una capa extra preconfigurada.
Conoce el AgentKit Engineer Kit - 20% de descuento, ahora $79.20 →
/review de Codex vs el flujo de review de Claude Code
Misma idea, herramienta distinta. Claude Code tiene su propio /review con el mismo flujo de "bloquear el merge mientras quede un hallazgo serio" - el proceso de 3 pasos y un ejemplo real de hallazgo están en la guía de code review con IA para Claude Code (ese artículo nunca menciona Codex, y este no repite su contenido). Si usas las dos herramientas, el principio de fondo se sostiene igual: revisar sobre el diff, ordenar por severidad y, al final, un humano sigue tomando la decisión del merge.
Preguntas frecuentes
¿Cuáles son los presets de /review de Codex?
Rama base (revisa todo el diff contra la merge base), Sin commitear (en stage + fuera del stage + sin seguimiento), Un commit (el conjunto de cambios de ese commit) e Instrucciones personalizadas (describes tus propios criterios de review, libre).
¿/review edita mi código?
No. /review ejecuta un sub-turno de solo lectura y nunca toca los archivos de tu working tree. Solo devuelve una lista priorizada de hallazgos - tú decides qué corregir o saltar.
¿Necesito gh para revisar PRs?
Sí, para leer el contexto del PR localmente (título, descripción, comentarios) desde la CLI/app/IDE - gh debe estar instalado y autenticado, o los detalles del PR pueden no aparecer en la barra lateral. Eso es distinto de comentar @codex review, que no necesita gh local.
¿Qué es @codex review en GitHub?
Una forma de disparar un review en la nube comentando @codex review directamente en un PR, separada de leer el contexto del PR localmente. Requiere Codex cloud ya configurado para tu repositorio; los detalles más profundos pertenecen a Codex Cloud, fuera del alcance de este artículo.
¿Puedo correr reviews desde un script/CI?
Sí, mediante el comando no interactivo codex review con --base, --commit, --uncommitted o un PROMPT/stdin - exactamente una flag de alcance por ejecución, nunca combinadas.
¿/review reemplaza una aprobación humana?
No. Un hallazgo de /review es una sugerencia priorizada que puede estar equivocada por faltarle contexto del sistema (mira el hallazgo 2 de arriba). Un humano - o un agente de review dedicado como el que trae el Engineer Kit de AgentKit - sigue teniendo la última palabra sobre el merge.
Conclusión
En resumen: el /review de Codex tiene 4 presets, corre en CLI/IDE/app/web, nunca edita archivos por su cuenta y necesita gh cuando quieres el contexto del PR localmente - mientras que @codex review como comentario es un mecanismo separado en la nube. Lee los hallazgos como sugerencias priorizadas, no como una puerta de merge automática. Si también usas Claude Code, mira el flujo de code review con IA para Claude Code; si Codex es nuevo para ti, empieza por qué es OpenAI Codex.