Conceptos clave de Codex de un vistazo

📚 Navegación de la serie: El artículo anterior 01 · Conoce Codex y sus cuatro interfaces te mostró las cuatro caras de Codex: aplicación de escritorio, línea de comandos, extensión de IDE y en la nube. Este artículo profundiza un nivel más para explicar detalladamente los conceptos clave que se utilizarán repetidamente en los capítulos siguientes. El próximo artículo 03 · Instalación y login te guiará para instalarlo formalmente.

Permíteme contarte una tontería que hice cuando empecé a usar Codex. Quería renombrar en lote tres archivos y le dije directamente: «ayúdame a renombrar estos tres archivos en lote». Codex empezó a hacer modificaciones rápidamente, pero cuando fui a ver, me quedé perplejo: solo había modificado los archivos dentro del directorio del proyecto actual, mientras que los dos archivos en mi escritorio permanecían intactos. En ese momento me pregunté: si se supone que puede ejecutar comandos, ¿por qué es tan selectivo? Más tarde, al revisar la documentación, lo entendí: era el sandbox (aislamiento) el que lo limitaba; de forma predeterminada, solo puede actuar en el espacio de trabajo que especifiques, y para salir de ese límite, debe preguntarte primero.

En ese instante comprendí algo: si no entiendes estos conceptos antes de usar Codex, siempre sentirás que funciona de manera inconsistente. En realidad, no está actuando sin control, sino que tú desconoces las restricciones que tiene activadas.

En este artículo explicaremos detalladamente estas restricciones y algunas de sus configuraciones exclusivas.

Al leer este artículo, obtendrás:

• Una explicación simple de qué es un «agente (Agent)» en Codex y en qué se diferencia de un chatbot convencional.
• Comprensión profunda de la pareja formada por el sandbox y la aprobación: por qué falló mi renombrado de archivos y cómo permitirlo.
• Conocer AGENTS.md: el «manual de bienvenida» para que Codex recuerde las reglas de tu proyecto.
• Saber qué son la memoria (Memory) y Chronicle, si están activadas por defecto y cómo usarlas.
• Un experimento práctico para seguir paso a paso y ver con tus propios ojos cómo te detiene el sandbox.

⚠️ Toda la información sobre comandos específicos, configuraciones y comportamientos predeterminados en este texto se basa en la documentación oficial de Codex; los nombres de los modelos y los planes de suscripción pueden cambiar con las versiones, por lo que debes guiarte por lo que se muestre en tu terminal local.

---

01 Agente (Agent): Actúa por sí mismo, no solo responde con palabras

Para resumir en una frase: Codex es el «agente de programación (coding agent)» de OpenAI, capaz de leer código, modificar archivos y ejecutar comandos de manera autónoma, en lugar de limitarse a responder con texto. La descripción oficial es "OpenAI's coding agent that can read, edit, and run code".

La palabra clave aquí es «agente (Agent)», la cual requiere una breve explicación para quienes la ven por primera vez: un agente es una IA capaz de desglosar tareas, invocar herramientas, analizar resultados y decidir el siguiente paso por sí misma, a diferencia de una ventana de chat de preguntas y respuestas.

La documentación oficial describe la forma de trabajar de Codex de la siguiente manera: «el agente ejecuta comandos de terminal en bucle; edita código, ejecuta comprobaciones e intenta validar su propio trabajo» (texto original: The agent runs terminal commands in a loop. It edits code, runs checks, and tries to validate its work).

Traducido al lenguaje cotidiano, se resume en los tres mismos pasos: Pensar → Actuar → Observar:

• Pensar: leer archivos relevantes, revisar errores y analizar la situación.
• Actuar: modificar código, crear archivos y ejecutar comandos.
• Observar: ejecutar pruebas, revisar salidas y, si no es correcto, volver a empezar una nueva ronda.

Analogía: Un asistente de compras que realiza recados por ti. Un chatbot convencional es como un dependiente que solo consulta precios: si le preguntas «¿cuánto cuesta esta prenda?», te da el precio y listo. Codex es como un asistente de compras: si le dices «ayúdame a comprar una sudadera negra de talla única», él mismo buscará el producto, comparará precios, hará el pedido, abrirá el paquete al recibirlo para verificar la talla y la devolverá si no es correcta. «Completar todo el proceso de forma autónoma» es la diferencia fundamental entre un agente y una ventana de chat.

