Codex Desktop oculta tus modelos custom

La mayoría de la gente está a una línea de config de un arreglo. Empareja lo que ves con la tabla y actúa.

La comprobación más rápida: abre una terminal en la misma carpeta, ejecuta codex (el CLI) y escribe /model. Si el CLI lista tu modelo pero Desktop no, tienes el bug de filtrado del lado del cliente — y editar la config del lado de Desktop no lo va a hacer aparecer. Salta a Fix 1.

Esta es la decisión que te ahorra una tarde editando la capa equivocada.

Necesitan arreglos distintos. Elegir la equivocada es por qué la gente pasa una tarde reescribiendo una config que ya funcionaba.

La primera sorprende. Según el issue abierto de codex #19694, el app-server carga el catálogo correctamente y devuelve tus modelos a través de su endpoint model/list — pero la UI de Desktop aplica un filtro extra y descarta los modelos configurados localmente antes de renderizar el selector. El backend conoce tu modelo. El frontend se niega a mostrarlo. Es un bug del cliente, no un error de config, y se abrió el 2026-04-26 y sigue abierto al escribir esto.

La segunda causa es la más común y la menos alarmante. Si solo escribiste model = "some-id" sin catálogo, Codex tiene el string pero no nombre de pantalla, ni ventana de contexto, ni flags de capacidades. El selector muestra la etiqueta "Custom" y sigue. Tus peticiones siguen yendo al modelo correcto. Esto confunde porque "Custom" parece roto cuando en realidad funciona.

Codex construye su lista de modelos por capas, y el orden te dice qué fix va a funcionar de verdad.

Tres fuentes alimentan la lista: un catálogo empaquetado con el binario, un catálogo remoto que se obtiene de OpenAI y tu model_catalog_json local. El archivo local gana — sobrescribe tanto al catálogo empaquetado como al remoto en el arranque, que es por lo que un model_catalog_json correcto es la palanca real para modelos de terceros, no un extra opcional.

Aquí está la parte que confunde a todos. Al arrancar, el app-server lee las tres capas, las resuelve y expone el resultado por un endpoint interno model/list. El CLI renderiza esa lista directamente, así que los modelos custom aparecen. Desktop renderiza la misma lista a través de un paso extra del cliente que, según el issue #19694, aplica su propia lista de permitidos y descarta las entradas configuradas localmente antes de que lleguen al desplegable. Mismo backend, mismo catálogo, dos selectores distintos. Esa única divergencia es por la que el CLI es una vía de escape fiable y Desktop no.

También hay una caché que vigilar. Codex mantiene ~/.codex/models_cache.json, y tras cambiar de proveedor o editar un catálogo no siempre se resincroniza. Una caché caduca puede seguir mostrando una lista antigua — o vacía — incluso con tu config correcta. Borrar ese archivo fuerza una reconstrucción limpia en el siguiente arranque, que conviene probar antes de asumir que el catálogo en sí está mal.

Ve de arriba a abajo. Fix 1 siempre funciona. Los siguientes hacen el selector bonito y la lista conmutable.

EL ARREGLO FIABLE

# ~/.codex/config.toml   (nivel de usuario, no una carpeta de proyecto)
model = "tu-proveedor/tu-model-id"
model_provider = "mi-gateway"

[model_providers.mi-gateway]
name = "mi-gateway"
base_url = "https://tu-gateway.ejemplo/v1"
env_key = "MI_GATEWAY_API_KEY"
wire_api = "responses"

QUE EL SELECTOR LO LISTE

# arriba del todo en ~/.codex/config.toml
model_catalog_json = "/Users/you/.codex/my-models.json"
model = "tu-proveedor/tu-model-id"
model_provider = "mi-gateway"

{
  "models": [
    {
      "slug": "tu-proveedor/tu-model-id",
      "display_name": "Tu Modelo (gateway)",
      "description": "Modelo de código vía el gateway",
      "context_window": 262000,
      "max_context_window": 262000,
      "supported_in_api": true,
      "visibility": "list",
      "priority": 1
    }
  ]
}

ARREGLA LA CAPA DE CONFIG

