奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

Codex `--oss` 接本地模型：lmstudio 与 ollama 怎么选

2026-08-09

先把范围划清楚。Codex（OpenAI Codex）的 CLI 里跟”接本地模型”直接相关的，其实只有两个顶层选项：

  • --oss：使用开源提供方
  • --local-provider <OSS_PROVIDER>：指定本地提供方，取值 lmstudio 或 ollama；help 原文的说法是「不带 --oss 指定时走配置默认或弹选择」

配置文件侧对应一个键：oss_provider，官方《Configuration Reference》给的说明是”--oss 时的默认本地提供方：lmstudio 或 ollama”，这个键官方没有给默认值。

以上就是官方口径里关于这两个名字的全部信息。我把话说在前面：官方文档和 codex --help 都没有描述 lmstudio 和 ollama 有什么差别，所以这篇不会去比它们的模型库大小、加载速度、显存占用、量化格式——那些维度我手上没有依据，编出来对你没用。真正值得花时间的，是它前面那一层决策：你到底该不该走 --oss 这条路。

决策不在 lmstudio 和 ollama 之间，在更前面一层

Codex 拿到模型的通路一共有几条，选型是在这几条之间做的：

  1. ChatGPT 登录：用 ChatGPT workspace 凭据，浏览器完成认证，官方《Authentication》明确写了这条路”遵循 workspace 权限、RBAC 与企业留存设置”。
  2. API Key：需要 OpenAI 控制台的 API key，按标准 API 费率通过 OpenAI Platform 账户计费。CLI 侧官方给的写法是 printenv OPENAI_API_KEY | codex login --with-api-key。
  3. --oss 本地提供方：也就是本篇的主角，取值只有 lmstudio 和 ollama 两个。
  4. 自定义 model_providers：在 config.toml 里自己描述一个提供方，后面单独讲，它有一道硬门槛。

下面四个问题，按顺序问自己一遍，答案就出来了。

问题一：预算卡在哪一档

官方《Pricing》页给的个人档位是：Free 为 $0/month，Go 为 $8/month，Plus 为 $20/month，Pro 为 Starting at $100/month，另有 API Key 按 token 用量计费（ChatGPT 官方定价页，2026-08-09 核对，以官方为准）。用量口径这里要留神：官方计量单位是 messages（消息数），窗口是 5 小时滚动窗口，而且同一档位下区间跨度极大——Plus 是 10–2,000 messages / 5h，Pro 是 50–40,000 messages / 5h，官方明确说这取决于模型（Pro 还取决于档位）。所以别拿区间的某一端当成”我每天能跑多少”。

另外官方公告口径里有一条：限时内 Codex 包含在 ChatGPT Free 与 Go 中，并且 Plus、Pro、Business、Enterprise、Edu 的速率上限翻倍。这是限时活动，不是常规权益，规划预算时别把它当成长期基线。

跟 --oss 的关系是：官方定价页那张表覆盖的是订阅档位与 API token 计费，本地提供方不在这张计费表里。至于本地跑要付出什么代价（硬件、电、你自己的时间），那是你机器的事，官方文档没有这方面的口径，我也不替它下结论。

这一问的判断：如果你已经在付 Plus 或 Pro，还打算把主力工作放在 Codex 上，那 --oss 更像是补充路径而不是替代路径；如果你的诉求是”额度到底、临时顶一下”，--oss 才是这一问里唯一的正解。

问题二：数据要不要出本机

这是选 --oss 最常见的动机，也是最容易被过度解读的一条。可以确定的是：--oss 走的是本地提供方，不是 ChatGPT 云端账号那条通路。但请注意几个仍然存在的出网面：

  • --search 这个顶层选项，help 原文说的是开启实时联网搜索，启用后原生 Responses web_search 工具对模型可用，无逐次调用审批。这是一个明确的、你自己开的出网口子。
  • 配置键 web_search 官方默认值是 cached，取值有 disabled / cached / indexed / live——默认既不是关闭，也不是实时，这一点很多人想当然搞错。
  • 你挂的 MCP server、插件、hooks 各自会不会出网，跟你用哪个模型提供方是两回事。

我不会写”用了 --oss 数据就不会出去”这种话，因为出网面由你的整套配置决定，不由 --local-provider 一个选项决定。要收紧网络面，官方给的抓手在权限档里：permissions.<name>.network.enabled、permissions.<name>.network.mode（limited 或 full）、permissions.<name>.network.domains.<pattern>（allow 或 deny，支持精确主机与通配）。还有一个 features.network_proxy，它标注的是 experimental 阶段、默认 false，别当稳定功能往生产流程里塞。

