Plugin Codex para Claude Code: Instalar, configurar, evitar bucles de revisión

Cualquiera que haya hecho funcionar dos agentes de programación simultáneamente conoce bien este proceso. Un terminal se encarga de planificar y el otro de revisar, mientras uno está sentado entre ellos copiando texto de un lado a otro como si fuera una pestaña con opiniones. Si intentas automatizar la conversación, los dos comienzan a discutir por las comas, y la sesión que pretendías terminar antes del almuerzo sigue reescribiendo el mismo encabezado a las cuatro de la tarde.

El complemento oficial de OpenAI para Claude Code, codex-plugin-cc, elimina en gran medida esa necesidad de copiar. Permite realizar revisiones en Codex, delegar tareas y transferir sesiones directamente desde dentro de Claude Code. Llegar a esto es rápido: instale la CLI de Codex en la máquina, registre el marketplace de OpenAI en Claude Code, instale el complemento, recargue la aplicación y ejecute la orden de configuración. En el caso opuesto, donde Claude se ejecuta como invitado dentro de Codex, existe un complemento inverso separado con su propio camino de instalación. En ambos casos, el orden lógico es compartir primero las instrucciones del proyecto y añadir reglas de revisión y transferencia antes de automatizar cualquier proceso iterativo.

La ventaja proviene de una transferencia más rápida y no de modelos más inteligentes. Un repositorio que cuenta con un terminal host, donde el agente invitado realiza la revisión por sí mismo, evita que el usuario tenga que trasladar fragmentos del diferencial de un sistema a otro. Los detalles que se presentan a continuación provienen de la documentación de los complementos y de artículos de la comunidad; es posible que los comandos o nombres de los modelos hayan cambiado desde que se recopilaron, por lo que conviene verificarlos en los README actuales antes de confiar en ellos.

Elija la dirección antes de instalar cualquier cosa

Imagínese subirse a un coche donde dos unidades de navegación se activan al mismo tiempo. Una prefiere las autopistas y la otra las calles laterales, y ninguna espera a que usted designe al conductor. Si sale del camino sin decidir quién indicará el próximo giro, terminará atascado mientras las dos pantallas se hablan entre sí.

El problema fundamental es el host. El complemento Codex para Claude Code funciona como un navegador adicional, no como un volante extra; por lo tanto, hay que decidir qué terminal será la principal antes de ejecutar la primera orden de instalación.

Existen dos métodos, y cada uno requiere un procedimiento propio. Una orden $cc: no pertenece a una sesión de Claude Code, y una orden /plugin pegada en Codex no activará el mismo complemento.

Método oficial: Codex dentro de Claude Code

Se trata del producto propio de OpenAI para este fin, codex-plugin-cc. Claude Code sigue siendo el espacio de trabajo, mientras que Codex se integra como un agente auxiliar capaz de revisar código, cuestionar diseños, asumir tareas de corrección, ejecutar trabajos en segundo plano y mantener la sesión activa.

Un mercado de complementos es simplemente el registro al que recurre Claude Code para encontrar los complementos que puede instalar. El procedimiento consiste en agregar el mercado de OpenAI, instalar codex@openai-codex, recargar la aplicación y ejecutar /codex:setup. El complemento se comunica con la CLI local de Codex y con el servidor de aplicaciones de Codex, sin iniciar un entorno de ejecución en la nube independiente. Elija este enfoque cuando Claude Code ya se encuentra donde usted desea que esté, para buscar y gestionar los complementos. Cuando hay discrepancias entre una entrada de blog y el archivo README del repositorio, prevalece el contenido del README.

Ruta inversa: Claude dentro de Codex

El complemento cc-plugin-codex de Sendbird funciona de manera inversa. Codex actúa como anfitrión, y Claude Code se llama como invitado, normalmente a través de un nuevo subproceso no interactivo claude -p por tarea. La instalación se realiza dentro de Codex:

codex plugin marketplace add sendbird/codex-marketplace
codex plugin add cc@sendbird
$cc:setup

Existe una herramienta idempotente, npx cc-plugin-codex install, que se puede ejecutar nuevamente para realizar actualizaciones. $cc:setup verifica los ganchos, la confiabilidad de la caché y las rutas escriturables, y los ganchos inversos también requieren hooks = true dentro de [features] en ~/.codex/config.toml.

