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,可以用官方安裝腳本:
|
|
Windows 使用者如果在 WSL 裡使用,也可以在 WSL 終端中執行同樣的命令,然後執行:
|
|
安裝完成後,先確認版本:
|
|
如果你正在使用較舊版本,建議先升級。OSS 模式、provider 配置、profile 行為都和 Codex 版本有關,舊教程裡的配置可能已經不再適用。
用 --oss 啟動本地 provider
最簡單的入口是在啟動時加上 --oss:
|
|
官方文件的表述是:Codex 在傳入 --oss 時,可以執行在本地 open source provider 上,例如 Ollama 或 LM Studio。如果只傳 --oss,Codex 會使用配置裡的 oss_provider 作為預設 OSS provider。
可以在 ~/.codex/config.toml 裡設定預設本地 provider:
|
|
這樣以後執行:
|
|
Codex 就會按 oss_provider 指向的本地 provider 啟動。
配置預設模型和 provider
Codex 的使用者級配置檔案是:
|
|
CLI 和 IDE extension 會共用這套配置。最常用的兩個欄位是:
|
|
model 是傳給後端的模型名;model_provider 指向下面定義的 provider。provider 負責告訴 Codex:請求發到哪裡、走哪個 wire API、認證方式是什麼。
例如,你可以為本地 Ollama 定義一個 provider:
|
|
這裡的幾個欄位含義:
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 已安裝、模型已拉取,並且服務正在執行。
示例配置:
|
|
然後啟動:
|
|
如果要臨時指定模型,也可以在啟動時使用 -m:
|
|
排查時先確認三件事:
- Ollama 服務是否在執行;
base_url是否帶了/v1;model是否是 Ollama 實際可用的模型名。
接入 LM Studio
LM Studio 也可以提供本地 OpenAI 相容介面。常見地址是:
|
|
可以寫成:
|
|
這裡的 model 要和 LM Studio 目前服務暴露的模型名一致。如果 LM Studio 只暴露 Chat Completions 相容介面,才考慮把 wire_api 改成:
|
|
但這更像相容兜底,不建議作為新配置的預設選擇。
接入 OpenRouter 或其他雲端閘道
如果你想透過一個雲端閘道存取多種模型,可以定義一個遠端 provider。以 OpenRouter 風格的 OpenAI 相容閘道為例:
|
|
如果不想把密鑰寫進配置檔案,更推薦使用環境變數方式,或按你的團隊安全規範注入 token。密鑰不應該提交進倉庫,也不要寫進專案級 .codex/config.toml。
接入自建 OpenAI 相容服務
如果你在區域網路或伺服器上部署了 vLLM、SGLang、TGI 或公司內部模型閘道,可以把 Codex 指向自建服務:
|
|
這類配置最容易出問題的地方是協議相容性。後端號稱 OpenAI compatible,不代表 Responses API 的每個欄位、串流輸出、工具調用和錯誤格式都完全相容。先用小任務驗證,再交給它大規模改程式碼。
正確使用 profile:不要再寫 [profiles.xxx]
舊教程裡常見這種寫法:
|
|
目前不要再這樣寫。官方 manual 明確說明:Codex 0.134.0 及以後,--profile 不再讀取 config.toml 裡的 [profiles.profile-name],也不再支援頂層 profile = "profile-name" 選擇器。
新的寫法是為每個 profile 建一個獨立檔案:
|
|
檔案內容使用頂層配置項:
|
|
啟動時選擇 profile:
|
|
再建一個複雜任務用的 profile:
|
|
示例:
|
|
啟動:
|
|
這樣可以把日常小改動、複雜架構設計、本地離線任務、雲端強模型任務分開管理。
專案級配置不要放 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 模式讓模型選擇更靈活:輕量任務可以走本地模型,敏感程式碼可以盡量留在本機或內網,複雜任務再切到更強的模型。真正要注意的是配置格式和模型能力邊界。
如果只是想快速嘗試,可以先跑:
|
|
如果要長期使用,建議盡早整理 ~/.codex/config.toml 和幾個獨立 profile 檔案,把本地模型、雲端閘道、強模型審查模式分開。這樣 Codex 不只是「能接任意模型」,而是能在不同開發場景裡選對模型。