问题三：要不要让它动你的文件

这一问和模型通路完全正交，但太多人把两件事混在一起，以为”接了本地模型就安全了”。沙箱边界跟模型在哪跑没有关系。

CLI 侧是 -s, --sandbox，官方给的三个取值是 read-only / workspace-write / danger-full-access，配置侧对应 sandbox_mode。官方对 workspace-write 标注的是默认模式；对 danger-full-access 的原文是”The agent runs without sandbox restrictions.”

审批策略 -a, --ask-for-approval 三档的官方释义分别是：untrusted 只有受信任命令（如 ls、cat、sed）免审批，其余升级给用户；on-request 由模型决定何时请求审批；never 从不询问，执行失败直接回传给模型。这里有个反直觉的地方值得单独记住：never 不等于放开权限，沙箱边界还在，它改变的只是”要不要问你”。真正撤掉边界的是 danger-full-access，或者那个官方原文写着 “EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed” 的 --dangerously-bypass-approvals-and-sandbox。

这一问的判断：换成本地模型之后，你对输出质量的信任度通常会下降，那么沙箱和审批就更该收紧而不是放松。别一边换本地模型一边顺手加 --dangerously-bypass-approvals-and-sandbox，这是最糟的组合。

问题四：有没有管理员权限

Windows 侧的沙箱是一套独立机制：官方《Windows sandbox》说明它在 PowerShell 中原生运行，强制 bounded filesystem and network permissions，不需要 WSL、不需要虚拟机，硬性要求是 winget 必须可用。两种模式的差别正好卡在管理员权限上：

模式官方口径
elevated官方标注为首选；使用专用的低权限沙箱用户，文件系统权限边界 + 防火墙规则；需要管理员批准的初始化设置
unelevated回退方案；用从当前用户派生的受限 Windows token 运行命令，基于 ACL 的文件系统边界，用环境级离线控制替代防火墙规则；官方自己写了保护更弱，但在拿不到管理员批准时可用

配置键是 windows.sandbox，另有 windows.sandbox_private_desktop（默认 true）。在 codex-cli 0.147.0（Windows 11）上，本机 config.toml 里是 [windows] sandbox = "elevated"，codex doctor 的 sandbox 行显示 restricted fs + restricted network · approval OnRequest。

关键结论：--oss 解决不了”没有管理员权限”这个问题。这两件事在不同的层上——模型跑在哪，和沙箱用哪种 Windows token 运行命令，互不影响。公司电脑没有管理员权限的话，你要面对的是 unelevated 这条回退路径，跟你用不用本地模型无关。

那 lmstudio 和 ollama 到底怎么选

在有依据的维度上，它们是对等的：都是 --local-provider 的合法取值，也都是 oss_provider 的合法取值，官方没有给出任何区分性描述。所以决策依据只能落在你自己这边——你本机已经装的是哪个、团队统一用的是哪个，就填哪个。真要横向评测，那是这两个工具本身的事，不是 Codex 这一层的事。

命令写法（都可以直接复制）：

# 用配置里的默认本地提供方，没配就按 CLI 的选择流程走
codex --oss

# 显式指定提供方
codex --oss --local-provider lmstudio
codex --oss --local-provider ollama

# 同时指定本次会话使用的模型（模型名填你本地实际加载的那个）
codex --oss --local-provider ollama -m <你本地的模型名>

写进配置文件（~/.codex/config.toml）省得每次敲：

oss_provider = "lmstudio"

也可以用顶层的 -c 临时覆盖。help 原文说 -c, --config <key=value> 覆盖 ~/.codex/config.toml 里的值，点号路径表示嵌套，value 按 TOML 解析，解析失败则按字面字符串处理：

codex -c oss_provider="ollama" --oss

Windows 用户注意一个纯 shell 层面的坑：官方给的 -c 示例（如 -c 'sandbox_permissions=["disk-full-read-access"]'）用单引号包住整个 key=value，这在 PowerShell 里的引号语义和 bash 不同。这是 shell 的规则不是 Codex 的规则，拿不准就别在命令行里跟引号较劲，直接写进 config.toml。

以上配置片段为按官方文档键位组合的示例，未逐项实测，以官方文档为准。

第三条路：自定义 model_providers，有一道硬门槛

如果你想接的不是 lmstudio / ollama，而是别的服务，那走的就不是 --oss 而是 model_providers.<id> 这一套。官方《Configuration Reference》里这张表的键包括 name、base_url、env_key（放 API key 的环境变量名）、env_key_instructions、requires_openai_auth（默认 false）、wire_api（默认 responses）、request_max_retries（默认 4）、stream_max_retries（默认 5）、stream_idle_timeout_ms（默认 300000）、supports_standalone_web_search（默认 false）等。