También existe una tercera opción no oficial: un mercado comunitario (yanchuk/claude-plugin-codex) con la orden $claude setup. Considérelo como software comunitario y no lo confunda con el plugin de OpenAI.

Si lo que desea es un veredicto sobre cuál producto es mejor, esa es una comparación diferente, y la discusión aquí se centra en la configuración. En resumen, la decisión depende de quién es el anfitrión, quién es el invitado y qué entrada de instalación se puede ingresar.

Instalando el plugin oficial dentro de Claude Code

El resto de esta sección sigue la ruta oficial, a menos que un encabezado indique lo contrario. Las comparaciones de marcas, VS Code y Cursor son tareas separadas, y la propia CLI, incluidos los instaladores de plataforma y las opciones de entorno aislado para la primera ejecución, cuenta con su propia documentación de instalación.

Las cosas fallarán si Node.js es anterior a 18.18, si Codex no está autenticado en la máquina, o si omite el recargue y luego concluye que el complemento está roto.

Confirme los requisitos documentados

El plugin oficial requiere Node.js 18.18 o una versión más reciente. El plugin inverso de Sendbird solo exige Node.js 18 o superior, pero quienes usen la ruta oficial deben cumplir con requisitos más estrictos. También se necesita una CLI de Codex local que funcione, además de una forma de pagarla, lo que implica un plan de ChatGPT (el gratuito cuenta, según el README original) o una clave API de OpenAI. Claude Code tiene su propio requisito: una clave API de Anthropic o un plan Claude Pro o Max. Eso significa dos productos y dos facturas, ya que el plugin no los combina.

Si falta la CLI, instálala:

npm install -g @openai/codex

Luego, autentíquese mediante el flujo documentado de Claude Code:

!codex login

Evite los sitios espejo y las listas de ejecutables de terceros. Los paquetes legítimos son el repositorio de GitHub y la CLI de npm con alcance específico. Y si su herramienta diaria es la barra lateral de un IDE y no Claude Code, entonces está trabajando con un host diferente que tiene sus propias instrucciones.

Agregar el marketplace, instalar, recargar, configurar

La instalación del plugin oficial requiere cuatro comandos con barra diagonal. Un comando con barra diagonal es /command introducido en la sesión de Claude Code y no un archivo binario en su ruta del shell. Úselos en este orden:

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins
/codex:setup

/reload-plugins actualiza la lista de plugins activos, y omitirlo puede hacer que una instalación exitosa muestre comandos como si aún faltaran. /codex:setup confirma que Codex está autenticado y, cuando la CLI no está disponible, puede proponer instalar el paquete global @openai/codex con npm. Esa es toda la instalación oficial. La mayoría de los problemas que la gente atribuye al plugin provienen de los pasos relacionados con él.

Configura Codex para el proyecto y no solo para la máquina

Una instalación global te proporciona comandos. No indica a Codex cómo se debe tratar un repositorio específico. Los valores predeterminados del usuario y las modificaciones del proyecto se encuentran en archivos diferentes, y el archivo del proyecto solo se carga cuando se confía en él.

Un error común es editar el archivo del usuario para establecer el modelo de un proyecto y luego preguntarse por qué otro repositorio lo heredó. La herencia forma parte del diseño: esa edición configuró la máquina, no el árbol de proyectos.

Ajustes del usuario frente a sobrescrituras de proyectos de confianza

La configuración a nivel de usuario se encuentra en ~/.codex/config.toml, el archivo del directorio personal que Codex lee para cada proyecto. Las sobrescrituras para un proyecto de confianza se encuentran en .codex/config.toml en la raíz del repositorio. “De confianza” se refiere a la marca de confianza de proyecto de Codex: las sobrescrituras solo se cargan si el directorio está marcado como de confianza, y un árbol no confiable ignora el archivo local. Eso es un límite de seguridad y no un error; por lo tanto, cuando parezca que el archivo del proyecto no se carga, verifique el estado de confianza antes de depurar el TOML.

