Abre en Cursor un proyecto cuyo código conozcas y elige un archivo corto. La meta de esta primera sesión no es comprobar que aparece un icono, sino cerrar un ciclo completo: aportar un contexto deliberado, obtener una propuesta limitada y decidir sobre ella después de revisar y probar el cambio.
No empieces con una refactorización ni con una petición abierta sobre todo el repositorio. Instala la extensión oficial, localiza su barra lateral y completa dos pruebas: primero una explicación sin modificar archivos y después, si la respuesta coincide con el código visible, un cambio pequeño y reversible.
Instala la extensión oficial y abre su barra lateral
OpenAI incluye Cursor entre los editores compatibles con su extensión de Codex para IDE y mantiene en la documentación oficial de Codex para IDE el acceso a la extensión para Cursor. Empieza desde esa página para comprobar que instalas el producto correcto.
Con el proyecto abierto en Cursor:
- Sigue el enlace de instalación que aparece en la documentación oficial.
- Comprueba en la vista de extensiones de Cursor que Codex está instalado y habilitado para la ventana actual.
- Inicia sesión o completa el acceso que solicite la interfaz. Las condiciones pueden variar según la cuenta, la organización, la región, la red y la versión instalada.
- Abre la paleta de comandos y ejecuta
Codex: Open Codex Sidebar. Si el icono de Codex ya está visible, también puedes abrir la barra lateral desde allí.
La ubicación del icono puede cambiar entre versiones; si no lo encuentras, busca el comando documentado en la paleta. La instalación queda operativa cuando la barra lateral de Codex se abre dentro de Cursor y permite escribir una petición. Eso todavía no demuestra que el contexto sea el correcto: la siguiente prueba sirve precisamente para confirmarlo.
Prepara una prueba que puedas deshacer
Antes de pedir una modificación, revisa el estado actual del proyecto. OpenAI recomienda crear puntos de control de Git antes y después de la primera tarea en el IDE para poder inspeccionar y revertir cambios; la recomendación figura en la misma guía oficial. Para esta prueba basta con un repositorio Git local: el punto de control no depende de un proveedor remoto.
Si el proyecto ya usa Git, comprueba qué archivos tienen cambios pendientes y evita mezclar trabajo anterior con la prueba. Si no usa Git, duplica el archivo de ensayo o elige un proyecto desechable. En ambos casos, no uses para la prueba archivos con secretos, credenciales ni datos personales.
Escoge una función breve que tenga entradas y un resultado fáciles de reconocer. Una buena candidata puede ser una validación, un formateador o una utilidad pequeña. Evita empezar por una migración, una actualización de dependencias o una petición abierta como «mejora todo el proyecto»: cuanto más amplio sea el encargo, más difícil será atribuir cada cambio a una necesidad concreta.
Verifica el contexto sin permitir cambios
La extensión puede utilizar archivos abiertos y código seleccionado como contexto, según la documentación de Codex para IDE. Abre el archivo elegido, selecciona la función y pide una explicación cuya precisión puedas contrastar con ese fragmento:
textExplica qué hace el código seleccionado, qué entradas espera y qué caso límite debería revisar. No modifiques ningún archivo.
Contrasta la respuesta con el código. Busca referencias correctas a nombres de parámetros, condiciones, dependencias o valores de retorno. Una explicación genérica sobre el lenguaje o el tipo de función no demuestra que se haya utilizado la selección.
Si la respuesta no contiene detalles verificables, reduce la selección y vuelve a intentarlo con una pregunta más concreta. También puedes cerrar y abrir de nuevo el archivo antes de repetir la prueba. No avances a una modificación mientras no puedas relacionar la respuesta con el fragmento visible.
Cuando no necesites seleccionar un bloque, puedes comprobar el contexto del archivo abierto con una petición distinta:
textResume la responsabilidad del archivo abierto y señala de qué módulos locales depende. No propongas cambios todavía.
No es necesario que Codex reconstruya toda la arquitectura del repositorio. La señal útil es más modesta: que sus afirmaciones sobre el archivo puedan confirmarse leyendo ese mismo archivo y sus importaciones.
Encarga un cambio pequeño con límites explícitos
Después de validar el contexto, define un resultado observable y restringe el área que puede cambiar. Por ejemplo, si la función seleccionada devuelve un mensaje poco claro cuando falta un argumento, podrías pedir:
textModifica solo la función seleccionada para que el error indique qué argumento falta. Conserva el comportamiento actual para las entradas válidas y muéstrame los cambios para revisarlos antes de aceptarlos.
Una petición controlable incluye cuatro datos: el archivo o fragmento afectado, el comportamiento deseado, lo que debe conservarse y la forma de comprobar el resultado. Estos límites no garantizan que la propuesta sea correcta, pero hacen visible cualquier desvío de alcance.
Codex puede presentar los cambios para revisarlos dentro del editor. Antes de aceptar una propuesta, comprueba:
- qué archivos se han tocado;
- si el cambio se limita a la función indicada;
- si conserva el comportamiento que pediste mantener;
- si añade dependencias, archivos o modificaciones laterales que no solicitaste;
- si puedes explicar cada línea modificada y cómo contribuye al resultado.
Rechaza o cancela una propuesta demasiado amplia. No intentes salvarla aceptando primero y limpiando después: divide el encargo y vuelve a pedir un único cambio. Mantener pequeño el primer ciclo facilita distinguir un problema de contexto de una instrucción ambigua.
Comprueba el resultado con las herramientas del proyecto
La revisión del diff es necesaria, pero no sustituye las comprobaciones existentes. Ejecuta la prueba, el analizador estático, el compilador o el comando de formato que ya utilice el proyecto. Si no existe una prueba automatizada para esa función, reproduce al menos el caso válido anterior y el nuevo caso de error.
Una respuesta convincente no demuestra que el código funcione. Da por superada la primera tarea solo cuando puedas observar esta cadena completa:
| Paso | Señal que puedes comprobar |
|---|---|
| Apertura | La barra lateral de Codex se abre dentro de Cursor. |
| Contexto | La respuesta se apoya en nombres y comportamientos reales del archivo o de la selección. |
| Alcance | La propuesta respeta el archivo, la función y las condiciones indicadas. |
| Revisión | Puedes inspeccionar los cambios antes de decidir si los incorporas. |
| Verificación | Las comprobaciones propias del proyecto confirman el resultado o revelan qué falta. |
Si alguna señal falla, detente en ese paso. Reinstalar la extensión no resolverá una petición imprecisa, y reformular la petición no arreglará una extensión deshabilitada.
Recupera el flujo según el síntoma
No aparece Codex en Cursor
Abre la vista de extensiones y confirma que la extensión enlazada desde la documentación de OpenAI está instalada y habilitada. Si Cursor ofrece recargar la ventana, hazlo y busca de nuevo Codex: Open Codex Sidebar en la paleta de comandos. Si la documentación o la interfaz actual muestran un nombre o una ubicación distintos, toma la documentación vigente como referencia.
La barra lateral se abre, pero bloquea el acceso
Lee el mensaje mostrado y completa únicamente el flujo de cuenta u organización que indique. No se puede deducir desde la instalación qué plan, cuota o disponibilidad corresponde a una cuenta concreta. Si el aviso no es claro, consulta la documentación enlazada desde la propia interfaz antes de cambiar configuraciones locales.
La respuesta ignora el código seleccionado
Confirma que escribes en la barra lateral de Codex, mantén abierto el archivo correcto y reduce la selección a un bloque autocontenido. Formula una pregunta que requiera citar un parámetro, una condición o un valor de retorno presente en ese bloque. Si la respuesta sigue siendo genérica, termina la prueba sin aplicar cambios y revisa la versión y el estado de la extensión.
La propuesta modifica demasiado
No la aceptes. Reduce la tarea a un archivo, una función y un comportamiento observable. Si incluso ese encargo produce cambios laterales, pide una explicación sin modificaciones o trabaja en una rama o copia desechable hasta entender el alcance.
El cambio parece correcto, pero falla la verificación
Conserva el error exacto y el diff. Pide que se explique la causa a partir de esos datos antes de autorizar otra modificación. Si el fallo afecta dependencias, configuración o varias áreas del repositorio, deja de tratarlo como una primera prueba y planifica el trabajo con sus propias comprobaciones y límites.
Cierra la primera sesión con un estado conocido
Revisa el diff completo y decide qué conservar. Si el cambio aporta valor y supera las comprobaciones del proyecto, crea un nuevo punto de control de Git con una descripción concreta. Si no lo hace, revierte la propuesta y vuelve al estado inicial.
La sesión termina bien cuando vuelves a un estado que entiendes: o conservas un cambio revisado y verificado, o descartas la propuesta sin arrastrar modificaciones dudosas. Repite este ciclo con una función conocida antes de ampliar el alcance en Cursor: contexto deliberado, tarea acotada, propuesta visible, verificación local y una decisión consciente.