# comprueba dónde vive tu proveedor realmente
grep -rn "model_providers" ~/.codex/config.toml ./.codex/config.toml 2>/dev/null
# si está en ./.codex/config.toml, mueve el bloque [model_providers.*]
# y model_provider = "..." a ~/.codex/config.toml, y reinicia

ARREGLA LA CAPA DE HERRAMIENTAS

# confirma que el catálogo existe y lista tus modelos tras volver a guardar
cat ~/.codex/cc-switch-model-catalog.json | grep -o '"slug":[^,]*'
# si esto está vacío, vuelve a guardar el proveedor en cc-switch y comprueba otra vez

La mitad de los reportes de "modelos custom que no aparecen" son una ruta rota disfrazada de problema de pantalla. Cada uno produce un síntoma que parece el selector ocultando tu modelo, cuando la petición nunca tuvo opción de llegar.

La señal que separa estos del filtro real #19694 es un comando: ejecuta la misma petición desde el CLI. Si el CLI también falla, es uno de los errores de arriba, no el selector de Desktop, y ningún cambio de catálogo lo arregla. Si el CLI funciona y solo Desktop se queda ciego, es el filtro — y vuelves a Fix 1 y Fix 4.

Esto no es un solo bug. Es un cluster de issues relacionados en la app de Codex y en las herramientas que escriben su config. Saber cuál tienes te ahorra aplicar el arreglo equivocado.

El patrón en todos estos: el enrutamiento funciona, la pantalla no. El CLI ha sido la vía de escape fiable cada vez, porque lee el catálogo sin el filtro extra del renderer de Desktop. Si estás bloqueado en Desktop, el CLI (codex en tu terminal) casi siempre mostrará y usará el modelo.

Si estás cansado de pelear con la UI de Desktop, aquí hay formas de seguir usando modelos custom sin esperar un arreglo del cliente.

El sentido de un gateway aquí es un endpoint y una key para muchos modelos, de modo que cambiar de modelo es editar un string en vez de un bloque de proveedor nuevo cada vez. Sea cual sea el camino, la rareza del selector de Desktop es una capa de pantalla por encima, no una restricción de enrutamiento.

No confíes en el selector como fuente de verdad — es justo lo que está roto. Verifica en la capa por debajo.

codex --version                 # confirma que estás en un build reciente
codex                           # arranca el CLI y escribe /model
# el CLI enumera el catálogo sin el filtro de Desktop

Si /model en el CLI muestra tu modelo, el catálogo y el proveedor son correctos y cualquier hueco restante es el renderer de Desktop. Si el CLI también sale vacío, el problema está aguas arriba: archivo equivocado (Fix 3), catálogo mal formado (Fix 2 / Fix 4) o un slug malo. Para una comprobación rápida de que la ruta resuelve, un curl contra el gateway con tu key te dice si el modelo existe antes de culpar al cliente. Primero la ruta, luego la pantalla.

Los arreglos de arriba te devuelven el selector. El resto es la parte por la que vale la pena actuar antes del próximo bug.

Puedes leer este bug de dos formas. La estrecha: un cliente de Desktop filtra tus modelos, ponlos inline y sigue. La útil: una herramienta que tratabas como parte de tu flujo soltó funcionalidad en la capa de renderizado, y la única señal fue que el desplegable se veía vacío.

Lo vemos en casi todo sistema de IA que auditamos. Un equipo construye sobre un cliente, una UI, un modelo por defecto, y un bug, una deprecación o un filtro silencioso convierte un setup que funcionaba en media tarde de conjeturas. El bug del selector de Codex es solo la versión más reciente y más concreta.

Tres cosas hacen que un setup sobreviva a estos cambios:

Si tu flujo colapsa cuando un cliente oculta un modelo, el flujo suspendió el examen de diseño — no el cliente.

Sobre FACTA

FACTA ayuda a startups y equipos en etapa de crecimiento a convertir IA en sistemas de producción que siguen funcionando — no demos que impresionan una vez.

Diseñamos la arquitectura en torno a lo que de verdad se rompe bajo uso real: abstracción de modelo, credenciales que te pertenecen, failover, controles de coste, observabilidad. La infraestructura aburrida que mantiene un sistema vivo después del lanzamiento.

Liderado por Matías Baglieri y Carolina Fogliato, nos centramos en una sola cosa:

Liderazgo de IA que construye. No solo asesora.