Una división razonable mantiene los secretos y la precaución por defecto en el archivo del usuario, y coloca las opciones de modelo y entorno aislado específicas del repositorio en el archivo del proyecto una vez que se confía en la estructura.

Comportamiento del modelo y del razonamiento

Aquí son importantes dos claves: model y model_reasoning_effort. La documentación oficial muestra cómo sobrescribir un proyecto de esta manera:

model = "gpt-5.4-mini"
model_reasoning_effort = "high"

Trate esos valores como ejemplos que se vuelven obsoletos con el tiempo. Las etiquetas de los modelos cambian rápidamente, y una cadena de texto que se vea en una captura de pantalla puede estar desactualizada una semana después. Copie las claves y, a continuación, verifique nuevamente los valores contra la documentación actual antes de guardarlos en un repositorio. El plugin también acepta la abreviatura spark, que se corresponde con gpt-5.3-codex-spark; esa correspondencia está documentada pero también es perecedera, y si en una versión posterior del README se elimina, debe seguirse lo indicado en dicho documento.

model_reasoning_effort = "high" no es un control de calidad ilimitado, ya que un nivel más alto consume más tokens en cada turno. Guárdelo para desafíos de diseño o fallos graves en pruebas, y no lo mantenga activo para una simple renombración de una línea.

Aprobaciones y entorno aislado

Una guía de ShakaCode de terceros documenta las anulaciones interactivas y las claves de entorno que el README oficial del plugin no destaca, por lo que deben considerarse como orientación de terceros. approval_policy controla cuándo Codex pregunta antes de actuar, siendo untrusted y on-request los valores mencionados. sandbox_mode limita lo que el proceso puede modificar, y las opciones indicadas son read-only, workspace-write y danger-full-access.

approval_policy = "untrusted"
sandbox_mode = "workspace-write"

En la guía citada este es el perfil estándar para trabajar con funcionalidades: Codex puede escribir dentro del espacio de trabajo pero aún así solicita permiso antes de actuar, como si el árbol solo fuera parcialmente confiable. Reserva danger-full-access para ejecutores de pruebas y scripts de compilación en los que ya confíes, y nunca lo uses al examinar por primera vez un repositorio desconocido.

En la CLI, codex --auto-edit sigue solicitando confirmación antes de ejecutar el shell, mientras que codex --full-auto se ejecuta completamente en un entorno aislado sin ninguna solicitud. Estas opciones modifican el comportamiento de las solicitudes y no son sinónimos, así que no uses --full-auto solo porque suene más decisivo.

A menudo la gente instala un segundo plugin para no perderse alguna funcionalidad, cuando en realidad lo que falta es una decisión del usuario que debe tomarse antes de ejecutar la primera orden.

Una única fuente de verdad del proyecto para ambos agentes

Dos agentes en un mismo árbol sin instrucciones compartidas inventarán dos estilos de código para el jueves. Es de esperar reglas repetidas, comandos de prueba duplicados y una revisión que anule una convención que el otro agente acababa de restablecer. Codex toma sus reglas de repositorio de AGENTS.md, un archivo Markdown, mientras que CLAUDE.md es el archivo correspondiente para Claude Code. Lo que se necesita es una política que defina cómo se relacionan ambos, ya que nada los mantiene alineados a menos que alguien lo haga.

La descripción más bien documentada de las opciones es claude-code-with-codex.md de ShakaCode. Está fechada según los nombres de los modelos, por lo que úsela para la estrategia de archivos y no para las etiquetas de modelo predeterminadas.

Referirse a un único archivo de instrucciones

Coloque los comandos de compilación, las notas de arquitectura y las convenciones en AGENTS.md, y convierta CLAUDE.md en un indicador:

# Project Instructions
See @AGENTS.md for build commands, architecture, and conventions.

Quedan dos archivos, y las notas específicas para Claude aún pueden encontrarse debajo del puntero. El costo radica en el mantenimiento, ya que olvidar actualizar el puntero hace que Claude siga un archivo incompleto. También se puede indicar a Codex que recurra a una solución alternativa cuando falte AGENTS.md, a través de ~/.codex/config.toml:

project_doc_fallback_filenames = ["CLAUDE.md", "COPILOT.md"]

