Gran actualización de OpenAI Codex: ahora puede conectarse a modelos locales como Ollama y LM Studio

Codex CLI ahora puede conectarse a servicios de modelos locales o personalizados mediante el modo OSS. Para los desarrolladores, el valor es directo: no todos los trabajos tienen que usar el modelo predeterminado de OpenAI. También puedes apuntar Codex a Ollama, LM Studio, OpenRouter, una pasarela interna de la empresa o un servicio de inferencia propio compatible con OpenAI.

Este artículo se basa en una publicación de la comunidad CSDN/AtomGit y está revisado frente al Codex manual actual de OpenAI. Hay un punto especialmente importante: algunos ejemplos de profile del artículo original usan un formato antiguo. Desde Codex 0.134.0, los profiles son archivos independientes ~/.codex/<profile-name>.config.toml. Codex ya no lee tablas [profiles.xxx] desde config.toml.

Artículo original: https://tianqi.csdn.net/6a33be7210ee7a33f27f7913.html

Qué resuelve el modo OSS

Codex CLI es, en esencia, un coding agent capaz de leer un proyecto, ejecutar comandos, modificar archivos, participar en revisiones de código y ayudar con la depuración. El modelo determina su calidad de razonamiento, velocidad, coste y frontera de datos.

Después de activar el modo OSS, Codex puede conectarse a proveedores locales “open source”, como Ollama o LM Studio. En un sentido más amplio, si el backend admite la Responses API o la Chat Completions API de OpenAI, también se puede conectar mediante un provider personalizado.

El modo OSS merece considerarse cuando:

quieres ejecutar modelos en hardware local y reducir la salida de código fuera de la máquina;
quieres enviar tareas ligeras a un modelo local para reducir costes;
quieres cambiar entre modelos como Qwen, DeepSeek, Mistral y Llama;
tu empresa ya tiene una pasarela de modelos unificada o un servicio privado de inferencia;
necesitas ejecutar Codex dentro de una intranet o LAN.

Conviene dejar claro el límite: que un modelo pueda conectarse no significa que la experiencia vaya a ser igual a la de los modelos recomendados por OpenAI. Las llamadas a herramientas, el contexto largo, la estabilidad al editar código y la capacidad de seguir instrucciones pueden variar mucho entre modelos. Para tareas complejas, conserva un profile con un modelo más fuerte.

Instalar Codex CLI

Si todavía no has instalado Codex CLI, puedes usar el instalador oficial:

1

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Los usuarios de Windows que usen Codex dentro de WSL pueden ejecutar el mismo comando en una terminal WSL y luego iniciar Codex con:

1

codex

Después de instalarlo, revisa primero la versión:

1

codex --version

Si estás usando una versión antigua, conviene actualizar primero. El modo OSS, la configuración de provider y el comportamiento de profile dependen de la versión de Codex, y las configuraciones de tutoriales antiguos pueden haber dejado de ser válidas.

Iniciar un provider local con `--oss`

La entrada más simple es añadir --oss al iniciar:

1

codex --oss

La documentación oficial indica que, al pasar --oss, Codex puede ejecutarse sobre un open source provider local, como Ollama o LM Studio. Si solo se pasa --oss, Codex usa el oss_provider de la configuración como provider OSS predeterminado.

Puedes definir el provider local predeterminado en ~/.codex/config.toml:

1

oss_provider = "ollama" # o "lmstudio"

Después ejecuta:

1

codex --oss

Codex arrancará con el provider local indicado por oss_provider.

Configurar el modelo y el provider predeterminados

El archivo de configuración de usuario de Codex es:

1

~/.codex/config.toml

La CLI y la IDE extension comparten esta configuración. Los dos campos más usados son:

1
2


model = "your-model-name"
model_provider = "your-provider-id"

model es el nombre del modelo que se envía al backend. model_provider apunta al provider definido más abajo. El provider le dice a Codex a dónde enviar las solicitudes, qué wire API usar y cómo autenticar.