Algunos escenarios reales con los que te encontrarás:

• Si preguntas «¿por qué falla esta prueba?», él mismo ejecutará la prueba → leerá el error → localizará el bug → lo modificará → ejecutará la prueba de nuevo para confirmar, y tú solo observarás el proceso.
• Si le das un proyecto antiguo sin documentación y le dices «explícame la estructura», él mismo revisará los archivos del directorio actual, buscará palabras clave, leerá varios archivos y finalmente te dibujará un diagrama, sin que hayas tenido que especificar ningún archivo.
• Si le dices «añade caché a esta función», modificará el código y, de paso, revisará los archivos donde se invoca la función, ya que tiene una visión global de los archivos del proyecto.

💡 Resumen en una frase: Codex es un «agente», no una «ventana de chat»; completa las tareas de forma autónoma en un ciclo de «pensar → actuar → observar», un mecanismo idéntico al de Claude Code, solo que con otra interfaz.

---

02 Sandbox (Sandbox): Dónde se dibuja su espacio de actuación

Llegamos al punto importante. El culpable de que fallara mi renombrado de archivos al principio fue precisamente este elemento.

Sandbox (Aislamiento en sandbox): la definición oficial es «la frontera (boundary) que permite a Codex actuar de forma autónoma sin darle privilegios ilimitados sobre toda tu máquina». Explicado con sencillez, es un círculo dibujado alrededor de Codex: dentro del círculo actúa libremente, pero para salir de él, debe pedirte permiso primero.

Analogía: La zona de juegos infantiles en un centro comercial. Dejas al niño dentro del área vallada; puede jugar en el tobogán y en la piscina de bolas sin que tengas que vigilar cada movimiento. Pero si el niño intenta saltar la valla para ir al aparcamiento, sonará una alarma y deberás autorizarlo. El sandbox es esa valla: libertad de acción sin interrupciones dentro del círculo, y control estricto al intentar salir; así se evitan sobresaltos y problemas.

Esta valla controla dos cosas: qué archivos puede modificar y si puede conectarse a internet. La documentación oficial define tres modos comunes de sandbox:

Modo de sandbox	¿Puede modificar archivos?	¿Puede conectarse a internet?	Cuándo usarlo
read-only (Sólo lectura)	❌ No (requiere aprobación previa)	❌	Para que lea código, haga revisiones o proponga soluciones sin tocar nada
workspace-write (Escritura en espacio de trabajo)	✅ Solo dentro del espacio de trabajo	❌ No por defecto	El más común en el desarrollo diario; se recomienda por defecto en directorios bajo control de versiones; en directorios sin control de versiones, el predeterminado es read-only
danger-full-access (Acceso total)	✅ En toda la máquina	✅	Entornos de total confianza. El nombre incluye danger por una razón, úsalo con precaución

¿Ves la indicación «Solo dentro del espacio de trabajo» en la fila de workspace-write? Esa es la razón por la que no se modificaron mis archivos del escritorio: no estaban dentro del directorio del proyecto donde inicié Codex, por lo que quedaban fuera de la valla. No es que Codex fuera perezoso, es que físicamente no podía alcanzarlos.

Hay otro detalle importante en la documentación oficial: el sandbox no solo limita las lecturas y escrituras directas de Codex, sino también los comandos que genera. Esto significa que si invoca a git, un gestor de paquetes o un script de pruebas, estos comandos también estarán limitados dentro del mismo círculo, evitando fugas de seguridad a través de subprocesos.

La implementación varía según la plataforma, algo con lo que te toparás al instalarlo (detalles en el capítulo 03 · Instalación y login):

• macOS: utiliza el framework nativo Seatbelt, listo para usar sin configuraciones adicionales.
• Windows: se ejecuta directamente en el entorno nativo de Windows, utilizando el sandbox nativo de Windows (con modos elevated y unelevated); si se usa WSL2, se sigue la implementación de Linux.
• Linux / WSL2: requiere instalar previamente la herramienta bubblewrap para que el sandbox funcione correctamente (es un requisito previo explícito en las instrucciones oficiales).

💡 Resumen en una frase: El sandbox es la primera restricción de Codex: de forma predeterminada (workspace-write), solo le permite modificar archivos dentro del espacio de trabajo y le prohíbe conectarse a internet; para darle más libertad, debes ampliar el círculo tú mismo.

---