Eso es una ruta de lectura y no una fusión. Codex buscará esos nombres de archivo, pero no combinará tres archivos en una sola política.

Vincular con enlace simbólico las reglas universales

La versión rápida consiste en un único comando:

ln -s AGENTS.md CLAUDE.md

Un inode, dos nombres: así las reglas universales permanecen idénticas. Sin embargo, existe un compromiso real: no se pueden mantener separadas las directivas específicas de cada herramienta, ya que ya no existe un segundo archivo. Si Claude necesita un gancho que Codex nunca debería ver, un enlace simbólico no puede expresarlo.

Mantener un núcleo compartido más adiciones específicas de la herramienta

Las reglas que deben ser idénticas, como la orden de prueba, los ajustes de lint y la instrucción “no reescribir el formato”, deben ir en AGENTS.md, mientras que las notas exclusivas para Claude o Codex se colocan en CLAUDE.md. Es la opción más madura, pero requiere un mantenimiento deliberado; por eso algunos equipos la omiten y luego culpan a los modelos por las desviaciones.

Si ambos agentes van a editar al mismo tiempo, las instrucciones compartidas no son suficientes. Aíslen sus árboles de trabajo, utilizando git worktrees como herramienta habitual, para que no compitan por un mismo índice. Las escrituras simultáneas en una única copia generan conflictos de fusión que ninguno de los agentes causó intencionadamente.

Revisiones, desafíos, rescates y trabajo en segundo plano

Con el plugin cargado, surge la tentación de automatizar todo. La mejor práctica es utilizar el comando más sencillo adecuado para la tarea, ya que una revisión de solo lectura no constituye implementación y la implementación no es un argumento de diseño.

Revisión simple o revisión adversarial

/codex:review inicia una verificación de corrección de solo lectura de los cambios locales no confirmados o de una base especificada. Acepta --base <ref>, --wait y --background, y nunca escribe archivos.

/codex:review --background

/codex:adversarial-review es un desafío de diseño orientable que cuestiona las decisiones, y el texto libre puede seguir a los marcadores.

/codex:adversarial-review --base main challenge whether this was the right caching and retry design

En la ruta inversa, los equivalentes son $cc:review y $cc:adversarial-review, que realizan las mismas tareas pero en un host diferente. No mezcle los prefijos. Una revisión que solo señala detalles menores sobre el orden de importación no constituye una verdadera revisión; por lo tanto, incluya la pregunta funcional en el comando. Si no puede formularla, aún no está listo para realizar una ronda de razonamiento.

Entrega de una solución mediante rescue

/codex:rescue transfiere el trabajo de implementación al subagente del plugin codex:codex-rescue, y a diferencia de los comandos de revisión, modifica archivos. Sus flags incluyen --background, --wait, --resume y --fresh.

/codex:rescue fix the failing test with the smallest safe patch

El gemelo inverso es $cc:rescue. Mantén la solicitud específica, ya que decir “hazlo mejor” te llevará a una reescritura que no querías y a un ciclo de revisiones del que no puedes salir.

Rastreo y control de tareas en segundo plano

Por “en segundo plano” se entiende que la tarea del plugin sigue ejecutándose mientras continúas usando Claude Code. No se trata de un proceso de pago adicional, ni implica que el trabajo esté terminado.

/codex:status
/codex:result
/codex:cancel

/codex:status informa sobre el estado de las tareas en segundo plano, /codex:result muestra su salida y /codex:cancel las detiene. Realice consultas de forma intencionada y no interprete el silencio como éxito. El plugin inverso ofrece las tres funciones equivalentes como $cc:status, $cc:result y $cc:cancel; nuevamente, el anfitrión decide el prefijo.

Transferencia de contexto y creación de un bucle de transferencia limitado

Una revisión en Claude Code no es lo mismo que una sesión de Codex que permite ver el razonamiento anterior, y cuando un hilo de depuración ya es largo, copiar y pegar hace que la información se pierda. /codex:transfer es la solución documentada. No existe una sincronización de estado perfecta; lo que se obtiene es un hilo de Codex persistente y una orden para imprimir el resumen, de modo que la conversación puede transitar entre ambos sin que una persona actúe como intermediario.