Por ejemplo, puedes definir un provider para Ollama local:

1
2
3
4
5
6
7


model = "qwen2.5-coder:32b"
model_provider = "local_ollama"

[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"
wire_api = "responses"

Estos campos significan:

model: el nombre del modelo, normalmente determinado por el backend;
model_provider: qué provider se usa actualmente;
[model_providers.local_ollama]: la tabla de configuración del provider personalizado;
name: el nombre visible;
base_url: el endpoint de API compatible con OpenAI del servicio de modelo;
wire_api: el tipo de protocolo, normalmente responses o chat.

Codex todavía puede apuntar a backends compatibles con Chat Completions, pero el manual oficial avisa claramente de que el soporte de Chat Completions está deprecated y se eliminará de Codex en el futuro. Para configuraciones nuevas, prioriza wire_api = "responses".

Conectar Ollama

Ollama es adecuado para ejecutar modelos en local. Primero asegúrate de que Ollama está instalado, el modelo está descargado y el servicio está en ejecución.

Configuración de ejemplo:

1
2
3
4
5
6
7
8


model = "qwen2.5-coder:32b"
model_provider = "local_ollama"
oss_provider = "ollama"

[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"
wire_api = "responses"

Luego inicia Codex:

1

codex --oss

Si quieres especificar temporalmente un modelo al iniciar, también puedes usar -m:

1

codex --oss -m qwen2.5-coder:32b

Al depurar, revisa primero tres cosas:

Si el servicio de Ollama está en ejecución;
Si base_url incluye /v1;
Si model es un nombre de modelo realmente disponible en Ollama.

Conectar LM Studio

LM Studio también puede ofrecer un endpoint local compatible con OpenAI. La dirección habitual es:

1

http://localhost:1234/v1

Puedes configurarlo así:

1
2
3
4
5
6
7
8


model = "local-model"
model_provider = "lmstudio_local"
oss_provider = "lmstudio"

[model_providers.lmstudio_local]
name = "LM Studio"
base_url = "http://localhost:1234/v1"
wire_api = "responses"

El valor de model debe coincidir con el nombre del modelo que LM Studio expone actualmente. Solo considera cambiar wire_api a lo siguiente si LM Studio expone únicamente una interfaz compatible con Chat Completions:

1

wire_api = "chat"

Esto se parece más a un fallback de compatibilidad y no se recomienda como opción predeterminada para una configuración nueva.

Conectar OpenRouter u otra pasarela en la nube

Si quieres acceder a varios modelos mediante una pasarela en la nube, puedes definir un provider remoto. Por ejemplo, una pasarela compatible con OpenAI al estilo OpenRouter se puede configurar así:

1
2
3
4
5
6
7
8


model = "anthropic/claude-sonnet-4-20250514"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
wire_api = "responses"
experimental_bearer_token = "sk-or-v1-your-key"

Si no quieres escribir la clave secreta en el archivo de configuración, es mejor usar variables de entorno o inyectar el token según la política de seguridad de tu equipo. Las claves no deben enviarse al repositorio ni escribirse en .codex/config.toml a nivel de proyecto.

Conectar un servicio propio compatible con OpenAI

Si has desplegado vLLM, SGLang, TGI o una pasarela interna de modelos en una LAN o servidor, puedes apuntar Codex a ese servicio:

1
2
3
4
5
6
7
8


model = "my-custom-model"
model_provider = "self_hosted"

[model_providers.self_hosted]
name = "Self Hosted"
base_url = "http://192.168.1.100:8080/v1"
wire_api = "responses"
experimental_bearer_token = "local-dev-key"

La parte más frágil de este tipo de configuración es la compatibilidad del protocolo. Que un backend diga ser OpenAI compatible no significa que todos los campos de la Responses API, la salida en streaming, las llamadas a herramientas y los formatos de error sean totalmente compatibles. Valídalo con tareas pequeñas antes de entregarle cambios de código a gran escala.

Usar profile correctamente: no escribas `[profiles.xxx]`

Los tutoriales antiguos suelen usar este formato:

1
2
3
4


[profiles.fast-coder]
model = "qwen2.5-coder:7b"
model_provider = "ollama"
model_reasoning_effort = "low"

Ahora no uses este formato. El manual oficial indica que en Codex 0.134.0 y versiones posteriores, --profile ya no lee [profiles.profile-name] desde config.toml, y tampoco admite el selector de nivel superior profile = "profile-name".

El enfoque nuevo es crear un archivo independiente para cada profile:

1

~/.codex/fast-coder.config.toml

El archivo usa claves de configuración de nivel superior:

1
2
3
4
5
6
7
8


model = "qwen2.5-coder:7b"
model_provider = "local_ollama"
model_reasoning_effort = "low"

[model_providers.local_ollama]
name = "Ollama"
base_url = "http://localhost:11434/v1"
wire_api = "responses"

Inicia Codex con ese profile:

1

codex --profile fast-coder

También puedes crear un profile para tareas complejas:

1

~/.codex/deep-review.config.toml

Ejemplo:

1
2
3


model = "gpt-5.5"
model_provider = "openai"
model_reasoning_effort = "high"

Inicio:

1

codex --profile deep-review

Así puedes separar pequeñas ediciones diarias, diseño de arquitectura complejo, tareas locales sin conexión y trabajos con modelos fuertes en la nube.

No pongas credenciales de provider en la configuración de proyecto

Codex admite .codex/config.toml a nivel de proyecto, pero la configuración de provider, autenticación y selección de profile encaja mejor en la configuración de usuario. El manual oficial también explica que la configuración local del proyecto no puede sobrescribir ajustes sensibles que redirijan credenciales, cambien provider auth o seleccionen profiles. Cuando Codex ve esas claves, las ignora y muestra una advertencia al iniciar.

En resumen:

~/.codex/config.toml a nivel de usuario: providers de modelo, método de autenticación y modelo predeterminado personal;
archivo profile ~/.codex/<name>.config.toml: diferencias entre modos de trabajo;
.codex/config.toml a nivel de proyecto: ajustes no sensibles relacionados con el proyecto y adecuados para compartirse en el repositorio;
claves secretas: prioriza variables de entorno, credenciales del sistema o un método de inyección gestionado por el equipo.

Lista de comprobación antes de usar el modo OSS

Antes de empezar, puedes revisar en este orden:

Usa codex --version para confirmar que la versión es suficientemente nueva;
Asegúrate de que el servicio local de modelos está iniciado, como Ollama o LM Studio;
Asegúrate de que el modelo se ha descargado o está disponible en el servidor;
Comprueba que base_url es correcto y normalmente incluye /v1;
Prioriza wire_api = "responses";
Asegúrate de que el provider ID no usa un nombre reservado;
Asegúrate de que la API Key no está escrita en el repositorio;
Valida llamadas a herramientas, edición de archivos y ejecución de comandos con una tarea pequeña;
Conserva un profile con un modelo fuerte para tareas complejas.

Conclusión

El modo OSS de Codex CLI hace más flexible la elección de modelos: las tareas ligeras pueden ir a modelos locales, el código sensible puede permanecer en la máquina local o en la intranet tanto como sea posible, y las tareas complejas pueden volver a un modelo más fuerte. Lo realmente importante es vigilar el formato de configuración y los límites de capacidad del modelo.

Si solo quieres probarlo rápidamente, ejecuta:

1
2


curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex --oss

Para un uso a largo plazo, organiza cuanto antes ~/.codex/config.toml y varios archivos profile independientes. Separa modelos locales, pasarelas en la nube y modos de revisión con modelos fuertes. Así Codex no solo “puede conectarse a cualquier modelo”, sino que puede elegir el modelo correcto para cada escenario de desarrollo.