03 Aprobación (Approval): Quién decide cuando se llega al límite

Una vez definido el círculo del sandbox, surge otra cuestión: «¿a quién se le pide permiso al intentar salir?»; esto se gestiona mediante la aprobación (Approval).

Muchos (incluido yo al principio) confunden ambos conceptos. La documentación oficial lo aclara muy bien: el sandbox define los límites técnicos, mientras que la política de aprobación determina cuándo debe detenerse Codex para pedirte permiso antes de cruzar esos límites.

Analogía: Tarjeta de acceso + Guardia de seguridad. El sandbox es la tarjeta de acceso (que físicamente te impide salir), y la aprobación es el criterio del guardia de seguridad en la puerta: algunos guardias dejan pasar a cualquiera (never), otros solo detienen a los desconocidos (untrusted), y otros te preguntarán cada vez que intentes salir (on-request). La puerta es fija, pero el nivel de control del guardia lo configuras tú.

La documentación oficial define tres políticas comunes de aprobación:

Política de aprobación	Comportamiento de Codex	Explicación sencilla
untrusted	Pregunta antes de ejecutar comandos que no estén en la «lista de confianza»	Protege contra comandos desconocidos
on-request	Actúa en el sandbox por defecto, pero se detiene a preguntar al intentar salir	El equilibrio más utilizado
never	No pide aprobación, actúa directamente	Común en automatizaciones; los límites los define el sandbox, requiere acceso total para tener sentido

Nota: untrusted / on-request / never son las tres políticas de aprobación oficiales; son dimensiones independientes del modo de sandbox, por lo que se configuran y se entienden por separado.

¿Cómo se combinan? La documentación oficial sugiere dos combinaciones listas para usar:

• Automatización local de bajo riesgo (recomendada para el día a día): sandbox_mode = "workspace-write" con approval_policy = "on-request". Los límites están bloqueados y solo pregunta al intentar salir; seguro y práctico.
• Acceso total libre (usar con precaución): sandbox_mode = "danger-full-access" con approval_policy = "never". Es equivalente a quitar la puerta y dar vacaciones al guardia; úsalo solo en entornos de absoluta confianza.

Mi recomendación personal: en proyectos nuevos o bases de código desconocidas, usa siempre read-only al principio para que analice y proponga soluciones; una vez que entiendas su plan, cambia a workspace-write para permitirle actuar. En una ocasión, por comodidad, utilicé danger-full-access para un script en lote y ver a Codex examinar archivos en la mitad de mi directorio de usuario me hizo sudar frío; desde entonces, no he vuelto a usar el acceso total fuera de entornos estrictamente necesarios.

¿Cómo cambiarlo? En el día a día no necesitas modificar archivos de configuración; en una sesión de CLI puedes cambiar el modo escribiendo /permissions (en la aplicación de escritorio y los IDE se selecciona desde el control de permisos junto al cuadro de entrada). Si quieres que se aplique siempre al iniciar, configúralo en el archivo de configuración; esto lo detallaremos en el capítulo 18 · Explicación detallada de config.toml.

El siguiente diagrama ilustra la relación entre el sandbox y la aprobación:

Este flujo aclara una regla: cada vez que Codex realiza una acción, primero verifica «si está dentro del círculo del sandbox» (gestión del sandbox), y si está fuera, verifica «si debe preguntarte» (gestión de la aprobación). Dos filtros independientes.

💡 Resumen en una frase: El sandbox gestiona el «qué puede hacer» y la aprobación gestiona el «si debe preguntar»; son dos controles independientes. Para el día a día, la combinación de workspace-write + on-request garantiza seguridad y comodidad.

---

04 AGENTS.md: El manual de bienvenida del proyecto para Codex

Las secciones anteriores trataban sobre los «permisos». Esta sección aborda otro tema clave: cómo hacer que Codex recuerde las reglas de tu proyecto para no tener que explicárselas en cada nueva conversación.

La solución es el archivo AGENTS.md.

Analogía: El manual de bienvenida para nuevos empleados. Cuando llega un nuevo programador a la empresa, no estás detrás de él repitiendo a diario «usamos pnpm en lugar de npm» o «los mensajes de commit deben ser en español»; le entregas un manual y él lo lee. AGENTS.md es ese manual para Codex: lo colocas en el proyecto, y él lo leerá al comenzar a trabajar para seguir sus reglas.