Reanudar en Codex después de una transferencia

/codex:transfer busca la transcripción de origen en ~/.claude/projects, y si el archivo JSONL no está allí, la transferencia no puede crearlo. Lo que muestra está destinado a ejecutarse en la aplicación Codex o en la TUI:

codex resume <session-id>

Utilice el ID de sesión que emite la orden, nunca uno inventado ni una URL de conversación de ChatGPT pegada.

Planificar, implementar, revisar, entregar

El ciclo que realmente mantiene todo en marcha es aburrido:

1. Planifique en Claude Code y escriba primero la línea de aceptación.
2. Implemente, ya sea en Claude Code o mediante /codex:rescue cuando el parche esté delimitado.
3. Revise con /codex:review o /codex:adversarial-review, uno por uno.
4. Devuelva el control para que una persona lo apruebe, rechace o lo escalone.

El proceso debe terminar. Un círculo que siempre vuelve a “una pasada más” convierte la etapa de revisión en un infierno.

Detener el ciclo interminable de revisión: un protocolo para conflictos y presupuestos

La función destinada a mejorar la calidad puede agotar el presupuesto debido a cuestiones de gusto. Al ejecutar /codex:setup --enable-review-gate se añade un gancho local llamado Stop, es decir, un gancho al final de cada turno: una vez que Claude intenta finalizar, se le pide a Codex que verifique el resultado antes de permitir que el turno termine. Si Codex encuentra problemas, se bloquea a Claude para que pueda solucionarlos. Al no haber nadie supervisando, ese bucle circular puede consumir tokens rápidamente. La documentación oficial advierte sobre esto, pero no ofrece ningún protocolo para gestionar el presupuesto.

El límite de tres iteraciones mencionado anteriormente es una guía editorial basada en esa deficiencia y no es una función oficial del plugin. No existe ninguna bandera --max-iterations 3 que buscar.

Defina primero la aceptación funcional

Escribe la lista de obstáculos antes de que alguien los revise, y manténla funcional: pruebas que deben superarse, comportamientos que no deben deteriorarse, y problemas de seguridad o datos que constituyen rechazos automáticos. El formato, el estilo de los comentarios y el nivel de los encabezados no son obstáculos a menos que el archivo de instrucciones del repositorio ya los prohíba. Incluye los criterios estilísticos en la puerta de control, y dos agentes pasarán tres turnos discutiendo si un encabezado debe ser H2 o H3, aunque la página ya estuviera correcta. Al no haber una definición clara de lo que se considera terminado, la puerta de control la inventó. Almacena la lista de verificación en AGENTS.md, donde ambos agentes vean reglas idénticas. Repetirla en la orden de revisión está bien, pero una solicitud vaga como “hazlo más limpio” invita a una reescritura.

Un caso de advertencia: al tener activada la puerta de control en un commit solo de documentos, los dos agentes debatieron si un encabezado debía ser H2 o H3 hasta que la sesión se interrumpió, aunque la página ya estuviera correcta. Al no existir una definición clara de lo terminado, la puerta de control la creó ella misma. Guarda la lista de verificación en AGENTS.md, donde ambos agentes vean reglas idénticas. Repetirla en la orden de revisión está bien, pero una solicitud vaga como “hazlo más limpio” invita a una reescritura.

Iteraciones de capa y toma de decisión humana obligatoria

Limítese a tres rondas de revisión y corrección por cada cambio:

• Iteración 1: únicamente obstáculos funcionales.
• Iteración 2: cualquier obstáculo restante, sin nuevos problemas de estilo.
• Iteración 3: la última pasada, y luego se detiene.

Después de tres rondas, una persona decide si fusionar, revertir o reescribir la especificación, y los agentes no pueden votar nuevamente. Los hilos de la comunidad sobre envoltorios de tmux y scripts personalizados cuentan como evidencia experimental y no como un segundo camino oficial; por lo tanto, trate esos scripts como el trabajo de otra persona y no como comandos de OpenAI.

Deténgase cuando no haya cambios reales

