Codex 的插件系统有时候会出现一个很别扭的问题：明明本地已经装过插件，缓存目录里也能看到插件文件，但 Codex 的插件列表里就是显示不全。
最常见的情况是 Browser、Computer Use、Chrome 这类插件突然不见，或者 marketplace 里看得到一些线索，但 UI 里没有完整展示。这个问题不一定是插件真的没了，也可能是本地配置、缓存、marketplace 元数据和 Codex UI 状态之间没有对齐。
我更倾向于先做一件事：不要手动乱删 .codex 目录，也不要一上来重装。先让 Codex 自己做一次“只修必要配置”的自查。
下面这段 Prompt 就是为这个场景准备的。
先明确这次要修什么
这段 Prompt 的目标不是强行打开所有插件，也不是绕过 Codex 的权限、账号或灰度限制。
它主要处理三类问题：
- 插件已经存在于本地缓存，但
config.toml里没有启用记录 - marketplace 本地可见，但配置里缺少必要字段
- Codex CLI 不可用或部分命令不可用时，仍然能通过文件检查继续排查
它会要求 Codex 先备份配置，再检查本地插件缓存和 marketplace 元数据，最后只做最小改动。
这里面有两个原则很重要：
第一，不删除原配置。
第二，不输出密钥、token、cookie、认证头、账号信息。
排查插件问题时，最怕的是一边修配置，一边把敏感信息打印出来。这个 Prompt 已经把这件事写进约束里。
直接复制这段 Prompt
新开一个 Codex 线程，把下面内容完整贴进去即可。
请帮我修复 Codex 插件显示不全的问题。目标是：
让本机已经安装、已经缓存、或者 marketplace 中本地可见且可安全启用的 Codex 插件，尽可能完整显示在 Codex 插件列表里。
请按下面步骤执行，不要跳步：
1. 先判断我的系统是 Windows、macOS 还是 Linux，并找到 Codex 配置目录：
- Windows 通常是 %USERPROFILE%\.codex
- macOS/Linux 通常是 ~/.codex
2. 检查 Codex CLI 是否可用：
- 查看 `codex --version`
- 查看 `codex plugin --help`
- 查看 `codex plugin marketplace --help`
- 如果 PATH 里的 `codex` 不可用，也请检查常见本地安装路径并改用真实存在的可执行文件
- 如果当前 CLI 不支持某些命令，或者命令失败，不要停止，改用文件检查方式继续
3. 备份配置文件：
- 找到 `config.toml`
- 在同目录创建一个带时间戳的备份，例如 `config.toml.bak-YYYYMMDD-HHMMSS`
- 不要删除任何原配置
4. 读取 `config.toml`，重点检查：
- `[marketplaces.*]`
- `[plugins."插件名@marketplace名"]`
- `enabled = true / false`
- 是否有重复、旧路径、明显损坏的 marketplace 或 plugin 配置
- 不要输出我的密钥、token、bearer token、账号凭据
5. 扫描本地插件缓存目录：
- `.codex/plugins/cache`
- 递归查找 `.codex-plugin/plugin.json`
- 也兼容 `.claude-plugin/plugin.json`
- 忽略明显的临时安装目录，例如 `plugin-install-*`，除非没有正式版本
- 对每个插件读取 `name`、`version`、`interface.displayName`、是否有 `skills/apps` 等信息
6. 对比“缓存中存在的插件”和“config.toml 中已启用的插件”：
- 如果某个插件在缓存中存在，但 `config.toml` 没有对应 `[plugins."name@marketplace"]`，请加入：
[plugins."name@marketplace"]
enabled = true
- marketplace 名应从 cache 目录结构推断，例如：
`.codex/plugins/cache/openai-bundled/browser/...` => `browser@openai-bundled`
- 如果同一插件有多个版本，只启用最新或正式目录中的版本
- 不要把正式版本替换成更旧的 `plugin-install-*` 临时版本
7. 如果某个已缓存插件所属的 marketplace 在 `config.toml` 中缺失：
- 优先尝试官方 CLI 的 marketplace 命令修复
- 如果 CLI 不支持或失败，再从本地 Codex 临时 marketplace 元数据中推断并做最小配置修复
- 只补齐必要字段，不要做大改
8. 同时检查“本地可见但未必已安装”的 marketplace 元数据：
- `.codex/.tmp/marketplaces/*`
- `.codex/.tmp/plugins`
- 把这些内容识别为“本地可见的可用 marketplace / 插件线索”
- 但不要强行启用那些仅存在于临时仓库、保留 marketplace、或被官方 CLI 明确拒绝的插件
- 对这类项目，请归类为“本地可见但可能受 Codex UI / 账号 / 灰度 / 管理员策略限制”
9. 如果 Codex CLI 支持 marketplace refresh / upgrade：
- 优先使用官方 CLI 刷新 marketplace 和插件状态
- 如果刷新失败，不要停止，请记录失败原因，并继续通过 `config.toml` 做最小修复
10. 修改完成后，验证：
- 输出已发现的缓存插件列表
- 输出已启用的插件列表
- 输出这次新增启用的插件
- 输出这次新增或修复的 marketplace
- 检查 `config.toml` TOML 语法是否仍然有效
- 不要输出任何敏感信息
11. 最后告诉我：
- 哪些插件已经修复
- 哪些插件本地没有安装，无法通过配置修复
- 哪些插件虽然本地 marketplace 可见，但仍可能受套餐、管理员、工作区、灰度开放、Codex UI 或服务端 gating 影响，不能保证显示
- 提醒我完全退出并重启 Codex，然后新建一个线程测试插件是否出现
额外要求：
- 以“最小改动”为原则，不要无故删除原配置
- 如果发现失效的本地 `CODEX_CLI_PATH` 或类似旧路径，可以修正为当前真实存在的稳定路径
- 如果需要编辑文件，请尽量保持原有格式
- 不要输出密钥、token、cookie、认证头、账号信息为什么要让它先备份
Codex 的插件配置通常会落在 .codex/config.toml 里。这个文件可能不只保存插件状态，还可能保存模型、provider、网络、workspace 或其他本地设置。
所以修插件之前，第一步必须是备份。
如果修完之后插件还是不显示，至少还能把 config.toml.bak-时间戳 复制回去，不至于把原来的环境越修越乱。
为什么 CLI 失败也不能停
有些机器上 codex 命令不一定能正常从 PATH 启动。比如 Windows 上可能会指向 WindowsApps 里的入口，实际执行时遇到权限问题；也可能是当前 CLI 版本还没有完整的 plugin marketplace 子命令。
这不代表无法继续排查。
插件缓存、marketplace 临时元数据、config.toml 本身都在本地。CLI 走不通时，至少还可以通过文件系统把“本地已经存在什么”“配置里启用了什么”对起来。
这也是 Prompt 里反复强调“命令失败不要停止”的原因。
哪些情况它修不了
这个方法只能修本地配置层面的问题。下面这些情况，它最多只能识别和提示，不能保证解决：
- 插件没有真正安装到本地
- marketplace 本地只是临时可见，但没有正式启用
- 插件受账号、套餐、管理员策略、工作区策略影响
- Codex UI 或服务端还没有对当前账号开放
- 插件被官方下架、重命名，或者当前版本不兼容
所以修完以后，最后一步一定是完全退出 Codex，再重新打开，新建一个线程测试插件是否出现。
不要只刷新当前线程。插件列表有时需要完整重启后才会重新读取。
如果你之前遇到的是 Computer Use 消失
如果你的问题是 Windows 版 Codex Desktop 里 Browser、Chrome、Computer Use 这几个插件突然不见，可以先用这篇里的 Prompt 做一次配置级自查。
如果仍然不行，再结合我之前写的排查思路看：
一个偏“配置修复”，一个偏“插件消失后的恢复排查”。两个方向合起来，基本能覆盖大多数本地显示不全的问题。
最后提醒
这类问题不要急着删目录。
先备份，再扫描，再对比，再最小修复。能通过配置补齐的，就让它补齐；补不齐的，就把原因分清楚。
有时候插件不显示，不是你本地坏了，而是它本来就还没被当前账号、当前 UI 或当前 marketplace 状态允许显示。把这层边界搞清楚，比反复重装更省时间。