La documentación oficial lo define como «durable project guidance» (guía duradera del proyecto): directrices persistentes que acompañan al repositorio y se aplican antes de que el agente comience a trabajar. Una recomendación importante: mantenlo breve (Keep it small), evita escribir textos largos y complejos.

Por lo general, contiene la siguiente información (ejemplos oficiales):

• Comandos de construcción y pruebas (por ejemplo, «las pruebas se ejecutan con pytest -q»).
• Expectativas de calidad (por ejemplo, «ejecutar el linter después de hacer cambios»).
• Convenciones específicas del repositorio (por ejemplo, estructura de directorios o reglas de nomenclatura).

Se puede ubicar en dos niveles, donde el más cercano al directorio de trabajo tiene prioridad:

Nivel	Ubicación	Ámbito de aplicación
Global	~/.codex/AGENTS.md	Tus preferencias personales (como «sé breve al responder»), se aplica a todos los proyectos
Proyecto	Directorio raíz del repositorio o subdirectorios	Las reglas del proyecto o del equipo; se integra en Git para compartirse con el equipo

La documentación oficial destaca un uso excelente que también es mi favorito: utilizarlo como un bucle de retroalimentación (feedback loop). Cuando Codex asuma algo incorrecto sobre tu base de código, en lugar de corregirlo solo en el chat (lo cual se perdería al cerrar la sesión), pídele directamente que escriba esa corrección en el AGENTS.md; de este modo, las futuras sesiones la heredarán automáticamente. Tras ajustar un proyecto de Python durante dos semanas, mi AGENTS.md creció de estar vacío a tener unas veinte líneas, registrando cada error que cometió y que yo corregí; ahora, las nuevas sesiones casi nunca repiten los mismos fallos.

AGENTS.md en Codex es equivalente a CLAUDE.md en Claude Code; es el mismo concepto con un nombre de archivo diferente.

💡 Resumen en una frase: AGENTS.md es el manual de bienvenida del proyecto para Codex: escribe allí las reglas de tu base de código y él las leerá al comenzar; utilízalo como un bucle de retroalimentación registrando correcciones para que el sistema aprenda y mejore con el uso.

---

05 Memoria (Memory) y Chronicle: ¿Puede «recordarte»?

Por último, explicamos dos conceptos recientes de Codex que suelen generar confusión: ¿puede recordar lo que hablaron en conversaciones anteriores?

Diferenciemos ambos términos:

Memoria (Memory): permite a Codex transferir información útil aprendida en sesiones anteriores a trabajos futuros (como tu stack tecnológico, las convenciones del proyecto o errores superados), para no tener que explicárselo todo en cada nueva sesión.

Analogía: Un compañero de equipo con experiencia. A un asistente nuevo tienes que repetirle constantemente «usamos TypeScript sin punto y coma»; a un compañero que lleva tres años a tu lado le basta con una mirada porque recuerda tus hábitos. Memory busca transformar a Codex de un «asistente nuevo» a un «compañero con experiencia».

Sin embargo, debes conocer algunos hechos clave para no frustrarte pensando que funciona de manera inconsistente:

• Está desactivada por defecto (off by default). Si no la activas, no recordará nada. Para activarla: ve a la configuración de la aplicación de Codex o añade memories = true en la sección [features] de ~/.codex/config.toml.
• Tiene restricciones regionales. La documentación oficial especifica que en su lanzamiento no está disponible en el Espacio Económico Europeo, el Reino Unido y Suiza.
• No se actualiza en tiempo real. Espera a que una sesión permanezca inactiva el tiempo suficiente para confirmar que has terminado de trabajar, y entonces resume la memoria en segundo plano; por ello, la memoria de una sesión recién cerrada puede tardar en estar disponible.
• Se guarda localmente: de forma predeterminada se almacena en ~/.codex/memories/ en formato markdown.
• Control por sesión: en la aplicación y en la CLI puedes usar /memories para decidir si la sesión actual debe usar las memorias existentes o generar nuevas memorias.

La documentación oficial añade una advertencia importante: las reglas críticas del equipo deben escribirse en AGENTS.md, no confíes en la memoria; la memoria es una capa de ayuda local complementaria, no la fuente única de reglas. Mi experiencia lo confirma: la memoria funciona por probabilidad; si confías en ella para reglas críticas, tarde o temprano fallará.

