Codex桌面端computer-use插件不可用且marketplace不显示：把settings改到TaoToken

1. Windows 下 Codex 桌面端 computer-use 插件不可用与 marketplace 不显示的真实场景Codex 桌面端在 Windows 上有一个很典型的现象第一次装好之后Computer Use 插件能正常调用浏览器控制、截图、点击这些动作都跑得通。但关掉客户端再打开插件页里 Computer Use 变成灰色不可用去插件市场里搜computer-use或者chrome也搜不到好像这个 bundled 插件从来没存在过。这个问题的核心检索词就是 Codex 桌面端 computer-use 插件不可用、marketplace 不显示属于 Windows 文件锁导致的 bundled 插件半更新问题。我先把结论说清楚这不是插件本身坏了也不是账号权限问题而是 Codex Desktop 在 Windows 用户目录里维护的一套 bundled marketplace 缓存出现了半更新状态。Codex 把openai-bundled这个内置插件市场放在%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled下面同时把 chrome、computer-use 这些插件的实际运行文件缓存到%USERPROFILE%\.codex\plugins\cache\openai-bundled。当客户端更新、重装或者异常退出时extension-host.exe、codex-computer-use.exe这些后台进程可能还占着文件句柄导致缓存目录只复制了一半marketplace.json缺失或者latest软链接指向了一个临时目录。一旦出现这种情况Codex 启动时扫描 bundled marketplace 就会失败表现就是插件市场里看不到computer-useopenai-bundled设置页里 Computer Use 显示 unavailable。日志里通常能看到EBUSY、resource busy or locked、plugin_cache_windows_file_lock、os error 5这些关键词插件页点进去还会报marketplace file %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\.agents\plugins\marketplace.json does not exist。适合读这篇的人有三类一是 Windows 上用 Codex 桌面端、想用 Computer Use 做浏览器自动化的开发者二是插件市场里搜不到 bundled 插件、想搞清楚缓存目录结构的人三是准备把 Codex 的 endpoint 和鉴权统一指向 TaoToken 通道、顺便把插件环境修干净的团队。下面我会先讲清楚问题根因和目录结构再给出可复制的 settings 配置片段把 endpoint 与鉴权指向 TaoToken 统一 Key/API 通道最后附上重启客户端后插件列表刷新与可用性验证的完整步骤。需要提前说明的是本文处理的是 Windows 文件锁导致的 bundled 插件缓存损坏不涉及任何网络访问方式的调整。如果你日志里的主要错误是os error 740或者请求的操作需要提升那属于 Windows sandbox 权限问题不在本文范围内需要单独排查。另外修复过程中不要打印、复制或暴露任何 API key、登录 token、auth.json 内容这一点在后面的脚本里也会体现。2. TaoToken 前置准备统一 Key 与 API 通道让 Codex 插件环境可复现在动手修插件之前先把 Codex 的模型通道固定下来这样后面重启客户端验证插件时不会因为 endpoint 或鉴权问题干扰判断。TaoToken 提供统一的 Key 和 API 通道官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 注意 API 地址后面不加 UTM 参数。你需要先拿到一个可用的 Key。登录后进入控制台在 API Keys 页面创建一个新 Key复制出来备用。这个 Key 后面会写进 Codex 的 settings 配置里作为统一的鉴权凭据。如果你还没注册可以先通过模型对话页面快速验证通道是否可用确认返回正常后再去创建 Key。Codex 桌面端在 Windows 上的配置主要落在两个位置一个是%USERPROFILE%\.codex\config.toml负责模型 provider、插件启用状态这些另一个是客户端自身的 settings 文件负责 endpoint 和鉴权。我们要做的是把 endpoint 指向 TaoToken 的 API 基址把鉴权指向刚才创建的 Key同时保留 bundled 插件的启用配置。这里有一个关键点Codex 的插件系统和模型通道是两套东西。插件不可用是文件锁和缓存问题模型通道是 endpoint 和 Key 问题。两者分开处理但都要在同一个 settings 文件里体现这样重启客户端后一次验证到位。我试过把这两块拆开改结果重启后插件列表刷新了但模型请求 401又得回头查 Key所以建议一次性配好。TaoToken 的 Coding Plan 适合长期编码和 Agent 场景如果你打算把 Codex 当日常编码助手用可以走 coding-plan 页面了解额度方案。模型对话页面适合临时验证某个模型是否可用接入文档页面则给出了不同客户端的接入细节。这三个入口在后面的 CTA 部分会分别给出这里先记住排障和接入看 API Keys 加接入文档验证模型看模型对话长期编码看 Coding Plan。配置前还要确认一件事Codex 桌面端是否已经安装并且至少启动过一次。因为 bundled marketplace 的源目录在安装包里路径是%ProgramFiles%\WindowsApps\OpenAI.Codex_*_x64__2p2nqsd0c76g0\app\resources\plugins\openai-bundled只有装过客户端这个目录才存在。如果这个目录找不到后面的修复脚本会直接报错提示你先确认 Codex Desktop 已安装且 WindowsApps 可访问。另外提醒一句修复脚本里会用到$env:USERPROFILE、$env:LOCALAPPDATA、$env:ProgramFiles这些环境变量不要写死某个用户名。这样脚本在不同机器上都能跑也避免把个人路径泄露到日志里。下面进入具体的可复制配置环节。3. 可复制配置settings 片段把 endpoint 与鉴权指向 TaoToken这一节给出可以直接复制的配置片段。Codex 桌面端的 settings 文件通常是 JSON 格式路径在%USERPROFILE%\.codex\下面具体文件名以你客户端版本为准常见的是config.toml配合一个 settings JSON。下面先给 JSON 片段再给 TOML 片段你按自己客户端的实际格式选用。先看 JSON 格式的 settings 片段。把 endpoint 指向 TaoToken 的 API 基址鉴权用 Bearer 加你的 Key模型 ID 按你实际要用的填{ endpoint: https://taotoken.net/api, apiKey: sk-你的TaoTokenKey, model: gpt-4o, provider: { name: taotoken, baseURL: https://taotoken.net/api, apiKey: sk-你的TaoTokenKey }, plugins: { chromeopenai-bundled: { enabled: true }, computer-useopenai-bundled: { enabled: true }, browseropenai-bundled: { enabled: true } } }如果你用的是 TOML 格式的config.toml对应片段如下。注意 provider 段和 plugins 段要分开写不要混在一起[endpoint] base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model gpt-4o [plugins.chromeopenai-bundled] enabled true [plugins.computer-useopenai-bundled] enabled true [plugins.browseropenai-bundled] enabled true这里要强调三件套Base URL、Key、Model ID。Base URL 是https://taotoken.net/apiKey 是你从控制台创建的sk-开头的字符串Model ID 按你要用的模型填。这三者缺一不可只填 Base URL 不填 Key 会 401只填 Key 不填 Model ID 会在请求时读不到 choices。如果你用的是 CC Switch 或者 Cline MCP 这类工具来管理 Codex 配置同样要把这三件套写进对应的配置文件。CC Switch 的配置里 Base URL 填 TaoToken 的 API 基址Key 填你的 KeyModel ID 填模型名。Cline MCP 的配置里也是同样的三件套不要只改其中一项。对于 Codex 的auth.json如果你之前手动改过建议先备份再改。auth.json 里通常存的是登录态不要和 API Key 混在一起。我们的做法是模型通道走 settings 里的 endpoint 和 apiKey登录态保持原样这样不会互相干扰。如果你不确定 auth.json 里有什么就不要动它只改 settings 文件。配置改完后先不要急着重启客户端。因为插件缓存可能还是坏的重启后插件列表依然不显示。正确的顺序是先按第 4 节的脚本修复 bundled marketplace 缓存再重启客户端最后验证插件列表和模型请求。这个顺序很重要反过来做会浪费一次重启。还有一点配置里的 Key 不要提交到任何公开仓库也不要在日志里打印。修复脚本里我们会刻意避开读取和输出 auth.json 内容就是为了防止 Key 泄露。如果你在团队里共享配置把 Key 换成环境变量引用比如apiKey: ${TAOTOKEN_API_KEY}然后在系统环境变量里设置真实值。4. 验证请求与成功结果重启客户端后插件列表刷新与可用性验证配置和缓存修复都做完之后进入验证环节。这一步的目标是确认三件事bundled marketplace 文件完整、插件列表里能看到 computer-use 和 chrome、模型请求能正常返回。下面按顺序给出可复制的 PowerShell 命令和预期结果。先验证 bundled marketplace 文件是否完整。打开 PowerShell执行$CodexHome Join-Path $env:USERPROFILE .codex $BundledTmpRoot Join-Path $CodexHome .tmp\bundled-marketplaces\openai-bundled $BundledMarketplaceJson Join-Path $BundledTmpRoot .agents\plugins\marketplace.json Get-Content -LiteralPath $BundledMarketplaceJson -Raw | ConvertFrom-Json | Out-Null Test-Path -LiteralPath (Join-Path $BundledTmpRoot plugins\chrome\assets\google-chrome.png) Test-Path -LiteralPath (Join-Path $BundledTmpRoot plugins\computer-use\assets\app-icon.png)预期结果是第一行不报错说明 marketplace.json 是合法 JSON后面两行都返回True说明 chrome 和 computer-use 的图标资源都在。如果第一行报 JSON 解析错误说明 marketplace.json 还是坏的需要回到修复脚本重新复制源目录。接着验证插件缓存目录的 latest 指向。执行$PluginCacheRoot Join-Path $CodexHome plugins\cache\openai-bundled $ChromeCacheRoot Join-Path $PluginCacheRoot chrome $ComputerUseCacheRoot Join-Path $PluginCacheRoot computer-use Test-Path -LiteralPath (Join-Path $ChromeCacheRoot latest\scripts\browser-client.mjs) Test-Path -LiteralPath (Join-Path $ChromeCacheRoot latest\extension-host\windows\x64\extension-host.exe) Test-Path -LiteralPath (Join-Path $ComputerUseCacheRoot latest\scripts\computer-use-client.mjs) Test-Path -LiteralPath (Join-Path $ComputerUseCacheRoot latest\node_modules\oai\sky\bin\windows\codex-computer-use.exe)预期四行都返回True。如果某一行返回False说明对应的缓存文件缺失需要重新执行第 4.5 步的缓存重建。特别注意extension-host.exe和codex-computer-use.exe这两个可执行文件它们是插件实际运行的核心缺一个插件就会显示不可用。然后验证 native host JSON 不再指向不稳定路径。执行$ExtensionManifest Join-Path $env:LOCALAPPDATA OpenAI\extension\com.openai.codexextension.json $CodexNativeHosts Join-Path $CodexHome chrome-native-hosts.json $LocalNativeHosts Join-Path (Join-Path $env:LOCALAPPDATA OpenAI\Codex) chrome-native-hosts.json foreach ($jsonPath in ($ExtensionManifest, $CodexNativeHosts, $LocalNativeHosts)) { if (-not (Test-Path -LiteralPath $jsonPath)) { continue } $content Get-Content -LiteralPath $jsonPath -Raw if ($content -match [regex]::Escape(\chrome\latest\) -or $content -match [regex]::Escape(\.tmp\bundled-marketplaces\)) { throw native host JSON 仍然指向不稳定路径: $jsonPath } NativeHost path OK: $jsonPath }预期每个存在的 JSON 文件都输出NativeHost path OK。如果抛出异常说明 native host 还指向chrome\latest或.tmp临时目录需要回到第 4.6 步重新写入extension-host.exe的绝对路径。文件层面验证通过后重启 Codex Desktop。重启后打开插件页确认三件事Chrome 和 Computer Use 能点进去、插件图标恢复显示、computer-useopenai-bundled和chromeopenai-bundled状态是 installed 和 enabled。再去设置页看 Computer Use不再显示 unavailable。最后验证模型请求。在 Codex 里发一条简单消息比如让它列一下当前目录文件。如果返回正常说明 endpoint 和 Key 配置生效。如果返回 401检查 settings 里的 apiKey 是否填对如果返回reading choices相关错误检查 Model ID 是否填对如果返回local proxy failed检查 endpoint 是否写成了https://taotoken.net/api而不是其他地址。如果codex命令因为 WindowsApps alias 拒绝访问失败不要卡在这一步直接跳过命令行验证以客户端界面和文件检查结果为准。命令行只是辅助文件完整性和客户端插件列表才是最终判断依据。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 对照修复过程中最容易遇到的几类报错这里逐个对照。先看 401。401 通常出现在模型请求阶段说明鉴权没通过。检查 settings 里的 apiKey 是否是sk-开头的完整 Key有没有多余空格有没有被截断。如果你用的是环境变量引用确认环境变量在当前用户下能读到。401 和插件不可用是两回事插件不可用是文件问题401 是 Key 问题不要混在一起查。第二个是local proxy failed。这个报错说明 Codex 尝试走本地代理但失败了。检查 endpoint 是否写成了https://taotoken.net/api注意结尾不要多加斜杠也不要在 API 地址后面加 UTM 参数。如果你之前配过其他代理地址先清掉再填 TaoToken 的基址。这个报错和网络访问方式无关纯粹是 endpoint 配置问题。第三个是reading choices相关错误。这个通常出现在模型返回阶段说明请求发出去了但响应格式不对。最常见原因是 Model ID 填错比如填了一个 TaoToken 通道不支持的模型名。回到 settings 里确认 Model ID换成通道支持的模型再试。如果换了模型还是报这个错检查 Base URL 是否指向了正确的 API 路径。第四个是 OAuth 相关报错。如果你之前用 OAuth 登录过 Codexsettings 里可能残留了 OAuth 的 token 字段。我们的做法是模型通道走 apiKeyOAuth 登录态保持原样两者不要互相覆盖。如果 OAuth 报错影响启动先备份 auth.json再检查是不是 OAuth token 过期。不要为了修 OAuth 去动 apiKey 配置这两套鉴权是独立的。第五个是插件页报marketplace.json does not exist。这个直接对应第 4.4 步的 bundled marketplace 重建。检查%USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled\.agents\plugins\marketplace.json是否存在如果不存在从安装包源目录重新复制。复制后一定要用ConvertFrom-Json校验一次确保文件不是半截的。第六个是日志里出现EBUSY或resource busy or locked。这说明有进程还占着缓存目录的文件句柄。回到第 4.1 步先关掉 Chrome再停止extension-host和codex-computer-use进程等两秒再操作目录。不要强杀 Codex Desktop 主进程否则可能中断当前会话。如果停了进程还是 EBUSY检查是不是有其他工具在扫描.codex目录。第七个是os error 5拒绝访问。这个通常是权限问题确认你用的是当前用户权限不要用管理员权限去改用户目录下的文件否则可能造成权限混乱。如果确实需要提升权限先确认日志里是不是os error 740740 才是需要提升权限的场景5 一般是文件被占用。第八个是插件图标不加载。图标文件在plugins\chrome\assets\google-chrome.png和plugins\computer-use\assets\app-icon.png如果这两个文件缺失图标就不显示。回到第 4.5 步的缓存重建确认复制完整。图标不加载不影响插件功能但会影响判断建议一并修好。排查时建议按顺序来先看文件是否存在再看 JSON 是否合法再看进程是否占用最后看配置是否正确。不要一上来就删目录删了之后如果源目录找不到反而更麻烦。备份永远放在第一步。6. 语义一致 CTA按场景选择 TaoToken 入口修完插件、配好通道之后接下来按你的实际场景选择入口。如果你是排障和接入阶段需要看 API Keys 和接入文档前者用来创建和管理 Key后者给出不同客户端的接入细节。API Keys 页面地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 接入文档地址是 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。如果你只是想验证某个模型是否可用走模型对话页面地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。在对话页面里选模型、发消息确认返回正常后再回到 Codex 里配。如果你打算长期用 Codex 做编码和 Agent 任务走 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。Coding Plan 适合高频编码场景额度方案在页面里有说明。控制台入口是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 用来查看用量和管理账号。Claude Code 和 Anthropic 相关的接入入口是 https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 如果你同时用 Claude Code可以在这里看接入方式。最后给一个实用技巧修好插件后把%USERPROFILE%\.codex\plugins\cache\openai-bundled这个目录的完整路径记下来下次再遇到插件不可用先看这个目录里的latest指向哪里。如果指向.tmp临时目录直接按第 4.5 步重建不用从头排查。这个习惯能省不少时间。