OpenAI Codex 重大更新：现在可以接入 Ollama、LM Studio 等本地大模型

Thu, 18 Jun 2026 22:41:34 +0800

Codex CLI 现在可以通过 OSS 模式接入本地或自定义模型服务。对开发者来说，这个能力的意义很直接：不一定每个任务都要走 OpenAI 默认模型，也可以把 Codex 指向 Ollama、LM Studio、OpenRouter、公司内部网关，或者自己部署的 OpenAI 兼容推理服务。

这篇整理自 CSDN/AtomGit 社区的一篇文章，并用 OpenAI 当前 Codex manual 做了口径校准。尤其要注意一点：原文里的部分 profile 写法属于旧格式，当前 Codex 0.134.0 之后已经改为独立的 ~/.codex/<profile-name>.config.toml 文件，不再从 config.toml 里的 [profiles.xxx] 表读取。

原文：https://tianqi.csdn.net/6a33be7210ee7a33f27f7913.html

OSS 模式解决什么问题

Codex CLI 本质上是一个能读项目、执行命令、修改文件、参与代码审查和调试的 coding agent。模型决定它的推理质量、速度、成本和数据边界。

开启 OSS 模式后，Codex 可以连接本地“开源”提供商，比如 Ollama 或 LM Studio。更广一点说，只要后端支持 OpenAI 的 Responses API 或 Chat Completions API，也可以通过自定义 provider 接入。

适合考虑 OSS 模式的场景：

想在本地硬件上运行模型，减少代码出网；
想把轻量任务交给本地模型，降低成本；
想在不同模型之间切换，比如 Qwen、DeepSeek、Mistral、Llama 等；
公司已经有统一的模型网关或私有推理服务；
需要在内网或局域网里运行 Codex。

需要先说清楚边界：模型能接入，不等于体验一定等同于 OpenAI 推荐模型。不同模型的工具调用、长上下文、代码修改稳定性、指令遵循能力差异会很明显。复杂任务仍然建议保留一个更强的模型 profile。

安装 Codex CLI

如果还没有安装 Codex CLI，可以用官方安装脚本：

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

Windows 用户如果在 WSL 里使用，也可以在 WSL 终端中执行同样的命令，然后运行：

codex

安装完成后，先确认版本：

`1`	`codex --version`

如果你正在使用较旧版本，建议先升级。OSS 模式、provider 配置、profile 行为都和 Codex 版本有关，旧教程里的配置可能已经不再适用。

用 `--oss` 启动本地 provider

最简单的入口是启动时加 --oss：

`1`	`codex --oss`

官方文档的表述是：Codex 在传入 --oss 时，可以运行在本地 open source provider 上，例如 Ollama 或 LM Studio。如果只传 --oss，Codex 会使用配置里的 oss_provider 作为默认 OSS provider。

可以在 ~/.codex/config.toml 里设置默认本地 provider：

`1`	`oss_provider = "ollama" # 或 "lmstudio"`

这样以后运行：

`1`	`codex --oss`

Codex 就会按 oss_provider 指向的本地 provider 启动。

配置默认模型和 provider

Codex 的用户级配置文件是：

`1`	`~/.codex/config.toml`

CLI 和 IDE extension 会共享这套配置。最常用的两个字段是：

1
2

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

model 是传给后端的模型名；model_provider 指向下面定义的 provider。provider 负责告诉 Codex：请求发到哪里、走哪个 wire API、认证方式是什么。

例如，你可以为本地 Ollama 定义一个 provider：

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

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

这里的几个字段含义：

model：模型名称，通常由后端决定；
model_provider：当前使用哪个 provider；
[model_providers.local_ollama]：自定义 provider 的配置表；
name：显示用名称；
base_url：模型服务的 OpenAI 兼容 API 地址；
wire_api：协议类型，常见值是 responses 或 chat。

当前 Codex 仍可指向支持 Chat Completions 的后端，但官方 manual 已明确提醒：Chat Completions 支持处于 deprecated 状态，未来会从 Codex 中移除。新配置优先使用 wire_api = "responses"。

接入 Ollama