💡 Resumen en una frase: La memoria es el modo «compañero experimentado», pero está desactivada por defecto, tiene límites regionales y no debe reemplazar a AGENTS.md.

Hablemos de Chronicle, aclarando de antemano:

⚠️ Función experimental, sujeta a cambios. Chronicle es actualmente una «vista previa de investigación bajo activación voluntaria (opt-in research preview)», disponible únicamente para usuarios de ChatGPT Pro en macOS, y no está disponible en la UE, el Reino Unido ni Suiza.

Chronicle alimenta la memoria con lo que ves en pantalla. Mientras que la memoria aprende de las conversaciones con Codex, Chronicle va más allá y analiza el contenido de tu pantalla para entender en qué estás trabajando (qué archivo estás editando, qué PR estás revisando o qué documentación estás leyendo), ayudando a Codex a seguirte el ritmo sin necesidad de explicaciones iniciales.

Analogía: Un compañero que puede ver tu pantalla. Un compañero común solo te escucha; Chronicle, además, puede echar un vistazo a tu monitor: «ah, estás revisando este error», por lo que no necesitas explicárselo. Suena fantástico, pero tiene costes reales. La documentación advierte de tres aspectos: consume cuota rápidamente, aumenta el riesgo de inyección de prompts (prompt injection) y las memorias se almacenan sin cifrar en tu máquina local. En resumen: la comodidad y los riesgos están sobre la mesa, debes evaluarlos tú mismo. Mi postura: sirve para probar; ante contenidos sensibles en pantalla (contraseñas, mensajes privados, datos de clientes), recuerda usar la opción «Pause Chronicle» en la barra de menú para pausarlo.

Dimensión	Memoria (Memory)	Chronicle
Origen de la información	Conversaciones anteriores	Contenido de tu pantalla
Madurez de la función	Función oficial (desactivada por defecto)	Vista previa de investigación (experimental)
Plataforma	Disponible en la App y CLI	Solo macOS, solo usuarios Pro
Recomendación	Actívala si quieres simplificar tareas	Úsala para probar; paúsala en entornos sensibles

💡 Resumen en una frase: La memoria ayuda a Codex a pasar de «novato» a «compañero experimentado», pero está desactivada por defecto, tiene restricciones de región y no reemplaza a AGENTS.md; Chronicle es una mejora experimental que «mira la pantalla», muy cómoda pero con riesgos asociados.

---

Explicados los cinco conceptos por separado, veámoslos integrados en un diagrama antes de pasar a la práctica; entenderlos por separado es sencillo, pero la clave está en cómo colaboran:

Este diagrama lo aclara: el «agente» en el centro es el protagonista, que trabaja delimitado por el círculo del «sandbox»; para salir a la máquina o a internet, debe pasar por el filtro de «aprobación». A la izquierda, AGENTS.md le enseña las reglas del proyecto al comenzar; abajo, la memoria y Chronicle le ayudan a acumular experiencia para futuras sesiones. Los cinco conceptos giran en torno al agente central.

---

06 Práctica: Ver con tus propios ojos cómo te detiene el sandbox

La teoría no basta. Hagamos un experimento rápido de un minuto para ver cómo el sandbox detiene una escritura en el modo read-only; esta práctica te dará una idea muy clara de cómo funciona. No necesitas ningún proyecto existente, basta con crear una carpeta vacía.

Paso 1: Crear un directorio vacío y arrancar Codex.

Ejecuta en tu terminal (para Mac / Linux; en Windows con PowerShell, cambia mkdir -p por mkdir):

mkdir -p ~/codex-demo && cd ~/codex-demo
codex

¿Aún no tienes instalado Codex? No te preocupes, en este capítulo asentamos los conceptos, y en el capítulo 03 · Instalación y login te guiaremos paso a paso para instalarlo y poder hacer este experimento.

Paso 2: Cambiar al modo de sólo lectura.

Escribe el comando de barra diagonal en tu sesión de Codex para ajustar los permisos a sólo lectura:

/permissions

Selecciona la opción de sólo lectura (Read Only / read-only) en el menú. Resultado esperado: La interfaz indicará que has entrado en modo de sólo lectura, mostrando un mensaje similar a:

Permissions updated: read-only

⚠️ El menú de la versión nueva podría variar: a partir de la versión 0.142 de codex-cli, el sistema introduce permission profiles (en fase Beta, sujeta a cambios) en lugar de los perfiles clásicos «Read Only / Auto / Full Access». Es posible que tu menú /permissions muestre opciones de políticas de aprobación como Ask for approval / Approval for me / Full access.