El plugin inverso de Sendbird toma una huella digital del árbol de trabajo y omite la revisión al final de turno siempre que el turno anterior en Codex no haya cambiado nada en términos netos. Esa medida de seguridad está documentada para la ruta inversa, pero el control de seguridad del sistema principal no indica esa misma omisión. En la ruta oficial, tú eres la huella digital: si git status muestra que todo está en orden, se omite otra revisión; y si el último turno solo modificó comentarios, se verifica si dichos comentarios estaban en la lista de aceptación y se detiene el proceso si no lo están.

Espera a automatizar el control de seguridad hasta que una revisión manual haya completado la lista de verificación. Activa --enable-review-gate al final, nunca al principio.

Solución de problemas por ruta, autenticación, confianza y tareas obsoletas

Diagnostique la ruta antes de reinstalar cualquier cosa. Los fallos en la ruta oficial upstream y los fallos en los ganchos del plugin inverso se parecen en un mensaje de chat frustrado, pero no corresponden al mismo sistema. La reinstalación casi nunca es la primera medida a tomar.

La ruta oficial upstream

• Comandos del plugin no disponibles: ejecute /reload-plugins. Si siguen faltando, confirme que /plugin install codex@openai-codex realmente se completó, y luego ejecute /codex:setup.
• Codex no puede autenticarse: escriba !codex login tal como se describe en el flujo de Claude Code. El plugin lee el estado de autenticación local, y una pestaña del navegador de ChatGPT con sesión iniciada no equivale a una CLI con sesión iniciada.

Se han ignorado las sobrescripciones del proyecto: verifica que el proyecto sea de confianza y que la edición se haya realizado en .codex/config.toml en la raíz del repositorio y no solo en el archivo del directorio personal.

Transfer no puede encontrar la transcripción: el archivo JSONL debe encontrarse en ~/.claude/projects; una sesión que nunca escribió allí no puede transferirse. Primero inicia una verdadera sesión de proyecto en Claude Code.

Tareas en segundo plano obsoletas: utiliza /codex:status, luego /codex:result o /codex:cancel, y no inicies una segunda operación de rescate solo porque la primera dejó de responder.

Errores en la versión de Node: el complemento requiere 18.18 o una versión más reciente; por lo tanto, ejecuta node -v antes de abrir un problema.

Ganchos del complemento inverso y confianza en el caché

Si los ganchos inversos no se ejecutan, establezca hooks = true bajo [features] en ~/.codex/config.toml. Si la configuración inversa parece incompleta, ejecute $cc:setup, que tiene como objetivo confirmar los ganchos, validar las cachés y las rutas de escritura. Para el complemento comunitario, $claude setup es la verificación propia de ese proyecto, y como no es oficial, sus fallos no deben reportarse en relación con openai/codex-plugin-cc. La compatibilidad con Windows en la ruta de Sendbird está marcada como experimental en su repositorio, por lo que un espacio de trabajo WSL es la mejor opción si el objetivo es utilizar el complemento inverso.

Respuestas rápidas a las preguntas más frecuentes

¿Existe una forma correcta de combinarlos? No realmente. La primera decisión es determinar qué herramienta albergará la sesión. Con Claude Code como anfitrión, el complemento de OpenAI, junto con archivos de instrucciones compartidos y tareas cortas mediante comandos, son suficientes. Con Codex como anfitrión, el complemento inverso de Sendbird y su prefijo $cc: realizan la misma función desde el otro lado. Es mejor mantener estos dos procedimientos separados y evitar que ambos agentes accedan a los mismos archivos al mismo tiempo.

¿Qué se escribe exactamente para instalar el plugin oficial? Cuatro líneas en la ventana de Claude Code, en orden: la adición al mercado para openai/codex-plugin-cc, la instalación de codex@openai-codex, una recarga del plugin y /codex:setup. Si la CLI de Codex aún no está en la máquina, la configuración puede ofrecer descargarla, o puedes instalar @openai/codex por tu cuenta con antelación e iniciar sesión con !codex login.

¿El plugin trae su propio backend de Codex? No. Todo se dirige a la CLI de Codex y al servidor de aplicaciones que ya están en tu ordenador, por lo que se aplica el mismo inicio de sesión y el mismo plan de ChatGPT o clave API. Cualquier acceso que necesite esa CLI, sigue necesitándolo.