Ollama 适合本地运行模型。先确保 Ollama 已安装、模型已拉取，并且服务正在运行。

示例配置：

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"

然后启动：

`1`	`codex --oss`

如果要临时指定模型，也可以在启动时使用 -m：

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

排查时先确认三件事：

Ollama 服务是否在运行；
base_url 是否带了 /v1；
model 是否是 Ollama 实际可用的模型名。

接入 LM Studio

LM Studio 也可以提供本地 OpenAI 兼容接口。常见地址是：

`1`	`http://localhost:1234/v1`

可以写成：

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"

这里的 model 要和 LM Studio 当前服务暴露的模型名一致。如果 LM Studio 只暴露 Chat Completions 兼容接口，才考虑把 wire_api 改成：

`1`	`wire_api = "chat"`

但这更像兼容兜底，不建议作为新配置的默认选择。

接入 OpenRouter 或其他云端网关

如果你想通过一个云端网关访问多种模型，可以定义一个远程 provider。以 OpenRouter 风格的 OpenAI 兼容网关为例：

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"

如果不想把密钥写进配置文件，更推荐使用环境变量方式，或者按你的团队安全规范注入 token。密钥不应该提交进仓库，也不要写进项目级 .codex/config.toml。

接入自建 OpenAI 兼容服务

如果你在局域网或服务器上部署了 vLLM、SGLang、TGI 或公司内部模型网关，可以把 Codex 指向自建服务：

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"

这类配置最容易出问题的地方是协议兼容性。后端号称 OpenAI compatible，不代表 Responses API 的每个字段、流式输出、工具调用和错误格式都完全兼容。先用小任务验证，再交给它大规模改代码。

正确使用 profile：不要再写 `[profiles.xxx]`

旧教程里常见这种写法：

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

当前不要再这样写。官方 manual 明确说明：Codex 0.134.0 及以后，--profile 不再读取 config.toml 里的 [profiles.profile-name]，也不再支持顶层 profile = "profile-name" 选择器。

新的写法是为每个 profile 建一个独立文件：

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

文件内容使用顶层配置项：

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"

启动时选择 profile：

`1`	`codex --profile fast-coder`

再建一个复杂任务用的 profile：

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

示例：

1
2
3

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

启动：

`1`	`codex --profile deep-review`

这样可以把日常小改动、复杂架构设计、本地离线任务、云端强模型任务分开管理。

项目级配置不要放 provider 凭据

Codex 支持项目级 .codex/config.toml，但 provider、认证、profile 选择这类设置更适合放在用户级配置。官方 manual 也说明，项目本地配置不能覆盖会重定向凭据、改变 provider auth、选择 profile 等敏感设置；看到这些键时 Codex 会忽略并给出启动警告。

简单说：

用户级 ~/.codex/config.toml：放模型 provider、认证方式、个人默认模型；
profile 文件 ~/.codex/<name>.config.toml：放不同任务模式的差异配置；
项目级 .codex/config.toml：放项目相关、适合随仓库共享的非敏感设置；
密钥：优先用环境变量、系统凭据或团队统一注入方式。

使用 OSS 模式前的检查清单

开始前可以按这个顺序排查：

codex --version 确认版本足够新；
本地模型服务已启动，例如 Ollama 或 LM Studio；
模型已经下载或在服务端可用；
base_url 正确，通常要带 /v1；
wire_api 优先用 responses；
provider ID 没有使用保留名；
API Key 没有写进仓库；
用小任务验证工具调用、文件修改和命令执行；
对复杂任务保留强模型 profile。

结论

Codex CLI 的 OSS 模式让模型选择更灵活：轻量任务可以走本地模型，敏感代码可以尽量留在本机或内网，复杂任务再切到更强的模型。真正要注意的是配置格式和模型能力边界。

如果只是想快速尝试，可以先跑：

1
2

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

如果要长期使用，建议尽早整理 ~/.codex/config.toml 和几个独立 profile 文件，把本地模型、云端网关、强模型审查模式分开。这样 Codex 不只是“能接任意模型”，而是能在不同开发场景里选对模型。

Codex CLI on KnightLi的博客