1. Windows 本地 Ollama 部署后 Codex 认证链路为什么总断在 Windows 上把 Ollama 跑起来其实不难难的是让 Codex 这类工具真正把请求发到你本地的模型上。我见过太多人卡在同一个地方Ollama 服务明明在跑ollama run qwen2.5-coder:7b也能正常对话但一进 VS Code 的 Codex 插件就报错要么是401 Unauthorized要么是local proxy failed要么干脆reading choices读不到内容。问题不在模型而在认证链路和 Base URL 的配置上。先说清楚这套方案是什么、能做什么、适合谁。Ollama 是一个在 Windows 上本地运行开源大模型的运行时它把模型权重、推理引擎、HTTP 服务打包成一个后台进程默认监听127.0.0.1:11434。Codex 是 OpenAI 推出的编码代理工具最新版把认证信息放在auth.json里通过 Base URL 决定请求发往哪里。把这两者接起来你就能在 VS Code 里用本地模型做代码补全、解释、重构延迟低、数据不出本机。适合的人群很明确有 16GB 以上内存、8GB 以上显存的 Windows 开发者想在 VS Code 里调用大模型但不想每次都走云端。但这里有个关键认知Ollama 的 API 和 OpenAI 的 API 并不完全兼容。Ollama 提供的是/api/chat和/api/generate而 Codex 期望的是/v1/chat/completions。所以你不能简单地把 Base URL 指向http://127.0.0.1:11434就完事中间需要一层协议转换。这就是为什么很多人配完之后 Codex 只回答问题、不自己干活——协议对不上工具调用tool calling的字段被丢掉了。我试过的路径是这样的本地 Ollama 负责跑模型TaoToken 负责提供兼容 OpenAI 协议的接入层和认证管理Codex 的auth.json指向 TaoToken 的 API 地址模型 ID 填本地拉取的模型名。这样 Codex 发出来的/v1/chat/completions请求能被正确解析工具调用也能透传。下面把每一步拆开讲包括可复制的配置片段和验证动作。2. TaoToken 前置准备与 Codex auth.json 定位在动手改配置之前先把两件事准备好TaoToken 的 API Key以及 Codex 的auth.json文件位置。这两样东西决定了后面所有配置能不能跑通。TaoToken 在这里的角色是提供 OpenAI 兼容的 API 入口和密钥管理。你需要在官网注册后进入控制台创建 API Key。地址是https://taotoken.net/api控制台里可以生成和管理 Key。拿到 Key 之后先记下来格式通常是一串以sk-开头的字符串。这个 Key 后面要写进 Codex 的auth.json同时 Base URL 指向 TaoToken 的 API 地址。然后是 Codex 的auth.json。最新版 Codex 在 Windows 上的认证文件位置通常在用户目录下的.codex文件夹里完整路径类似C:\Users\你的用户名\.codex\auth.json。如果你装的是 VS Code 的 Codex 插件它可能还会在插件自己的存储目录里放一份配置。最稳妥的办法是先在 VS Code 里登录一次 Codex让它自动生成auth.json然后你再手动改里面的字段。如果文件不存在可以手动创建Codex 启动时会读取。这里要提醒一个坑Codex 的认证链路分两层。第一层是auth.json里的 API Key第二层是 Base URL 指向的服务端。很多人只改了 Key 没改 Base URL结果请求还是发到默认的云端地址自然报 401。所以两个字段必须一起改。另外Ollama 那边要确认服务在跑。打开 PowerShell 执行ollama list能看到你拉取的模型列表就说明服务正常。如果提示连接失败去任务管理器的后台进程里找ollama.exe没有的话从开始菜单启动 Ollama。模型存储路径建议改到非系统盘默认在C:\Users\用户名\.ollama\models模型文件动辄几个 GB放 C 盘容易把系统盘撑满。改路径在 Ollama 设置里操作改完重启服务生效。准备工作做完你应该手上有三样东西TaoToken 的 API Key、Codex 的auth.json路径、Ollama 里已拉取的模型名比如qwen2.5-coder:7b。接下来进入配置环节。3. 可复制配置auth.json 与 Base URL 完整片段这一节是整篇的核心配置写错一个字后面全白搭。我把auth.json的完整结构和关键字段拆开讲你直接照着改就行。先看auth.json的典型结构。用文本编辑器打开C:\Users\你的用户名\.codex\auth.json内容大致是这样{ OPENAI_API_KEY: sk-你的TaoToken密钥, OPENAI_BASE_URL: https://taotoken.net/api/v1, OPENAI_MODEL: qwen2.5-coder:7b, tokens: { access_token: sk-你的TaoToken密钥, refresh_token: } }三个字段必须对齐OPENAI_API_KEY填 TaoToken 控制台生成的 KeyOPENAI_BASE_URL填https://taotoken.net/api/v1注意结尾的/v1不能少Codex 会在这个地址后面拼/chat/completions。OPENAI_MODEL填你在 Ollama 里拉取的模型名必须和ollama list显示的一模一样大小写和冒号都不能错。如果你用的是 VS Code 的 Codex 插件它可能还会读一个settings.json。在 VS Code 里按CtrlShiftP输入Preferences: Open User Settings (JSON)在打开的settings.json里加上{ codex.baseUrl: https://taotoken.net/api/v1, codex.apiKey: sk-你的TaoToken密钥, codex.model: qwen2.5-coder:7b }这样插件层和认证层的配置就一致了。注意codex.baseUrl和auth.json里的OPENAI_BASE_URL要指向同一个地址否则会出现插件读一个地址、认证读另一个地址的混乱情况。如果你用的是 Cline 或 CC Switch 这类工具配置逻辑类似核心三件套永远是 Base URL、Key、Model ID。以 Cline 的 MCP 配置为例在cline_mcp_settings.json里写{ mcpServers: { taotoken: { command: npx, args: [-y, taotoken/mcp-server], env: { TAOTOKEN_API_KEY: sk-你的TaoToken密钥, TAOTOKEN_BASE_URL: https://taotoken.net/api/v1, TAOTOKEN_MODEL: qwen2.5-coder:7b } } } }这里TAOTOKEN_BASE_URL同样指向https://taotoken.net/api/v1TAOTOKEN_MODEL填本地模型名。Cline 通过 MCP 协议调用时会把请求转发到 TaoToken 的兼容层再由兼容层路由到你的本地 Ollama。配置改完记得重启 Codex 和 VS Code。很多人改完不重启插件还在用旧的配置缓存报错依旧。重启之后进入下一步验证。4. 验证请求一次对话请求的完整动作与成功结果配置写完不算完必须发一次真实请求确认链路通了。这一步我给你一个可复现的验证动作从命令行到 VS Code 插件都覆盖。先在 PowerShell 里用 curl 直接打 TaoToken 的接口确认 Key 和 Base URL 本身没问题curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d { model: qwen2.5-coder:7b, messages: [ {role: user, content: 用一句话说明快速排序的核心思想} ], stream: false }如果返回的 JSON 里有choices数组且choices[0].message.content里有正常的中文回答说明 TaoToken 这一层通了。如果返回401检查 Key 有没有复制错、有没有多余空格。如果返回model not found检查模型名和ollama list是否一致。命令行通了之后进 VS Code 验证插件。打开一个.py或.js文件选中一段代码右键选择 Codex 的解释或重构功能。正常情况下几秒内会在侧边栏或内联提示里看到模型返回的结果。如果插件报local proxy failed说明插件没有正确读取auth.json去检查settings.json里的codex.baseUrl是否和auth.json一致。再验证一次工具调用能力这是区分“只回答问题”和“真正干活”的关键。在 Codex 对话框里输入“帮我在当前目录创建一个 hello.py内容打印 hello world”。如果 Codex 能生成文件创建的动作并执行说明工具调用字段被正确透传了。如果它只是回复一段代码文本而不执行说明协议转换层丢了tool_calls字段需要检查 TaoToken 的兼容层配置。成功的结果长这样命令行 curl 返回带choices的 JSONVS Code 插件能返回代码解释Codex 能执行文件创建动作。三个都过链路就算打通了。5. 常见报错对照401、local proxy failed、reading choices 排查这一节把最常见的四类报错和对应解法列出来你对着自己的报错找。401 Unauthorized出现频率最高。原因通常是三个Key 写错、Key 过期、Base URL 没带/v1。先检查auth.json里的OPENAI_API_KEY和 TaoToken 控制台里的是否完全一致注意不要有多余的引号或空格。然后确认OPENAI_BASE_URL是https://taotoken.net/api/v1结尾的/v1必须有。如果 Key 是刚生成的等一分钟再试有时候控制台有同步延迟。local proxy failed通常出现在 VS Code 插件层。意思是插件尝试连接本地代理但失败了。检查两处一是settings.json里的codex.baseUrl是否指向https://taotoken.net/api/v1二是 Ollama 服务是否在跑。在 PowerShell 里执行ollama list如果报连接错误去任务管理器启动 Ollama。还有一种情况是端口冲突Ollama 默认用11434如果被其他程序占用Ollama 会启动失败。用netstat -ano | findstr 11434查一下端口占用情况。reading choices报错说明请求发出去了、也收到响应了但响应结构里没有choices字段。这通常是协议不匹配导致的——Ollama 原生返回的是/api/chat格式而 Codex 期望/v1/chat/completions格式。确认你的 Base URL 指向的是 TaoToken 的兼容层而不是直接指向http://127.0.0.1:11434。直连 Ollama 原生端口就会出现这个问题。OAuth相关报错说明 Codex 还在尝试走云端认证流程。检查auth.json里是否还有残留的refresh_token或id_token字段把它们清空或删掉。Codex 看到这些字段会优先走 OAuth 刷新而不是用你配置的 API Key。清空后重启 Codex。还有一个隐蔽的坑模型名大小写。qwen2.5-coder:7b和Qwen2.5-Coder:7B在 Ollama 里是两个不同的标识写错了会报model not found。以ollama list的输出为准直接复制粘贴。6. 从本地模型到 Codex 调用的稳定接入建议配置跑通之后还有几个实践层面的建议能让这套方案更稳定。模型选择上7B 级别的编码模型在 16GB 内存的机器上跑得比较舒服qwen2.5-coder:7b是平衡点。如果机器只有 8GB 内存换 3B 级别的模型否则 VS Code 会卡到没法用。显存 8GB 以上可以开 GPU 加速Ollama 会自动检测 NVIDIA CUDA你在任务管理器里能看到 GPU 占用率上去推理速度明显快于纯 CPU。模型存储路径一定要改到非系统盘。默认路径在 C 盘用户目录下一个 7B 模型量化后大约 4-5GB多拉几个模型 C 盘就红了。在 Ollama 设置里改到D:\OllamaModels这类路径改完重启服务。关于长期编码和 Agent 场景如果你打算把 Codex 当作日常编码代理来用建议走 Coding Plan 的接入方式它在并发和稳定性上比单次 API 调用更适合持续交互。地址是https://taotoken.net/api下的 coding-plan 入口。如果只是偶尔验证模型效果用模型对话页面就够了。最后说一个我踩过的坑改完auth.json之后Codex 有时候会缓存旧的认证信息。如果确认配置没错但报错依旧把C:\Users\用户名\.codex目录下的缓存文件清掉只保留auth.json然后重启 Codex。这个动作能解决大部分“配置明明对了却不生效”的问题。整套链路的核心就三件事Ollama 跑本地模型、TaoToken 提供兼容层和认证、Codex 的auth.json指向正确的 Base URL 和模型 ID。三件套对齐从本地模型到 Codex 调用就能稳定复现。 
长河君 · 2026/9/30 2:35:21 · 阅读 1.2k Windows 电脑部署 Ollama 大模型并接入最新版 Codex 经验分享：把 Codex auth.json 改到 TaoToken
1. Windows 本地 Ollama 部署后 Codex 认证链路为什么总断在 Windows 上把 Ollama 跑起来其实不难难的是让 Codex 这类工具真正把请求发到你本地的模型上。我见过太多人卡在同一个地方Ollama 服务明明在跑ollama run qwen2.5-coder:7b也能正常对话但一进 VS Code 的 Codex 插件就报错要么是401 Unauthorized要么是local proxy failed要么干脆reading choices读不到内容。问题不在模型而在认证链路和 Base URL 的配置上。先说清楚这套方案是什么、能做什么、适合谁。Ollama 是一个在 Windows 上本地运行开源大模型的运行时它把模型权重、推理引擎、HTTP 服务打包成一个后台进程默认监听127.0.0.1:11434。Codex 是 OpenAI 推出的编码代理工具最新版把认证信息放在auth.json里通过 Base URL 决定请求发往哪里。把这两者接起来你就能在 VS Code 里用本地模型做代码补全、解释、重构延迟低、数据不出本机。适合的人群很明确有 16GB 以上内存、8GB 以上显存的 Windows 开发者想在 VS Code 里调用大模型但不想每次都走云端。但这里有个关键认知Ollama 的 API 和 OpenAI 的 API 并不完全兼容。Ollama 提供的是/api/chat和/api/generate而 Codex 期望的是/v1/chat/completions。所以你不能简单地把 Base URL 指向http://127.0.0.1:11434就完事中间需要一层协议转换。这就是为什么很多人配完之后 Codex 只回答问题、不自己干活——协议对不上工具调用tool calling的字段被丢掉了。我试过的路径是这样的本地 Ollama 负责跑模型TaoToken 负责提供兼容 OpenAI 协议的接入层和认证管理Codex 的auth.json指向 TaoToken 的 API 地址模型 ID 填本地拉取的模型名。这样 Codex 发出来的/v1/chat/completions请求能被正确解析工具调用也能透传。下面把每一步拆开讲包括可复制的配置片段和验证动作。2. TaoToken 前置准备与 Codex auth.json 定位在动手改配置之前先把两件事准备好TaoToken 的 API Key以及 Codex 的auth.json文件位置。这两样东西决定了后面所有配置能不能跑通。TaoToken 在这里的角色是提供 OpenAI 兼容的 API 入口和密钥管理。你需要在官网注册后进入控制台创建 API Key。地址是https://taotoken.net/api控制台里可以生成和管理 Key。拿到 Key 之后先记下来格式通常是一串以sk-开头的字符串。这个 Key 后面要写进 Codex 的auth.json同时 Base URL 指向 TaoToken 的 API 地址。然后是 Codex 的auth.json。最新版 Codex 在 Windows 上的认证文件位置通常在用户目录下的.codex文件夹里完整路径类似C:\Users\你的用户名\.codex\auth.json。如果你装的是 VS Code 的 Codex 插件它可能还会在插件自己的存储目录里放一份配置。最稳妥的办法是先在 VS Code 里登录一次 Codex让它自动生成auth.json然后你再手动改里面的字段。如果文件不存在可以手动创建Codex 启动时会读取。这里要提醒一个坑Codex 的认证链路分两层。第一层是auth.json里的 API Key第二层是 Base URL 指向的服务端。很多人只改了 Key 没改 Base URL结果请求还是发到默认的云端地址自然报 401。所以两个字段必须一起改。另外Ollama 那边要确认服务在跑。打开 PowerShell 执行ollama list能看到你拉取的模型列表就说明服务正常。如果提示连接失败去任务管理器的后台进程里找ollama.exe没有的话从开始菜单启动 Ollama。模型存储路径建议改到非系统盘默认在C:\Users\用户名\.ollama\models模型文件动辄几个 GB放 C 盘容易把系统盘撑满。改路径在 Ollama 设置里操作改完重启服务生效。准备工作做完你应该手上有三样东西TaoToken 的 API Key、Codex 的auth.json路径、Ollama 里已拉取的模型名比如qwen2.5-coder:7b。接下来进入配置环节。3. 可复制配置auth.json 与 Base URL 完整片段这一节是整篇的核心配置写错一个字后面全白搭。我把auth.json的完整结构和关键字段拆开讲你直接照着改就行。先看auth.json的典型结构。用文本编辑器打开C:\Users\你的用户名\.codex\auth.json内容大致是这样{ OPENAI_API_KEY: sk-你的TaoToken密钥, OPENAI_BASE_URL: https://taotoken.net/api/v1, OPENAI_MODEL: qwen2.5-coder:7b, tokens: { access_token: sk-你的TaoToken密钥, refresh_token: } }三个字段必须对齐OPENAI_API_KEY填 TaoToken 控制台生成的 KeyOPENAI_BASE_URL填https://taotoken.net/api/v1注意结尾的/v1不能少Codex 会在这个地址后面拼/chat/completions。OPENAI_MODEL填你在 Ollama 里拉取的模型名必须和ollama list显示的一模一样大小写和冒号都不能错。如果你用的是 VS Code 的 Codex 插件它可能还会读一个settings.json。在 VS Code 里按CtrlShiftP输入Preferences: Open User Settings (JSON)在打开的settings.json里加上{ codex.baseUrl: https://taotoken.net/api/v1, codex.apiKey: sk-你的TaoToken密钥, codex.model: qwen2.5-coder:7b }这样插件层和认证层的配置就一致了。注意codex.baseUrl和auth.json里的OPENAI_BASE_URL要指向同一个地址否则会出现插件读一个地址、认证读另一个地址的混乱情况。如果你用的是 Cline 或 CC Switch 这类工具配置逻辑类似核心三件套永远是 Base URL、Key、Model ID。以 Cline 的 MCP 配置为例在cline_mcp_settings.json里写{ mcpServers: { taotoken: { command: npx, args: [-y, taotoken/mcp-server], env: { TAOTOKEN_API_KEY: sk-你的TaoToken密钥, TAOTOKEN_BASE_URL: https://taotoken.net/api/v1, TAOTOKEN_MODEL: qwen2.5-coder:7b } } } }这里TAOTOKEN_BASE_URL同样指向https://taotoken.net/api/v1TAOTOKEN_MODEL填本地模型名。Cline 通过 MCP 协议调用时会把请求转发到 TaoToken 的兼容层再由兼容层路由到你的本地 Ollama。配置改完记得重启 Codex 和 VS Code。很多人改完不重启插件还在用旧的配置缓存报错依旧。重启之后进入下一步验证。4. 验证请求一次对话请求的完整动作与成功结果配置写完不算完必须发一次真实请求确认链路通了。这一步我给你一个可复现的验证动作从命令行到 VS Code 插件都覆盖。先在 PowerShell 里用 curl 直接打 TaoToken 的接口确认 Key 和 Base URL 本身没问题curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d { model: qwen2.5-coder:7b, messages: [ {role: user, content: 用一句话说明快速排序的核心思想} ], stream: false }如果返回的 JSON 里有choices数组且choices[0].message.content里有正常的中文回答说明 TaoToken 这一层通了。如果返回401检查 Key 有没有复制错、有没有多余空格。如果返回model not found检查模型名和ollama list是否一致。命令行通了之后进 VS Code 验证插件。打开一个.py或.js文件选中一段代码右键选择 Codex 的解释或重构功能。正常情况下几秒内会在侧边栏或内联提示里看到模型返回的结果。如果插件报local proxy failed说明插件没有正确读取auth.json去检查settings.json里的codex.baseUrl是否和auth.json一致。再验证一次工具调用能力这是区分“只回答问题”和“真正干活”的关键。在 Codex 对话框里输入“帮我在当前目录创建一个 hello.py内容打印 hello world”。如果 Codex 能生成文件创建的动作并执行说明工具调用字段被正确透传了。如果它只是回复一段代码文本而不执行说明协议转换层丢了tool_calls字段需要检查 TaoToken 的兼容层配置。成功的结果长这样命令行 curl 返回带choices的 JSONVS Code 插件能返回代码解释Codex 能执行文件创建动作。三个都过链路就算打通了。5. 常见报错对照401、local proxy failed、reading choices 排查这一节把最常见的四类报错和对应解法列出来你对着自己的报错找。401 Unauthorized出现频率最高。原因通常是三个Key 写错、Key 过期、Base URL 没带/v1。先检查auth.json里的OPENAI_API_KEY和 TaoToken 控制台里的是否完全一致注意不要有多余的引号或空格。然后确认OPENAI_BASE_URL是https://taotoken.net/api/v1结尾的/v1必须有。如果 Key 是刚生成的等一分钟再试有时候控制台有同步延迟。local proxy failed通常出现在 VS Code 插件层。意思是插件尝试连接本地代理但失败了。检查两处一是settings.json里的codex.baseUrl是否指向https://taotoken.net/api/v1二是 Ollama 服务是否在跑。在 PowerShell 里执行ollama list如果报连接错误去任务管理器启动 Ollama。还有一种情况是端口冲突Ollama 默认用11434如果被其他程序占用Ollama 会启动失败。用netstat -ano | findstr 11434查一下端口占用情况。reading choices报错说明请求发出去了、也收到响应了但响应结构里没有choices字段。这通常是协议不匹配导致的——Ollama 原生返回的是/api/chat格式而 Codex 期望/v1/chat/completions格式。确认你的 Base URL 指向的是 TaoToken 的兼容层而不是直接指向http://127.0.0.1:11434。直连 Ollama 原生端口就会出现这个问题。OAuth相关报错说明 Codex 还在尝试走云端认证流程。检查auth.json里是否还有残留的refresh_token或id_token字段把它们清空或删掉。Codex 看到这些字段会优先走 OAuth 刷新而不是用你配置的 API Key。清空后重启 Codex。还有一个隐蔽的坑模型名大小写。qwen2.5-coder:7b和Qwen2.5-Coder:7B在 Ollama 里是两个不同的标识写错了会报model not found。以ollama list的输出为准直接复制粘贴。6. 从本地模型到 Codex 调用的稳定接入建议配置跑通之后还有几个实践层面的建议能让这套方案更稳定。模型选择上7B 级别的编码模型在 16GB 内存的机器上跑得比较舒服qwen2.5-coder:7b是平衡点。如果机器只有 8GB 内存换 3B 级别的模型否则 VS Code 会卡到没法用。显存 8GB 以上可以开 GPU 加速Ollama 会自动检测 NVIDIA CUDA你在任务管理器里能看到 GPU 占用率上去推理速度明显快于纯 CPU。模型存储路径一定要改到非系统盘。默认路径在 C 盘用户目录下一个 7B 模型量化后大约 4-5GB多拉几个模型 C 盘就红了。在 Ollama 设置里改到D:\OllamaModels这类路径改完重启服务。关于长期编码和 Agent 场景如果你打算把 Codex 当作日常编码代理来用建议走 Coding Plan 的接入方式它在并发和稳定性上比单次 API 调用更适合持续交互。地址是https://taotoken.net/api下的 coding-plan 入口。如果只是偶尔验证模型效果用模型对话页面就够了。最后说一个我踩过的坑改完auth.json之后Codex 有时候会缓存旧的认证信息。如果确认配置没错但报错依旧把C:\Users\用户名\.codex目录下的缓存文件清掉只保留auth.json然后重启 Codex。这个动作能解决大部分“配置明明对了却不生效”的问题。整套链路的核心就三件事Ollama 跑本地模型、TaoToken 提供兼容层和认证、Codex 的auth.json指向正确的 Base URL 和模型 ID。三件套对齐从本地模型到 Codex 调用就能稳定复现。