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的博客