1. Codex App 用久了那些小痛点会自己冒出来Codex App 本身是个挺顺手的桌面编码工具但只要你把它当成日常主力用上一两周几个高频小问题就会开始硌手。最典型的是 API Key 登录模式下插件入口直接打不开提示要登录 ChatGPT 账号历史会话列表只有归档按钮想真正删掉一段没用的对话得手动去翻本地数据库切换 model provider 之后明明本地 rollout 文件还在/resume里却看不到旧会话了想把某段对话导出成 Markdown 存档原生也没给一个顺手的入口。这些都不是致命问题但每天都要碰几次累积起来就很影响节奏。Codex 这个项目就是冲着这些细节来的——它不是另一个 Codex也不是改官方安装包的补丁而是一个外部增强启动器通过自己的 launcher 拉起 Codex Desktop App再借 Chromium DevTools Protocol 注入增强脚本在不碰原始文件的前提下补上删除会话、导出 Markdown、插件解锁和 Provider 同步这四条能力线。这篇就按「一次配置即可复现全部增强功能」的目标来写把 config.toml 与 settings.json 的骨架、TaoToken 统一 Key/API 通道的接入方式、以及验证动作串成一条可跟做的路径。适合已经在用 Codex App、并且经常在 API Key 模式和多 provider 之间来回切的人。2. 先把 TaoToken 的 Key 和通道准备好Codex 解决的是桌面体验层的问题但模型请求最终还是要走一个稳定的 API 通道。我这边习惯用 TaoToken 做统一入口原因是它把 GPT / Codex 全系列模型的 Key 和 base_url 收敛成一套切换 provider 时不用到处改环境变量。你需要先拿到一个 API Key。打开控制台页面https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite在 API Keys 页面创建一个新 Key复制出来备用。接入文档在这里里面有 base_url 和请求格式说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 端点本身是https://taotoken.net/api注意这个地址后面不加任何 UTM 参数直接作为 base_url 写进配置就行。Key 的管理入口https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite拿到 Key 之后先别急着配 Codex用模型对话页面确认一下 Key 是活的https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite在里面选一个 Codex 系列模型发一句话能正常返回就说明 Key 和通道都没问题。这一步很重要因为后面 Codex 的 Provider 同步如果出问题你得先排除是 Key 本身失效还是同步逻辑没生效。3. Codex 的 config.toml 与 settings.json 骨架Codex 的配置分两层一层是 Codex 自己的config.toml负责 model_provider 和模型参数另一层是 Codex 的settings.json负责增强功能的开关。两者配合起来才能让 Provider 同步和插件解锁同时生效。先看config.toml。它默认在~/.codex/config.tomlWindows 是%USERPROFILE%\.codex\config.toml。下面是一个可以直接抄的骨架把 provider 指向 TaoToken# ~/.codex/config.toml model gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses [model_providers.taotoken.headers] X-Client codex-plus-plus这里几个点值得说明。model_provider的值taotoken是自定义标识Codex 的 Provider 同步会读这个字段来决定把哪些历史会话匹配到当前供应商。env_key指定从哪个环境变量读 Key所以你还得把 Key 写进环境变量# Windows PowerShell写入当前用户环境变量 [Environment]::SetEnvironmentVariable(TAOTOKEN_API_KEY, sk-你的Key, User)# macOS / Linux写进 shell 配置 echo export TAOTOKEN_API_KEYsk-你的Key ~/.zshrc source ~/.zshrc然后是 Codex 的settings.json默认在~/.codex-session-delete/settings.json。这个文件控制增强功能的开关骨架如下{ plugin_unlock: true, force_install_special_plugins: true, session_delete: true, markdown_export: true, conversation_timeline: true, provider_sync: true, watcher_enabled: false, backup_before_delete: true, backup_dir: ~/.codex-session-delete/backups }provider_sync设成 true 是这篇的重点它会在启动 Codex 前同步本地会话 metadata包括 rollout 文件、SQLite 线程记录、项目路径缓存以及当前 model_provider 对应的会话可见性信息。backup_before_delete建议保持 true删除会话前会自动备份到~/.codex-session-delete/backups。配置写完后用 Codex 的启动命令拉起 Codexpython -m codex_session_delete launch如果你在 Windows 上想让它自动接管原生启动可以装 watcherpython -m codex_session_delete watch-installwatcher 会每 3 秒探测一次本机 CDP 端口发现 Codex 在跑但 CDP 没起来就把它重拉成带注入的版本。日志在%USERPROFILE%\.codex-session-delete\watcher.log。4. 验证请求确认四条能力线都生效配置写完不算完得逐条验证。下面是我实测下来比较靠谱的验证顺序。第一步确认 Codex 菜单出现。从 Codex 快捷方式启动后顶部菜单栏应该多出一个 Codex 菜单。点开能看到后端状态和设置面板入口。如果没出现八成是你直接启动了原版 Codex而不是走 Codex 入口。第二步验证插件解锁。在 API Key 登录模式下打开插件页原本提示需要登录 ChatGPT 的入口现在应该能正常显示并启用。如果特殊插件还提示 App unavailable检查force_install_special_plugins是否为 true。第三步验证会话删除。在会话列表里悬停某条会话应该出现删除按钮点击后有确认弹窗删除后还支持撤销。删除前会备份到~/.codex-session-delete/backups可以进去确认备份文件在不在。第四步验证 Markdown 导出。选一段会话用 Codex 菜单里的导出功能它会按本地 rollout 导出带时间戳的 Markdown 文件。打开看看内容是否完整时间戳格式是否符合预期。第五步也是最能体现 Provider 同步价值的一步切换 provider 后看旧会话还在不在。先把config.toml里的model_provider改成另一个值重启 Codex然后打开/resume或项目列表确认旧会话仍然出现在原来的项目下。再切回taotoken旧会话应该依然可见。这一步过了说明 Provider 同步真的在工作。如果你想在验证阶段直接测模型返回可以用模型对话页面发一条请求确认 TaoToken 通道稳定https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite5. 本篇常见错排查配置过程中最容易踩的坑集中在几个地方我按出现频率排一下。双击 Codex 没反应。先看日志%USERPROFILE%\.codex-session-delete\launcher.log。常见原因有三个Codex App 没装或路径变了9229 端口被占用Python 环境不可用。端口占用可以用netstat -ano | findstr 9229查一下是谁占的。Codex 菜单没出现。确认你是从 Codex 快捷方式启动的不是直接开原版 Codex。再检查 Codex 进程有没有带 CDP 参数--remote-debugging-port9229。如果用了 watcher看 watcher.log 里有没有二次确认失败。切换供应商后旧会话不见了。打开 Codex 设置面板确认provider_sync是 true然后重启 Codex。它会在启动 Codex 前同步当前 model_provider。注意 Provider 同步只修复会话可见性相关的 metadata不会改写对话内容。如果 Codex 正在占用某个会话文件或 SQLite 忙碌Codex 会跳过并继续启动这种情况重启一次通常就好。技能推荐加载失败。如果提示git fetch failed unable to access https://github.com/openai/skills.git/通常是本机网络访问 GitHub 受限。Codex 启动时会优先继承现有的 HTTP_PROXY / HTTPS_PROXY / ALL_PROXY 环境变量如果没设置会自动探测常见本地端口。你也可以手动指定后再启动$env:HTTP_PROXYhttp://127.0.0.1:7897 $env:HTTPS_PROXYhttp://127.0.0.1:7897 python -m codex_session_delete launchWindows 卸载失败。先更新到当前版本再重装一次python -m codex_session_delete setup新版会写入更稳定的系统卸载项并用绝对 Python 路径执行卸载。Key 明明配了但请求 401。先确认环境变量在当前 shell 里真的生效了echo $env:TAOTOKEN_API_KEYPowerShell或echo $TAOTOKEN_API_KEYbash看一下。再确认config.toml里的env_key拼写和变量名完全一致。最后用模型对话页面单独测一次 Key排除是 Key 本身的问题。6. 长期编码场景下的接入建议如果你只是偶尔用 Codex App 写点小脚本上面这套配置跑通就够了。但如果你把 Codex 当日常主力经常在 API Key 模式、多个 provider、本地历史会话之间来回切那有两件事值得提前做。一是把 Provider 同步和 watcher 都打开。watcher 让原生入口启动的 Codex 也能被自动接管省得每次都要记得从 Codex 快捷方式进。二是把 TaoToken 的 Key 和 base_url 固定成一套配合 Codex 的 Provider 同步切换供应商时历史会话不会丢模型请求也走同一条稳定通道。长期编码和 Agent 场景可以看下 Coding Plan它把 Codex 系列模型的调用额度打包适合高频使用https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite如果你用的是 Claude Code 那套 Anthropic 风格的接入入口在这里https://taotoken.net/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeanthropicutm_campaignrewrite配置这件事一次写对后面就省心。Codex 的增强层加上 TaoToken 的统一通道基本能把 Codex App 日常使用里那些硌手的细节都抹平。先把config.toml和settings.json两个骨架抄进去跑一遍第 4 节的五步验证剩下的就是正常写代码了。