¿Cuál es la forma más limpia de aplicar las mismas reglas a ambos agentes? Funcionan tres patrones: hacer que CLAUDE.md apunte a AGENTS.md, crear un enlace simbólico entre ambos o colocar el núcleo compartido en AGENTS.md y dejar los elementos adicionales específicos de la herramienta en CLAUDE.md. Una configuración de nombre de archivo de respaldo en la configuración del usuario permite a Codex leer el archivo de Claude cuando AGENTS.md no está presente. El enlace simbólico es el más rápido, pero con la desventaja de perder los archivos específicos de la herramienta.

¿Dónde se establece la elección del modelo para cada proyecto? En un .codex/config.toml en la raíz de un proyecto que hayas marcado como confiable, utilizando las claves model y model_reasoning_effort. Los valores de ejemplo de la documentación, como gpt-5.4-mini y high, se actualizan con rapidez, así que revísalos. Un proyecto no confiable recurre silenciosamente a los valores predeterminados del usuario.

¿Qué función tiene la puerta de revisión? Al activarla se registra un gancho Stop local. Cuando Claude intenta finalizar una ronda, Codex verifica primero el trabajo realizado, y cualquier problema detectado bloquea la ronda para que Claude pueda solucionarlo. Sin supervisión, esto puede consumir tokens. El complemento inverso puede omitir una revisión cuando no hay cambios en el árbol de trabajo, pero ese es su propio comportamiento y no algo que prometa la versión original.

¿Cómo se transfiere una sesión? Ejecute /codex:transfer en Claude Code. Esto convierte la transcripción guardada en ~/.claude/projects en un hilo persistente de Codex y muestra una línea codex resume con el ID de la sesión, que luego puede ejecutarse en la aplicación Codex o en la TUI. Si no hay transcripción en esa carpeta, no hay nada que transferir.

¿Cómo evito que estos dos quemen tokens? Defina de antemano criterios de aceptación relacionados únicamente con la funcionalidad, permita tres rondas de revisión y corrección, y luego involucre a un humano. Active la barrera solo después de que se haya completado una revisión manual. Si git status muestra un árbol limpio, o si la última ronda solo modificó aspectos estilísticos y nadie lo señaló como obstáculo, termine el ciclo usted mismo.

Un primer experimento seguro

Elija un repositorio que ya conozca, así como una prueba fallida o un pequeño cambio para revisar; primero haga commit o stash. Instale únicamente la ruta oficial y ejecute /codex:review con ese cambio. Lea el resultado, luego aplíquelo o rechácelo usted mismo, y deje --enable-review-gate desactivado la primera tarde.

Si la reseña resulta útil, comparta AGENTS.md a continuación e intente ejecutar un único /codex:transfer en un hilo de depuración real. Ese es todo el experimento. Los nombres de los modelos seguirán cambiando, pero la decisión del anfitrión y la condición de parada seguirán siendo relevantes. Lo que aún no está claro es cuánto tiempo soportarán los equipos dos facturas y dos archivos de instrucciones antes de que alguien vuelva a solicitar un único proveedor. Por ahora, la versión sensata de esta estructura es una campana con reglas del hogar y no un compañero de piso con llave.

Lecturas relacionadas

• Usando Codex en VS Code: ámbito, puntos de recuperación y soluciones para los cuellos de botella habituales — Una guía práctica a través de la extensión Codex para VS Code: instalación, inicio de sesión, una primera tarea del agente con límites definidos, uso en la nube frente a la CLI, configuración compartida y soluciones para WSL, aprobaciones y autenticación remota.
• Reconstruyendo un agente al estilo Claude Code con LangChain Deep Agents — Cómo funciona el mecanismo de un agente de programación, desde el bucle principal hasta las herramientas, la planificación, la memoria, los subagentes y las aprobaciones en entorno aislado, reconstruido paso a paso con deepagents.

Codex Inside Claude Code: Revisión intermodelo con codex-plugin-cc — El codex-plugin-cc de OpenAI permite que un segundo modelo revise el código escrito por Claude Code. Conozca los comandos, la función de revisión, los pasos de configuración, los costos y las consideraciones de privacidad.