Modelo por defecto de Codex: cómo fijarlo, cambiarlo y anclarlo en config.toml
Cómo ver con qué modelo arranca Codex CLI, cambiarlo para una sesión con /model, dejar un valor por defecto permanente con model y model_reasoning_effort en ~/.codex/config.toml, sobrescribirlo por proyecto — y qué cambió el release 0.161.0 del 7 de octubre de 2026.
Respuestas rápidas
- Comprueba el valor por defecto actual sin editar nada: el banner de bienvenida imprime el modelo activo al arrancar Codex, /status lo muestra dentro de la sesión, y codex doctor --summary informa de qué archivos de configuración se cargaron.
- Cambia el modelo solo para esta sesión con el comando slash /model — el cambio muere al terminar la sesión y vuelve el valor por defecto de tu config.toml.
- Fija el modelo de forma permanente en ~/.codex/config.toml con model = "gpt-6.1-sol" y combínalo con model_reasoning_effort = "high" para controlar cuánto piensa.
- Un proyecto de confianza puede llevar su propio .codex/config.toml que sobrescribe tu valor por defecto de usuario, y una carpeta anidada puede sobrescribir otra vez — el flag del CLI o el override de -c siempre gana. El vídeo demuestra toda la pila con una tabla de scopes.
- Codex CLI 0.161.0 (7 de octubre de 2026) hizo de GPT-6.1 Sol el modelo por defecto en los catálogos integrados y de Amazon Bedrock — actualiza y puede que tu valor por defecto haya cambiado sin que te enteres.
Codex CLI Setup & Configuration: Which Setting Wins?
Canal:Coding With Chuck10:12
Config reference — official documentation
Docs:developers.openai.com/codex
Release rust-v0.161.0 — default model swap
Release:github.com/openai/codex
La grabación usa gpt-5.6-terra, gpt-5.6-sol y gpt-5.6-luna como valores de ejemplo dentro de un laboratorio desechable de CODEX_HOME; las claves que demuestra — model, approval_policy, sandbox_mode, projects trust_level — son las claves reales de config.toml de la referencia oficial. Los comandos en sesión /model y /status vienen de la documentación oficial de comandos slash.
Los fotogramas del vídeo siguen siendo propiedad de Coding With Chuck y se incrustan aquí como documentación paso a paso con atribución y enlaces profundos.
Fijar el modelo por defecto de Codex paso a paso
Averigua qué modelo estás ejecutando de verdad
- 1
Instala o abre Codex desde el hub oficial
Todo empieza en chatgpt.com/codex — la grabación abre el hub y su botón Download antes de tocar la terminal. Si ya tienes el CLI, salta adelante; si parece que tu modelo por defecto cambió solo, revisa primero tu versión, porque los catálogos integrados se mueven entre releases.
El hub chatgpt.com/codex con el botón Download for WindowsVer en 1:30 - 2
Confirma qué codex ejecuta tu shell
Antes de culpar a la config, asegúrate de ejecutar el Codex que crees. En PowerShell, Get-Command codex resuelve a codex.ps1 y muestra su ruta de instalación; en macOS o Linux, which codex hace lo mismo. Varias instalaciones (npm más un binario independiente) son la razón clásica por la que una config editada parece ignorada.
Get-Command codex resolviendo el script de lanzamiento y la ruta de origenVer en 2:00 - 3
Comprueba la versión y el estado de inicio de sesión
Ejecuta codex --version y después codex login status. La grabación reporta codex-cli 0.146.1 y "Logged in using ChatGPT". La versión importa aquí: el modelo por defecto viene con el catálogo integrado del CLI, así que dos máquinas con versiones distintas pueden discrepar incluso sobre cuál es el valor por defecto.
codex --version y codex login status en una sola pantallaVer en 2:40 - 4
Inspecciona la configuración efectiva con codex doctor
codex doctor --summary imprime un informe de salud: la grabación muestra una nota "mixed auth signals" (login de ChatGPT más una variable de entorno con API key), marcas verdes para runtime, install, git y terminal, y una sección Configuration que confirma config loaded. Es la forma más rápida de ver si tu archivo de configuración se está leyendo siquiera.
El informe del doctor con su nota de auth y las marcas verdes del entornoVer en 3:00
Dejar el valor por defecto en config.toml — usuario, proyecto, subcarpeta
- 5
Localiza tu home de Codex
Los ajustes de usuario viven en ~/.codex, y la variable de entorno CODEX_HOME puede apuntar Codex a otro sitio completamente — la grabación construye a propósito una carpeta de laboratorio desechable y apunta CODEX_HOME hacia ella. Si un compañero o un script dejó puesto CODEX_HOME, tus ediciones de ~/.codex/config.toml caen en un archivo que Codex nunca lee.
El script de setup anunciando el laboratorio CODEX_HOME aisladoVer en 4:30 - 6
Abre el config.toml a nivel de usuario
Dentro del home de Codex vive config.toml — el archivo que documenta la referencia oficial de configuración. La grabación despliega la carpeta codex-home en VS Code y selecciona config.toml. En una máquina normal es ~/.codex/config.toml; créalo si aún no existe, y respeta la sintaxis TOML (valores entre comillas, sin comas).
La carpeta codex-home con su config.toml seleccionado en VS CodeVer en 4:53 - 7
Fija el modelo por defecto a nivel de usuario
Añade model = "gpt-5.6-terra" — el ejemplo de la grabación, usando uno de los modelos del catálogo de esa época; hoy el integrado por defecto es gpt-6.1-sol, así que usa el ID exacto que viste en /model. El mismo archivo lleva approval_policy = "on-request" y sandbox_mode = "workspace-write", más un bloque [projects.'D:\...\config-lab'] trust_level = "trusted" que marca qué carpetas pueden cargar su propia config de proyecto.
model, approval_policy, sandbox_mode y el bloque de proyectos de confianzaVer en 5:00 - 8
Sobrescribe el modelo por proyecto
Un repositorio de confianza puede llevar su propio .codex/config.toml. La grabación añade uno en la raíz de config-lab con model = "gpt-5.6-sol" y el comentario "Trusted repository default for this demonstration" — a partir de ahora, las sesiones iniciadas en ese repo usan Sol mientras el resto sigue en Terra. Recuerda la regla de la documentación: los archivos de proyecto no pueden sobrescribir claves locales de máquina como model_provider, así que deja la configuración de proveedores a nivel de usuario.
El .codex/config.toml del proyecto anclando gpt-5.6-solVer en 5:25 - 9
Anida un override para una subcarpeta
Un nivel más profundo: config-lab/tools consigue su propio .codex/config.toml con model = "gpt-5.6-luna" y el comentario "More specific setting for work launched under tools/". Las configs de proyectos de confianza aplican desde la raíz del repositorio hasta el directorio de trabajo, así que la carpeta más específica desde la que lances fija el modelo.
tools/.codex/config.toml anclando gpt-5.6-luna para ese subárbolVer en 5:50 - 10
Demuestra qué capa ganó
La grabación cierra el círculo con un script run-demo que imprime una tabla "Effective model": user → terra, project-root → sol, nested-project → luna, cli-override → terra. Toda la pila de prioridad en una pantalla — los flags de línea de comandos y los overrides de -c vencen a las carpetas anidadas, que vencen a las raíces de proyecto, que vencen a tu config de usuario.
La tabla del modelo efectivo scope por scope, con las notas del doctor abajoVer en 6:00
Cambios de sesión, esfuerzo de razonamiento y el relevo del 0.161.0
- 11
Cambia de modelo para una sesión con /model
Dentro de una sesión, /model abre el selector para cambiar de modelo al vuelo, y /status reporta el modelo y el esfuerzo de razonamiento vigentes. Los cambios de sesión son temporales por diseño — sal y vuelve a arrancar, y el valor por defecto de config.toml retoma el mando; por eso /model es la forma segura de hacer una audición de un modelo antes de anclarlo.
- 12
Conoce el relevo del 0.161.0 (2026-10-07)
Codex CLI 0.161.0, publicado el 7 de octubre de 2026, declara: "GPT-6.1 Sol is now the default model in the bundled and Amazon Bedrock catalogs". Si nunca pusiste una clave model, una actualización te mueve allí en silencio. Para conservar un valor anterior, escríbelo explícitamente en ~/.codex/config.toml y ajusta la profundidad con model_reasoning_effort ("high" en el ejemplo de la documentación). Los equipos también deberían saber que agents.default_subagent_model fija el modelo por defecto de los agentes generados, y que review_model sobrescribe el modelo que usa /review.
Cuando el modelo por defecto no se queda
Editaste un archivo de configuración y Codex sigue arrancando con el modelo viejo. Antes de volver a editar, recorre esta lista — la causa es casi siempre una segunda capa de config que manda sobre la tuya.
- 1Archivo equivocado para el scope desde el que lanzas — un .codex/config.toml de proyecto sobrescribe tu ~/.codex/config.toml de usuario, y uno anidado manda sobre la raíz del proyecto. Ejecuta codex doctor en la carpeta exacta desde la que lanzas y mira qué configs reporta cargadas.
- 2Un flag del CLI o un override puntual de -c vence a todos los archivos — si un script envoltorio, un alias o una extensión del IDE lanzan codex con --model o -c model=..., tu config nunca llega a votar. Inspecciona cómo se invoca realmente el comando.
- 3CODEX_HOME apunta a otro sitio — editar ~/.codex/config.toml no sirve de nada cuando la variable de entorno CODEX_HOME reubica el home; es justo lo que hace el laboratorio del vídeo. Hazle un echo a la variable antes de culpar al parser.
- 4El proyecto no es de confianza — un .codex/config.toml en una carpeta no confiable se salta por completo. La confianza se otorga con la entrada projects.'<path>'.trust_level = "trusted" en tu config de usuario, como se ve en el archivo de usuario de la grabación.
- 5Claves locales de máquina en un archivo de proyecto — model_provider, model_providers, profile y profiles se ignoran en las configs locales de proyecto por diseño. Si intentabas enganchar un proveedor personalizado por proyecto, súbelo a nivel de usuario y sobrescribe localmente solo el id del modelo.
- 6ID de modelo mal escrito o renombrado — el valor de model debe coincidir con el catálogo exactamente (el release 0.161.0 rebarajó los catálogos integrados y de Bedrock). Abre /model para copiar el id exacto y pégalo en config.toml en vez de teclearlo de memoria.
Una vez entendidas las capas de archivos, el comportamiento es totalmente predecible: valor por defecto de usuario, luego perfil, luego configs de proyectos de confianza de la raíz al directorio, luego flags del CLI. La tabla de scopes de la grabación merece reproducirse en tu máquina — predice las cuatro filas antes de ejecutarla y nunca más te preguntarás qué modelo usará Codex.