Si no ves la opción Read Only, puedes forzar el modo de sandbox clásico (que mantiene compatibilidad): sal de la sesión y entra de nuevo ejecutando codex --sandbox read-only; o añade sandbox_mode = "read-only" en ~/.codex/config.toml para aplicarlo permanentemente. El experimento funcionará siguiendo estos pasos alternativos.

Esta sección es experimental y puede variar; las referencias a cambiar a modo de sólo lectura en el resto del manual seguirán esta misma regla.

Paso 3: Pedirle que realice una acción de escritura y observar cómo se detiene.

Escribe el siguiente mensaje en la sesión:

Ayúdame a crear un archivo llamado hello.txt con el texto "hello codex" dentro.

Resultado esperado: Codex no creará el archivo en silencio, sino que se detendrá a pedir tu autorización, ya que la acción de «escribir un archivo» supera los límites de read-only y la política de aprobación le exige preguntar. Verás un mensaje similar a:

Necesito crear el archivo hello.txt, lo cual supera los límites del modo de sólo lectura actual.
¿Permitir acción? (y/n)

Al ver esta pregunta de confirmación, estarás presenciando la colaboración del sandbox y la aprobación: el sandbox identifica que la acción «sale del círculo» y la aprobación detiene el proceso para pedir tu confirmación. Estas son las dos barreras explicadas en las secciones 02 y 03 actuando en tu pantalla.

Paso 4: Comparar con el modo libre.

Vuelve a /permissions, cambia al modo de espacio de trabajo con escritura (workspace-write) y pide de nuevo que cree el archivo hello.txt. Resultado esperado: Esta vez creará el archivo directamente sin preguntar, ya que la escritura dentro del espacio de trabajo está permitida por el sandbox y no requiere aprobación.

Creado el archivo hello.txt

Al terminar, usa /status para revisar la información del modelo y la política de aprobación de la sesión actual:

/status

La misma petición de creación de archivo es bloqueada en modo de sólo lectura y permitida en modo de escritura; esa es la diferencia práctica del sandbox. Ver cómo se detiene a pedir permiso enseña mucho más que leer diez veces que «el sandbox es un límite seguro».

💡 Resumen en una frase: Realiza este experimento mínimo para comprobar que la misma petición de escritura es detenida en read-only para pedir confirmación y se ejecuta directamente en workspace-write; así es como trabajan juntos el sandbox y la aprobación.

---

07 Resumen

En este capítulo hemos explicado los conceptos clave de Codex indispensables para el resto del manual:

Concepto	Explicación rápida	Equivalente en Claude Code
Agente (Agent)	IA autónoma que piensa, actúa y observa; no es un chat	Bucle de agentes, idéntico
Sandbox (Sandbox)	Círculo de actuación seguro; limita escritura y red	Límite de permisos, pero más visible
Aprobación (Approval)	Política para preguntar al salir del sandbox	Modo de permisos
AGENTS.md	Manual del proyecto con las reglas que lee al iniciar	CLAUDE.md con otro nombre
Memoria / Chronicle	Memoriza preferencias; Chronicle analiza pantalla (experimental)	Equivalente a memory; Chronicle es nuevo

Ahora comprendes por qué Codex puede «negarse» a modificar un archivo (límites del sandbox), por qué se detiene a pedir confirmación (política de aprobación), cómo usar AGENTS.md para enseñarle las reglas y cómo ajustar los permisos con /permissions.

La lección principal: Codex no es un sistema de deseos automáticos, sino un compañero de programación delimitado por reglas de seguridad; tu función es guiarlo, definir su espacio de actuación y corregir el rumbo si es necesario. Comprender estos conceptos te facilitará el aprendizaje de las interfaces, configuraciones y extensiones en los capítulos siguientes.

---

El próximo capítulo 03 · Instalación y login te guiará para instalar físicamente Codex en tu máquina (Mac, Windows o Linux), iniciar sesión con tu cuenta y ejecutar tu primera instrucción (los usuarios de Linux verán en acción la herramienta bubblewrap explicada aquí).

---

Lecturas recomendadas

• Conoce Codex y sus cuatro interfaces
• Conectar modelos de terceros como DeepSeek
• Mejores prácticas: Consejos reales más allá de la teoría estándar