在断网环境、内部代码仓库或需要控制推理成本的场景里不少开发者会尝试用 codex --oss 连接本机模型。这个参数并不是把云端模型下载到电脑也不会自动安装推理服务它的作用是让 Codex CLI 改用本地开放模型提供方。当前可直接选择 Ollama 或 LM Studio真正能否工作取决于本地服务是否启动、模型是否已下载、端口是否可访问以及模型本身能否稳定完成工具调用。一、先判断电脑是否适合跑本地模型本地模型的优势是代码和提示词可以留在自己控制的设备或网络里离线开发也更方便但硬件要求不能忽略。模型越大对内存、显存和磁盘空间的要求越高。只有普通办公笔记本时可以先从较小模型做连通性测试不要一开始就追求最大参数量。能回答聊天问题不代表能顺利阅读仓库、生成补丁并连续调用命令。还要分清“能启动”和“能完成编码任务”。本地推理速度慢、上下文窗口不足或工具调用格式不稳定时Codex 可能长时间停留在思考状态也可能给出文本建议却无法继续执行。首次测试最好选一个小型 Git 仓库让它读取两个文件、解释一段代码再修改一个低风险文件并运行短测试。二、Ollama 与 LM Studio 怎么选Ollama 更偏命令行和服务化使用适合熟悉终端、希望用脚本管理模型的用户。安装后需要拉取模型并确认服务正在监听本地端口。LM Studio 提供图形界面下载、加载模型和启动本地服务器比较直观适合希望先看界面状态再排错的人。两者都能作为本地提供方但模型文件、端口和启动方式互不通用。选择时不必纠结谁绝对更强。已经在团队里统一使用 Ollama就沿用现有模型和运维方式个人电脑想快速查看模型是否加载、显存占用和服务日志LM Studio 往往更省事。不要同时启动多个占用相同端口的服务否则看似模型已加载Codex 实际连接的可能是另一套进程。三、第一次运行 --oss 的正确顺序先启动 Ollama 或 LM Studio 的本地服务再打开新的终端运行 codex --oss。如果没有额外指定提供方Codex 会依据配置或提示让你在 LM Studio 与 Ollama 之间选择。也可以配合 --local-provider 明确本次使用哪一个例如只在当前会话切换到 Ollama不改动长期配置。本地提供方可用并不等于模型已经准备好。Ollama 需要确认目标模型存在且能单独响应LM Studio 需要把模型真正加载到内存并启动兼容接口。建议先用提供方自己的测试界面或命令发送一句简单请求确认服务返回正常再启动 Codex。这样可以把“模型服务故障”和“Codex 配置故障”分开。四、模型名称为什么容易配错本地模型名称通常由提供方管理可能包含组织名、模型名、参数规模、量化版本和标签。复制网页上的展示名称不一定等于服务接口返回的标识。遇到 model not found 时应从 Ollama 的本地模型列表或 LM Studio 当前服务器页面读取实际名称避免凭记忆手写。同一个基础模型的不同量化版本速度和质量可能差别很大。低精度版本更容易在有限硬件上运行但复杂重构、长上下文和严格 JSON 输出可能不稳定。测试时记录准确模型标识、上下文设置、首次响应时间和工具调用结果换模型后才能做有效比较。五、长期使用如何写入配置如果每次都用同一个本地提供方可以在 Codex 配置中设置 oss_provider临时运行时仍可用 --local-provider 覆盖。修改配置后先关闭旧会话再开新会话验证因为已经运行的进程通常不会自动采用全部新设置。团队电脑不要直接复制个人绝对路径应把模型服务地址、模型准备步骤和最低硬件要求单独记录。配置文件只负责告诉 Codex 选择什么并不能保证本地服务常驻。电脑重启、模型被卸载、端口变化或防火墙规则调整后原有配置仍在但连接会失败。把“启动模型服务”列入日常启动流程比出现错误后反复重写配置更可靠。六、连接失败时按四层排查第一层看进程提供方服务是否真的在运行。第二层看端口监听地址是否只允许本机端口是否被占用。第三层看模型目标模型是否已下载并加载。第四层看 Codex是否使用了预期的 provider 和模型。每次只改一个变量改完立刻发送最小请求不要同时换端口、换模型又改配置。如果出现 timeout先观察提供方日志。第一次加载模型可能需要较长时间不能立刻断定网络不通持续没有任何请求记录则更像地址或进程问题。返回 404 常见于接口路径或模型名不匹配返回内存不足则需要换更小模型、降低上下文或关闭占用显存的程序。七、用真实编码动作做验收连通后不要只问“你是谁”。让 Codex读取项目说明、定位一个函数、解释输入输出再要求它只修改一个文件。随后检查 diff运行项目已有的格式化和测试命令。能够稳定完成这组动作才说明本地模型至少具备基本代理能力。如果大家想体验一线 AI 编程模型 codex 和 claude用它们完成项目分析、代码修改和测试审查可以参考以下教程文档进行接入配置接入配置好后即可使用。文档教程https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg八、本地模型也需要权限边界请求留在本地不代表命令执行天然安全。Codex 仍可能读取工作区文件、写入代码或运行 shell 命令。敏感项目应继续使用只读或工作区写入沙箱重要命令保留人工审批。不要因为没有调用云端接口就让工具直接访问生产密钥、个人主目录或未备份的数据目录。团队使用时还要确认模型许可证、内部合规要求和日志留存方式。LM Studio 或 Ollama 的本地日志可能记录模型名、请求时间或错误信息排错后应按组织规则处理。模型文件来源也要可信避免下载来路不明的量化包。九、什么时候应该回到云端模型本地方案适合隐私优先、离线实验和轻量任务但复杂跨仓库重构、长时间代理任务或高要求代码审查可能更依赖强模型和稳定工具调用。发现本地模型反复偏离任务、无法维持格式、测试修复来回打转时应比较人工修正成本而不是只看接口费用为零。更实际的做法是分层使用本地模型承担代码解释、简单修改和敏感材料初步整理复杂任务再使用经过批准的云端模型。无论选哪条路线都保留小仓库基准任务定期验证模型升级后是否仍能读文件、改代码、跑测试和准确总结 diff。
在断网环境、内部代码仓库或需要控制推理成本的场景里不少开发者会尝试用 codex --oss 连接本机模型。这个参数并不是把云端模型下载到电脑也不会自动安装推理服务它的作用是让 Codex CLI 改用本地开放模型提供方。当前可直接选择 Ollama 或 LM Studio真正能否工作取决于本地服务是否启动、模型是否已下载、端口是否可访问以及模型本身能否稳定完成工具调用。一、先判断电脑是否适合跑本地模型本地模型的优势是代码和提示词可以留在自己控制的设备或网络里离线开发也更方便但硬件要求不能忽略。模型越大对内存、显存和磁盘空间的要求越高。只有普通办公笔记本时可以先从较小模型做连通性测试不要一开始就追求最大参数量。能回答聊天问题不代表能顺利阅读仓库、生成补丁并连续调用命令。还要分清“能启动”和“能完成编码任务”。本地推理速度慢、上下文窗口不足或工具调用格式不稳定时Codex 可能长时间停留在思考状态也可能给出文本建议却无法继续执行。首次测试最好选一个小型 Git 仓库让它读取两个文件、解释一段代码再修改一个低风险文件并运行短测试。二、Ollama 与 LM Studio 怎么选Ollama 更偏命令行和服务化使用适合熟悉终端、希望用脚本管理模型的用户。安装后需要拉取模型并确认服务正在监听本地端口。LM Studio 提供图形界面下载、加载模型和启动本地服务器比较直观适合希望先看界面状态再排错的人。两者都能作为本地提供方但模型文件、端口和启动方式互不通用。选择时不必纠结谁绝对更强。已经在团队里统一使用 Ollama就沿用现有模型和运维方式个人电脑想快速查看模型是否加载、显存占用和服务日志LM Studio 往往更省事。不要同时启动多个占用相同端口的服务否则看似模型已加载Codex 实际连接的可能是另一套进程。三、第一次运行 --oss 的正确顺序先启动 Ollama 或 LM Studio 的本地服务再打开新的终端运行 codex --oss。如果没有额外指定提供方Codex 会依据配置或提示让你在 LM Studio 与 Ollama 之间选择。也可以配合 --local-provider 明确本次使用哪一个例如只在当前会话切换到 Ollama不改动长期配置。本地提供方可用并不等于模型已经准备好。Ollama 需要确认目标模型存在且能单独响应LM Studio 需要把模型真正加载到内存并启动兼容接口。建议先用提供方自己的测试界面或命令发送一句简单请求确认服务返回正常再启动 Codex。这样可以把“模型服务故障”和“Codex 配置故障”分开。四、模型名称为什么容易配错本地模型名称通常由提供方管理可能包含组织名、模型名、参数规模、量化版本和标签。复制网页上的展示名称不一定等于服务接口返回的标识。遇到 model not found 时应从 Ollama 的本地模型列表或 LM Studio 当前服务器页面读取实际名称避免凭记忆手写。同一个基础模型的不同量化版本速度和质量可能差别很大。低精度版本更容易在有限硬件上运行但复杂重构、长上下文和严格 JSON 输出可能不稳定。测试时记录准确模型标识、上下文设置、首次响应时间和工具调用结果换模型后才能做有效比较。五、长期使用如何写入配置如果每次都用同一个本地提供方可以在 Codex 配置中设置 oss_provider临时运行时仍可用 --local-provider 覆盖。修改配置后先关闭旧会话再开新会话验证因为已经运行的进程通常不会自动采用全部新设置。团队电脑不要直接复制个人绝对路径应把模型服务地址、模型准备步骤和最低硬件要求单独记录。配置文件只负责告诉 Codex 选择什么并不能保证本地服务常驻。电脑重启、模型被卸载、端口变化或防火墙规则调整后原有配置仍在但连接会失败。把“启动模型服务”列入日常启动流程比出现错误后反复重写配置更可靠。六、连接失败时按四层排查第一层看进程提供方服务是否真的在运行。第二层看端口监听地址是否只允许本机端口是否被占用。第三层看模型目标模型是否已下载并加载。第四层看 Codex是否使用了预期的 provider 和模型。每次只改一个变量改完立刻发送最小请求不要同时换端口、换模型又改配置。如果出现 timeout先观察提供方日志。第一次加载模型可能需要较长时间不能立刻断定网络不通持续没有任何请求记录则更像地址或进程问题。返回 404 常见于接口路径或模型名不匹配返回内存不足则需要换更小模型、降低上下文或关闭占用显存的程序。七、用真实编码动作做验收连通后不要只问“你是谁”。让 Codex读取项目说明、定位一个函数、解释输入输出再要求它只修改一个文件。随后检查 diff运行项目已有的格式化和测试命令。能够稳定完成这组动作才说明本地模型至少具备基本代理能力。如果大家想体验一线 AI 编程模型 codex 和 claude用它们完成项目分析、代码修改和测试审查可以参考以下教程文档进行接入配置接入配置好后即可使用。文档教程https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg八、本地模型也需要权限边界请求留在本地不代表命令执行天然安全。Codex 仍可能读取工作区文件、写入代码或运行 shell 命令。敏感项目应继续使用只读或工作区写入沙箱重要命令保留人工审批。不要因为没有调用云端接口就让工具直接访问生产密钥、个人主目录或未备份的数据目录。团队使用时还要确认模型许可证、内部合规要求和日志留存方式。LM Studio 或 Ollama 的本地日志可能记录模型名、请求时间或错误信息排错后应按组织规则处理。模型文件来源也要可信避免下载来路不明的量化包。九、什么时候应该回到云端模型本地方案适合隐私优先、离线实验和轻量任务但复杂跨仓库重构、长时间代理任务或高要求代码审查可能更依赖强模型和稳定工具调用。发现本地模型反复偏离任务、无法维持格式、测试修复来回打转时应比较人工修正成本而不是只看接口费用为零。更实际的做法是分层使用本地模型承担代码解释、简单修改和敏感材料初步整理复杂任务再使用经过批准的云端模型。无论选哪条路线都保留小仓库基准任务定期验证模型升级后是否仍能读文件、改代码、跑测试和准确总结 diff。