其中一条决定成败：wire_api 官方明确只支持 responses。也就是说对方必须提供 Responses 协议兼容的端点，不是随便一个”OpenAI 兼容接口”都能接进来。这一条我不会再往下推断具体哪家服务行不行——没有验证过的事，写出来就是害人。

另外 experimental_bearer_token 这个键官方标注了不建议使用，应改用 env_key。所以密钥应该以环境变量名的形式出现在配置里，配置文件里写的是变量名，不是 <YOUR_API_KEY> 本身。

配完之后怎么验收

三步，都是只读操作：

第一步，确认配置真的加载了。 跑 codex doctor --summary，盯 Configuration 组的 config 行。在 codex-cli 0.147.0（Windows 11）上，我故意执行 codex -c 'features=[unclosed' doctor --summary，命令并没有崩溃退出，doctor 照常跑完，但输出里出现了这一行：

✗ config       config could not be loaded - Fix the reported config error, then rerun codex doctor.

这个行为很有用：配置写坏了 CLI 不一定当场报错，但 doctor 会明确告诉你配置没加载成功。所以”我改了 oss_provider 怎么没生效”，第一步就该看这一行，而不是反复重启。

第二步，看端点可达性。 codex doctor --summary 的 Connectivity 组里有 reachability 这一项，在 codex-cli 0.147.0（Windows 11）上，本机观测到的说明文字是 “active provider endpoints are reachable over HTTP”。按字面看，这一项检查的就是当前生效提供方的端点——所以换到本地提供方之后，这是你首先该盯的位置。诚实交代：我们没有在本地提供方下跑过 doctor，具体输出以你自己机器上的为准。

第三步，别指望 --strict-config 帮你抓拼写错误。 在 codex-cli 0.147.0（Windows 11）上，我执行 codex -c model_reasoning_effortt=high --strict-config exec --help（键名故意多打了一个 t），结果是正常打印 help，没有报未知字段错误。说明这道校验发生在真正加载配置去跑会话的时候，--help 这类不进入会话的路径不触发它。所以拿 --help 去测配置对不对，测不出来。

顺带两个可以放心的点：codex doctor --json 的官方说明是 “Emit a redacted machine-readable report”，是脱敏的，贴到 issue 里相对安全；在 codex-cli 0.147.0（Windows 11）上，codex mcp list 的 Env 列实测把环境变量值打成 *****，只显示键名，同样自带脱敏。但 ~/.codex/auth.json 是另一回事——官方原话是把它当密码看待，别提交、别贴进工单、别发聊天窗。

什么情况下别走 --oss

  • 需要 workspace 权限、RBAC、企业留存设置生效时：这些是 ChatGPT 登录那条通路才带的（官方《Authentication》口径）。顺便说一句，--oss 和登录状态是两件事，官方没有”用了 --oss 就不需要登录”的说法，别自己推断。在 codex-cli 0.147.0（Windows 11）上，本机 codex login status 的输出就是一行 Logged in using ChatGPT，这一条命令随时能查。
  • 依赖云端集成、桌面应用或 IDE 那一侧能力时：这些面我们完全没有实测，官方文档给的做法是各自在对应的界面里登录与配置，本文不做转述。
  • 工作流强依赖实时联网搜索时：--search 与 web_search 的行为在本地提供方下是什么表现，官方文档没有给出这个组合的说明，我也没有实测数据，只能建议你自己在机器上验一遍再决定。

最后补一个 Windows 用户高频踩的无关坑：features.unified_exec 官方标注默认 true 但 Windows 除外；在 codex-cli 0.147.0（Windows 11）上，codex features list 实测 unified_exec 的生效值就是 false。所以如果你照着某篇教程操作，发现行为对不上，先确认那篇是不是在非 Windows 上写的——这跟你有没有接本地模型没关系。

相关阅读

本文依据 Codex 官方文档（learn.chatgpt.com/docs/ 的《Configuration Reference》《Codex CLI》《Pricing》《Sandbox》《Windows sandbox》《Authentication》页面）整理，核对日 2026-08-09；文中标注「本机实测」的部分基于 codex-cli 0.147.0 / Windows 11 环境下的只读命令输出。产品功能、模型与价格以官方最新说明为准。价格与活动随时可能调整，下单前请以官方页面为准。桌面应用与云端部分为官方文档口径，非本机实测。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员