老哥们Codex 控不住浏览器这事我最近也撞上了。不是一次两次是折腾了大半天的程度。Codex 本身跑得好好的对话、写代码、改文件都没问题但只要让它去操作浏览器它就卡住、报错、或者干脆说“我做不到”。如果你也正卡在这个地方这篇复盘就是给你的排查思路不求一次解决但求别再瞎折腾重装。先说清楚我的使用环境Windows 11 Codex CLI VSCode 插件双开浏览器是 Chrome 最新稳定版通过浏览器扩展暴露 MCP 连接给 Codex。出问题的场景分两种一种是 Codex 直接调浏览器扩展的操作工具另一种是让 Codex 写 Playwright 脚本去控制浏览器。两种我都踩过坑排查路径也不太一样下面拆开讲。1. 先把控制链路搞清楚Codex 说“控制浏览器”到底走的是哪条路排查之前最忌讳的就是上来就卸了重装。你得先明白 Codex 和浏览器之间到底是怎么对话的链路里的每一环都是什么角色不然你根本不知道报错该甩锅给谁。1.1 Codex 控浏览器的两种主流姿势第一种是走MCP 协议Model Context Protocol。Codex 不是直接去点 Chrome 的按钮而是通过一个浏览器扩展把浏览器的状态、DOM、可点击元素这些信息通过 MCP 端口暴露出来。Codex 在这个链条里扮演的是“大脑”它决定下一步做什么扩展是“手”真正去操作页面。这个方案的优点是 Codex 不需要提前知道页面结构它能看到什么就操作什么非常适合“帮我填个表单”、“把这个按钮点一下”这种开放式任务。第二种是走Playwright / Puppeteer 这类自动化库。Codex 负责写代码Node 脚本负责执行。Codex 通过代码控制浏览器实例的启动、跳转、点击、断言。这个方案更可控适合你有明确的测试路径、或者要对批量页面做重复操作的时候。这两种方式我都试过日常高频使用的是第一种因为它更接近“Codex 控制浏览器”这个直觉不用维护一堆脚本。但如果你的目标是稳定的自动化回归我更推荐第二种——脚本可以脱离 Codex 单独跑出了问题至少知道是代码的问题还是模型的问题。1.2 出问题的大概率是这三节“咽喉”不管走哪条路链路里总有几节最容易出问题的地方我用看病来类比Codex 本体相当于人的大脑。大脑如果不工作说什么都白搭。这一节出问题通常表现为 Codex 对话本身都报错、或者回调异常。本地通信层相当于神经和血管。Codex 要和浏览器扩展或者 Playwright 脚本通信中间要经过本地端口、进程、配置文件。报文能不能送达到全看这一节通不通。很多让人摸不着头脑的报错比如 local proxy failed基本都是这一节的问题。浏览器实例相当于手脚。Chrome 版本太老、扩展权限没开、浏览器进程被安全策略锁死都会导致 Codex 明明发出指令了浏览器却没有任何反应。我的经验是80% 的“控不了浏览器”问题出在第二节而不是第三节。为什么因为报错信息往往指向本地服务的问题但字面意思又看着像网络问题让人误判方向。2. 从报错文本反推病灶三个高频 error 逐一拆解Codex 报错跟大多数工具一样报错信息里藏着最直接的线索。别看到一长串英文就头皮发麻其实拆开来看就几类。我最近实际踩过的、以及社区里高频出现的三个报错逐个给你拆。2.1 local proxy failed端口、进程还是路径问题这个报错我第一次见的时候第一反应是“网络问题”。原文大概长这样cc switch local proxy failed while handling codex endpoint /responses。注意这里说的是local proxy这个 proxy 并不是什么特殊代理而是 Codex 工具内部的本地通信进程负责把 Codex 的请求转发到本地运行的浏览器扩展服务上。它跟你的网络环境、网络出口没有任何关系纯粹是本地进程间通信的问题。我遇到这个报错时排查顺序是这样的先看本地端口是不是被占了。Codex 用的本地通信端口一般可以在配置文件里看到如果你本机有别的服务占用了同一个端口Codex 的 proxy 就起不来。然后看进程是否还活着。Codex CLI 和 VSCode 插件双开的时候有时候会拉起两个 proxy 进程互相抢资源导致其中一个失败。最后看版本是否匹配。Codex 的 CLI 版本和 VSCode 插件版本不一致旧版插件调新版 CLI也容易在这里翻车。这个报错还经常伴随一个现象Codex 对话能发起但一到要调用工具的时候就立刻中断。判断方法很简单——在终端里单独跑codex命令最小化环境再试一次如果最小化环境里没问题那就是双开环境打架。2.2 auth token is unavailable登录态去哪了这个报错比较直白codex auth token is unavailable。意思是 Codex 在调用远端接口时拿不到你的登录凭证。它不长出现在第一次安装的时候——因为第一次安装你大概率会走完整的登录流程反而是在你长时间没动、或者切换了账号之后冒出来。我踩过的场景是这样的Codex CLI 的登录态存了一份VSCode 插件又存了一份两个地方不同步插件调起 Codex 的时候拿的是自己那一份结果发现 token 过期了或者压根不存在于是报这个错。排查办法第一步在终端跑codex login重新走一遍登录流程看看能不能恢复。第二步如果重登也没用就去看用户目录下的 Codex 配置文件夹确认auth.json或者类似的文件里确实存了 token且修改时间是刚刚。第三步如果你设置过环境变量指向自定义的配置路径检查这个路径是不是被插件和 CLI 共用。最典型的坑是CLI 用默认路径插件用自定义路径两边各存各的当然有一个拿不到。说实话这个报错本身不难解决但很多人在第一步重登之后觉得“我明明登录了为什么不生效”其实就是没意识到存在两份登录态的问题。我后面会专门讲 VSCode 插件和 CLI 双开的坑。2.3 model not supported配置里藏了个“过期型号”最后一个高频报错the gpt-5.6-sol model is not supported when using codex with a...。这类报错我看到过很多次后缀都不一样但本质都是同一个——你在 Codex 配置里指定的模型和当前 Codex 版本能支持的模型列表对不上。为什么会这样因为 Codex 是个迭代很快的工具模型支持列表会变新模型加进来老模型下线或者改名。你配置文件里如果写死了一个模型名过了几周 Codex 升级了这个名字可能就不认识了。这里我特别提醒一点不要在配置文件里手写模型名除非你明确知道自己要干什么。很多“配置教程”会让你在本地配置里填model字段但 Codex 这类工具更推荐用model_provider和model的组合并且以官方文档为准。如果你照着某个历史教程填了一个模型名最好在升级之后重新核对一遍官方支持列表。判断这个问题的方法也很简单报错信息里直接把这个模型名打出来了你把这个名字丢到 Codex 的官方模型列表里搜一下搜不到就说明配错了。改回默认配置或者删掉自己加的 model 字段让它走默认逻辑问题通常就解决了。3. 排查思路五步法从外层到内核别一上来就重装技术人的一个通病是出了问题就喜欢“全部卸载重装一条龙”其实这是最费时间的。我后来总结了一套五步排查法按顺序走一遍大部分问题都能定位到具体位置。这套方法的思路是从“最外层、最不影响环境”的检查开始逐步深入到核心配置。3.1 第一步先确认 Codex 本体活着这一步看起来废话但真有人跳过。所谓“本体活着”指的是在终端里直接输入codex能正常进入对话界面。随便问它一个问题它能正常回答。让它做个不涉及浏览器的任务比如“写一个 Python 脚本计算斐波那契数列”能正常生成并执行。这一步的目的是确认大脑没问题排除“Codex 服务本身挂了”这种大前提故障。如果这一步都过不去那问题根本不在于“控浏览器”而是 Codex 本身的安装、登录、网络连接。这时候再派对浏览器模块就是南辕北辙。我做这一步的时候习惯顺带看一眼 Codex 的日志文件确认没有持续的报错输出。很多时候日志里早就有线索了只是你懒得看。花两分钟扫一眼比你在网上翻半天帖子有用。3.2 第二步查本地服务和端口占用确认 Codex 本体没问题后下一步就是查本地通信层。你可以打开命令行检查 Codex 的本地服务是否在监听预期端口。我用的命令是 Windows 下的netstat -ano | findstr 端口号macOS / Linux 下是lsof -i :端口号。重点检查两件事端口是否有进程在监听。如果没有任何监听说明本地服务根本没起来或者起来之后崩溃了。监听进程是不是 Codex 自己的。如果被别的进程占了那就是端口冲突需要在配置里改端口或者关掉占用进程。还有一个很容易被忽略的点防火墙或安全软件拦截。Windows 上有些安全策略会拦截本地端口的通信尤其是从命令行进程发起的。如果你发现端口是通的但 Codex 调用工具的时候依然报错可以去看看安全软件的拦截日志。这种情况不多见但我真的遇到过最后是给 Codex 进程加了白名单才通过。3.3 第三步查浏览器扩展与 MCP 连接如果本地服务没问题下一步查的是 Codex 和浏览器扩展之间的 MCP 连接。以 Chrome 扩展为例你去看扩展的设置页面里面通常会有一栏“MCP 连接状态”显示连接是否建立。我遇到过的情况有两种第一种是扩展页面显示连接失败。通常是扩展和 Codex 本地服务之间握手失败原因可能是扩展版本和 Codex 版本不匹配。第二种是扩展显示已连接但 Codex 那边调用工具时依然报错。这种情况多半是 MCP 的配置路径不对Codex 连上了扩展但是连接的是扩展的“控制接口”而不是“操作接口”。听起来有点绕打个比方你打通了电话但打错了分机号。MCP 配置我还想多说两句因为这块其实是“Codex 控不了浏览器”这类问题里最深的坑。Codex 支持通过配置文件声明 MCP 服务比如{ mcpServers: { chrome-devtools: { command: npx, args: [-y, chrome-devtools-mcp], env: {} } } }这类配置如果写错Codex 往往不会直接报配置文件错而是报“connect timed out”或者“server not found”。所以这一步正确的检查姿势是先把 Codex 里配置的 MCP 服务列表打印出来看看它认为自己在连谁再对照扩展自己显示的状态。两边信息对上了才能确认是真的通了。3.4 第四步查浏览器版本、驱动与权限链路前面都通了还是控不了就得盯浏览器本身了。这里有几个检查点浏览器版本Chrome 的稳定版、Beta 版、Dev 版内核差异很大。Codex 的浏览器控制能力通常是基于某种协议实现的对浏览器版本有要求。版本太老可能协议不支持太新可能协议出现兼容 bug。浏览器驱动如果你用的是 Playwright 那套方案驱动和浏览器版本必须严格匹配。Playwright 有个命令会自动下载匹配的浏览器但如果你本地已经装了 Chrome它有时候会去用系统 Chrome这时候版本不匹配就出现了。解决办法是强制让它用自己下载的浏览器或者手动指定执行路径。扩展和权限Chrome 扩展如果被禁用、或者权限被安全策略锁死Codex 连上了也操作不了。头一次排查这个问题的时候我是真没往这块想——因为你从表面看扩展是启用的但实际上它被同步策略锁住了。Chrome 管理页面里能看是否被组织策略管控如果有“此扩展程序由管理员强制执行”之类的提示那就是权限被锁了。这个坑还延伸出一个话题很多浏览器自动化工具都需要“远程调试端口”如果你之前手改过浏览器启动参数把调试端口关掉了Codex 也会立刻失灵。检查方式很简单手动用一个带远程调试参数的配置启动浏览器看它是否能正常监听端口。3.5 第五步最小化复现把变量砍到最少走到这一步还没定位问题那就必须上“最小化复现”了。所谓最小化复现就是砍掉所有无关变量只保留最核心的链路去试。我的做法是关掉 VSCode 插件只用 CLI。停掉所有无关的本地服务释放端口。关掉浏览器里其他扩展只保留 Codex 需要的那个。用一个全新配置目录重新初始化 Codex 配置只带最少的设置。让 Codex 做一个最简单的浏览器操作比如“打开 example.com”。如果最小化之后成功了说明问题出在你砍掉的变量里如果失败了说明核心链路本身还有问题就该回头重新过一遍前面四步。这招虽然笨但极其有效。我自己有两次找不到原因的诡异问题最后都是靠最小化复现试出来的。4. VSCode 插件和 CLI 双开的场景最容易翻车如果你跟我一样既装了 Codex CLI又装了 VSCode 插件那“双开”这个场景本身就是个小型事故多发区。排查这类问题的时候你要额外留几个心眼。4.1 双端配置不一致的典型表现CLI 和 VSCode 插件虽然是同一个 Codex但它们各自会维护一套配置文件、登录态和本地进程。两边不一致的时候表现迷惑性很强表现一CLI 里能正常控制浏览器但 VSCode 插件里不能。这是最典型的双端不一致。表现二CLI 和插件都报同样的错但错的方式不同。比如 CLI 报 proxy failed插件报 auth token unavailable。表现三重启之后好了一段时间然后又坏。这可能是因为你手动改过 CLI 的配置但插件每次启动会重新读自己的那份覆盖回旧值。排查这类问题我的习惯是“先统一再分离”。统一的意思是把 CLI 和插件的版本对齐——要么全升到最新要么都降到某个稳定版本。分离的意思是如果你要定位某一边的问题就把另一边彻底关掉只留一个在跑。千万不要两个同时开着排查你根本分不清报错是谁产生的。4.2 MCP 配置到底该怎么写才对双开环境下MCP 配置是最容易出分歧的地方。CLI 的配置文件路径和 VSCode 插件的配置路径往往不一样一个改了另一个没改就出现了“明明配置没问题怎么就是连不上”的尴尬。我后来试出一个比较稳的写法不要在 VSCode 插件界面里手动填 MCP 服务而是在 CLI 的配置文件里统一声明然后让插件读取 CLI 的配置。这样保证了一处配置双端生效。具体做法是查看 Codex 官方文档看它支持的配置继承关系是什么。以我当前手头的版本来说插件会读取全局用户目录下的 Codex 配置你在那里改动两端都会同步不用在插件设置里重复配。另一个容易忽略的点是环境变量。Codex 会从环境变量里读取很多设置如果你在终端里生效的环境变量没有同步给 VSCode 的 GUI 进程那你从 VSCode 里启动 Codex 的时候它读到的环境是残缺的。最典型的例子就是 PATH 不一致导致 Codex 在插件里找不到某个依赖命令而 CLI 里却能正常跑。5. 高频问题速查表 我踩出来的几条经验最后这部分直接打包给你我把自己遇过的问题、社区里的高频问题以及我的排查结论整理成一个速查表再分享几条拿真金白银主要是头发换来的经验。5.1 常见问题速查表现象可能原因优先排查动作Codex 对话正常但调用浏览器工具即时报错本地 proxy 进程崩溃或端口被占检查端口监听杀掉残留进程确认 CLI 与插件版本一致报 local proxy failed本地转发服务起不来版本不匹配单独跑 CLI 最小化复现检查防火墙白名单报 auth token unavailableCLI 和插件登录态不同步重新执行登录流程检查配置文件夹的 token 文件报 model not supported配置里指定了不存在的模型名打开配置删掉手写的 model 字段或改回默认扩展显示已连接但 Codex 调不到工具MCP 配置路径不对或环境变量残缺检查 MCP server 列表是否指向正确的本地服务浏览器没任何反应Codex 也不报错浏览器扩展被策略锁定或调试端口被关闭检查扩展管理页面手动启动浏览器测试调试端口重启后好了又坏双开环境下配置被覆盖统一配置源只改一处让另一端继承5.2 几条用真金白银换来的经验第一日志永远比报错信息有用。Codex 的报错信息通常已经把方向指出来了但具体的坑永远在日志里。排查的时候先去找 Codex 的日志文件看看报错前后的完整上下文。很多时候你会发现报错信息本身是一个误导真正的原因在日志文件前面的几十行里。第二不要同时开着多个“自动浏览器”相关工具。我有一回排查了快两个小时没头绪最后发现是电脑后台还跑着一个旧的代码助手进程它也在尝试控制浏览器跟 Codex 抢同一个调试端口。两个工具之间没有锁机制互相踩谁都用不了。从那以后我只要排查这类问题先看一眼后台进程列表把所有可能占用浏览器端口的进程全部关掉再测。第三版本这东西能不打乱就不打乱。Codex 这种迭代快的工具版本升级大概率是好事但你的配置文件、缓存、浏览器扩展可能跟不上。社区里常见的一句话是“锁版本等于锁平安”这不是要你不用新特性而是提醒你升级之后要主动回头验证一遍原有的链路等也等不来它不会自己好。第四最小化复现是最快的方法没有之一。遇到玄学问题别在网上翻帖子翻到怀疑人生老老实实砍变量、搭一个最小环境五分钟就能出结论。很多时候你找了一堆资料不如自己做一次实验更接近真相。根据我个人经验Codex 控不了浏览器九成不是“万恶的兼容性”这种玄学而是哪一节链路悄悄断掉了。你只要按着链路顺序排查先看 Codex 本体再看本地服务再看 MCP 连接和浏览器权限最后用最小化复现锁定问题基本都能解决。如果你恰好也是双开 CLI 和插件的环境先把版本统一了再回头看有没有配置文件双份的问题我赌你省下两个小时。最后再分享一个小技巧排查这种问题的时候养成每次都记笔记的习惯。把报错原文、当时的 Codex 版本、浏览器版本、操作步骤都记下来。你不用记给别人看就记给自己。下次再遇到类似问题直接搜自己的笔记比去任何论坛都快。我自己就是靠着这份笔记从第一次排查花一整天到后来十分钟定位差别就是这么来的。