如果你最近在折腾 Codex 和 MCP大概率和我遇到的情况差不多教程翻了不少照着贴了一堆配置结果 Codex 要么不认这些 server要么直接报错。上周我帮一个朋友排查“配好了 filesystem server 但模型始终说没有这个工具”的问题折腾半天最后发现他用的是三个月前装的 Codex 旧版本压根没带完整的 MCP 支持。我写这篇不是想做概念复读就按实际使用顺序讲清楚三件事配置写在哪儿、Server 怎么接进去、出了问题按什么链路查。文末会专门拆一个最近很热的报错——cc switch local proxy failed while handling codex endpoint /responses这类错看着吓人其实定位起来并不复杂。1. MCP 在 Codex 里不是插件是一套“工具外挂协议”1.1 先把 Host / Server / Client 三个角色分清很多人一上来就搜“MCP 是什么”然后看到一堆术语直接劝退。其实用插座和电器来理解就通了MCP 是一个开放协议规定了“想要给智能体外接工具的进程”和“智能体本体”之间怎么对话、怎么传递请求、怎么返回结果。在 Codex 的语境里Codex 本体就是 MCP Host它负责发起会话、调度模型、决定什么时候需要外部工具。MCP Server 则是独立运行的进程它可以是本地的 Python 脚本、Node.js 包也可以是远程的 HTTP 服务。Codex 内部会有一个 MCP Client 组件负责按照协议和各个 Server 建立连接、收发消息。这三个角色必须分清因为后面所有配置和报错定位都建立在“你到底在配哪个角色”之上。比如你配的是mcp_servers改变的是 Codex 能调用哪些外部能力而你改model_provider改变的是 Codex 用哪个模型来思考。前者是给智能体装手臂和眼睛后者是给智能体换大脑完全是两件事。1.2 调用链是什么样从一句指令到工具返回结果理解调用链比你记住一百条配置项都重要。实际发生过的一次完整调用是这样的你给 Codex 发一句“帮我把当前目录下所有大于 10MB 的文件列出来”。Codex 内部先把这句话交给模型推理模型判断“我需要遍历目录、看文件大小”于是向 Codex 发出一个调用某 MCP 工具的信号。Codex 的 MCP Client 把这个请求翻译成协议格式通过 stdio 传给对应的 MCP Server 进程。Server 执行完文件扫描把结果作为文本内容块返回。Codex 把结果拼回上下文模型基于这个结果生成给你的最终回答。这条链路里最关键的一点是MCP Server 只负责执行和返回数据不负责“思考”。最终决定“要不要用这个工具、拿到结果后怎么理解”的是模型本身。所以我经常跟人说别指望挂上一个 MCP Server 模型就会自动变聪明工具只是提供了数据通道和操作通道推理质量还得看模型。传输方式上绝大多数本地 MCP Server 用的是 stdio也就是 Codex 把 Server 当子进程拉起来通过标准输入输出通信。另一些远程 MCP Server 通过 HTTP 或 SSE 暴露端点Codex 以客户端身份连接。两种方式在配置文件里的写法差别很大后面会分别给示例。1.3 Codex 对 MCP 支持的范围与边界先说结论Codex 目前对 MCP 的支持是“可用但还在快速迭代”。不同版本之间的字段名、行为可能有差异我下面写的内容以我当前在用的版本为准如果你发现某些字段不识别先考虑是不是版本太旧。几个边界问题需要心里有数。比如一个 MCP Server 启动失败不会让 Codex 整体崩溃只是那个工具在本次会话里不可用模型会告诉你“没有这个工具”或者“调用失败”。再比如MCP Server 的进程权限和 Codex 基本一致等于你本机用户的权限所以给 Server 配 token、配目录、配数据库连接串的时候要想清楚它一旦被乱调用会造成什么后果。还有一个常见的认知误区Codex 的 IDE 插件比如 VS Code 扩展和命令行工具读的其实是同一份配置文件。很多人以为插件里有一套独立的 MCP 设置面板找了半天没找到其实配置入口就是那份config.toml。2. 配置文件的位置与权限全局、项目级和 IDE 是同一份2.1 config.toml 才是真正的入口Codex 的 MCP 配置不是存在 UI 界面里而是写在一个叫config.toml的 TOML 格式文件里。全局配置文件在 Linux/macOS 下位于~/.codex/config.tomlWindows 下位于%USERPROFILE%\.codex\config.toml。注意是 TOML 格式不是 JSON网上很多示例直接贴 JSON 进去Codex 解析必挂。一个最小可用的全局 MCP 配置长这样model gpt-5-codex model_provider openai [mcp_servers.filesystem] command npx args [-y, modelcontextprotocol/server-filesystem, /Users/yourname/projects]这里[mcp_servers.filesystem]表示注册一个名为filesystem的 MCP Servercommand是启动命令args是传给命令的参数。Codex 在需要时就会去执行npx -y modelcontextprotocol/server-filesystem /Users/yourname/projects这个命令把进程拉起来通信。如果你要给某个 Server 传环境变量用env字段里面用 TOML 的键值对形式写[mcp_servers.github] command npx args [-y, modelcontextprotocol/server-github] env { GITHUB_PERSONAL_ACCESS_TOKEN ghp_xxx }修改完配置文件之后一定要重启 Codex 会话或者重开 IDE 窗口配置才会生效。这个“重启”动作很多人漏掉后面会专门说。2.2 全局 MCP 与项目级 MCP 的取舍除全局配置外Codex 还支持项目级配置。你可以在某个项目的根目录下创建.codex/config.toml把只针对这个项目生效的 MCP Server 放进去字段名用的是project_mcp_servers[project_mcp_servers.buildtools] command python args [/path/to/project/tools/build_server.py]全局配置适合放通用工具比如 filesystem、github、数据库客户端因为你不管打开哪个项目都可能用到。项目级配置适合放绑定特定项目的脚本比如这个项目独有的构建检查工具、内部接口封装项目里每个人都用得上但别的项目完全不需要。两个层级同时配置同一个名字的 Server 时项目级会覆盖全局这个行为可以用来做局部定制。比如全局挂了一个默认的数据库 MCP某个项目需要连另一套库就在项目级配一个同名 Server指向另一个地址。从权限角度考虑项目级配置一般不应该放入敏感 token因为它是跟着代码仓库走的一旦提交到 Git 就会泄密。即使放在.codex/config.toml里也要确保.gitignore把.codex/目录或者至少其中的配置备份排除掉。2.3 改了配置不生效先别怪 Codex我见过太多人改了配置文件之后对着 Codex 喊“为什么没有”最离谱的一次是发现自己把配置写进了auth.json——那是存登录凭证的文件根本不是配置入口。排查“配置不生效”时按下面这个顺序来基本能覆盖九成的情况第一确认 TOML 语法没问题。TOML 对缩进和括号的要求比 JSON 宽松但它有自己的坑比如字符串里出现特殊字符要加引号数组用中括号。一个快速验证方法是把配置片段丢到任意 TOML 校验工具里跑一遍。第二确认你改完配置后重新开了会话。Codex 只会启动时读取配置不会热加载。如果你是在命令行里敲codex那要退出再进如果你用的是 IDE 插件最好把窗口整个关掉重开。第三确认 npx 真的把包拉下来了。npx -y modelcontextprotocol/server-filesystem首次运行需要联网下载如果网络状态不好或者 npm registry 很慢会卡很久看起来像配置失败实际上是在默默下载。可以先在终端里手动跑一遍这个命令确认能正常进入 server 的等待状态再回来配 Codex。第四确认没有其他工具在“帮倒忙”。现在有很多第三方配置切换工具会重写config.toml它们认识老字段但未必认识最新的mcp_servers段落。你配好 MCP 后切了一下模型供应商配置MCP 段落就没影了。这个问题下文讲 cc-switch 时会展开。3. 把第一个 MCP Server 跑起来三种典型接入方式3.1 filesystem 官方参考实现最适合试水如果你想验证 Codex 的 MCP 链路通不通别第一个就上复杂的自定义服务先用官方维护的 filesystem server 试水它能读文件、列目录、看文件信息足够验证配置和调用链。配置就三段写在全局config.toml[mcp_servers.filesystem] command npx args [-y, modelcontextprotocol/server-filesystem, /Users/yourname/projects]这里要注意两个细节。第一个目录参数要写绝对路径MCP Server 启动后只会向你授权的目录提供服务授权范围就是 args 里列出的那几条路径想访问多个目录就多写几个。第二个Windows 下如果npx直接执行失败改成[mcp_servers.filesystem] command cmd args [/c, npx, -y, modelcontextprotocol/server-filesystem, C:\\projects]配好之后重启 Codex新开会话直接问一句“你能用哪些工具”模型会把它当前可见的工具列表告诉你里面应该包括 filesystem 暴露的read_file、list_directory、get_file_info这些条目。更直接的验证方式是让它“帮我列出 /Users/yourname/projects 下的所有文件”如果它能正确返回目录结构说明整条链路已经通了。3.2 自定义 Python 脚本把内部接口变成 MCP 工具filesystem 只是官方示例真正让 MCP 值钱的是把你自己内部的接口、脚本、数据源封装成工具。比如你有个内部服务只在公司内网暴露没有现成的 API 网关那就可以写一个小 MCP Server 把它包起来让 Codex 能直接查数据、发命令。用 Python 官方 SDK 写一个最小 server 非常简单。先装依赖pip install mcp然后写一个my_tools_server.pyfrom mcp.server.fastmcp import FastMCP mcp FastMCP(MyTools) mcp.tool() def get_stock_price(code: str) - str: 查询指定股票代码的当前价格code 例如 600519 # 这里替换成你实际的内部接口调用逻辑 return f{code}: 100.00 mcp.tool() def health_check() - str: 检查本地服务是否存活 return alive if __name__ __main__: mcp.run()这里面每个被mcp.tool()装饰的函数都会对外暴露成一个可供 Codex 调用的工具。函数名、参数、docstring 会被作为工具的元信息发给模型所以 docstring 一定要写清楚这个工具是干嘛的参数含义是什么。因为模型是靠这些描述来决定“要不要用这个工具、传什么参数”的。然后在config.toml里注册它[mcp_servers.mytools] command python args [/path/to/my_tools_server.py] env { INTERNAL_API_URL http://127.0.0.1:8080, INTERNAL_API_KEY xxx }env里传的就是这个 Python 进程能读到的环境变量你的脚本里用os.environ.get(INTERNAL_API_URL)就能取到。这种方式比把密钥硬编码在代码里安全得多也比写在 args 里好因为 args 里的内容会出现在进程列表里容易被其他进程看到。热词里有人搜“codex 如何接入 python”大概率想的是让 Codex 执行 Python 代码。这里顺便说清楚Codex 本身就能在本地执行 shell 命令和 Python 脚本这是它作为本地智能体的基础能力不通过 MCP 实现。MCP 用于的是“把一段特定逻辑封装成可复用工具”两者场景不一样。比如你直接让 Codex“运行 app.py 并修复报错”它自己就能做到但你想让 Codex“调用公司内部的上线平台接口”那写个 MCP Server 包一层会更稳。3.3 远程 HTTP Server连一个可以直接访问的 MCP 服务除了本地进程Codex 也支持连接远程 MCP Server也就是通过 HTTP 协议暴露的 MCP 端点。配置写法不是command而是url加可选的headers[mcp_servers.remote_tools] url https://example.com/mcp headers { Authorization Bearer xxxx }这种模式适合几种场景MCP Server 跑在另一台机器或容器里通过内网地址访问使用了某个 SaaS 平台提供的 MCP 端点或者本地起了一个 HTTP 模式的 MCP ServerCodex 用 HTTP 而不是 stdio 去连它。远程模式有一个容易踩的坑新版 MCP 协议规范要求远程端点实现 Streamable HTTP 传输老一点的 SSE 端点 Codex 不一定支持。所以如果你连接一个第三方 MCP 服务失败先确认它的传输方式是不是新版标准别在 Codex 这边反复改配置。最简单的验证方法是用curl自己请求一下那个 URL看返回的响应头、协议协商结果是否正常。4. 顺着热搜词看真实场景DeepSeek、Burp 和 Figma 到底连什么4.1 接入 DeepSeek 是模型配置不是 MCP 配置“codex 接入 deepseek”最近是大热门但这个需求本质上和 MCP 没关系它是模型供应商的配置问题。可它为什么会和 MCP 混在一起因为都写在同一个config.toml里很多人改着改着就分不清哪段管什么了。接入 DeepSeek你改的是model_provider字段和新增的一个model_providers段落model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com env_key DEEPSEEK_API_KEY这里env_key表示 Codex 会从环境变量DEEPSEEK_API_KEY里读取你的 API Key。你在启动 Codex 的终端里先export DEEPSEEK_API_KEYsk-xxx或者写进 shell 配置文件就行了。请记住一个心智模型这组配置决定的是“Codex 的大脑是谁”而mcp_servers决定的是“Codex 的手和眼睛有哪些”。大脑换成 DeepSeek 之后MCP Server 完全不受影响该用还是能用。反过来也一样你挂了十个 MCP Server也不影响你要用哪个模型来调度它们。实践中很多人遇到的情况是把 DeepSeek 的 API Key 填到了某个 MCP Server 的env里或者把 MCP Server 的 token 填到了model_providers里两边串了之后症状非常奇怪——Codex 能启动但一调用就 401。真遇到这种先检查每份密钥是不是在自己该待的位置。4.2 Codex 联动 Burp安全测试场景怎么串起来“codex 联动 burp mcp”这个热搜词说明安全测试圈子里已经有人在实践这条路了。简单说Burp Suite 是一个本地运行的抓包与安全测试工具它本身有 REST API 和扩展接口MCP Server 可以封装这些接口让 Codex 能读取当前代理捕获的请求、提交新的测试请求、查询扫描进度。大致的配置方式是在本地把 Burp 跑起来开启它的 API 端口然后让写好的 MCP Server 通过 HTTP 和它通信Codex 这边用command模式拉起这个 MCP Server并在env里传入 Burp API 的地址和密钥[mcp_servers.burp] command python args [/path/to/burp_mcp_server.py] env { BURP_API_URL http://127.0.0.1:8081, BURP_API_KEY xxx }实际使用中Codex 可以做这些事从 MCP 工具里拿到 Burp 捕获的原始请求分析请求头、参数、Cookie 结构把模型给出的测试建议拼成新的 HTTP 请求再通过 MCP 工具交给 Burp 转发出去读取扫描结果帮你判断哪些是误报。它本质上是把“人的分析助手”变成了“有执行能力的分析助手”。这里必须提醒一句被抓包的流量里经常带着真实用户会话和敏感数据把这些数据直接抛给外部大模型等于把公司的内部数据往外送。如果你一定要做这个场景要么用本地部署的模型要么对流经的数据做脱敏处理。工具是好的但数据边界要自己守住。4.3 Figma 的 token 放到哪一层才算对搜“figma mcp token 在哪获取”的人很多是卡在 token 生成这一步。Figma 的 Personal Access Token 在 Figma 账户设置里的 Security 页面生成生成时要勾选files:read之类的权限范围。拿到的是figd_xxx开头的一长串。这个 token 应该放在哪个位置答案是 MCP Server 的env里因为它是给 Figma 那个 Server 用的不是给 Codex 的模型提供商用的[mcp_servers.figma] command npx args [-y, figma-mcp-server] env { FIGMA_API_KEY figd_xxx }npm 上叫 figma mcp server 的包不止一个有的维护活跃有的一年不更新。建议优先选带官方标识、GitHub stars 较高的项目然后先手动在终端单独跑一遍这个 server确认它能正常读 Figma API再配进 Codex。否则你会分不清是 token 问题、包问题还是 Codex 集成的问题。5. 从“cc switch local proxy failed”看一类报错的排查方法5.1 这个报错到底发生在哪一层最近搜 Codex 相关报错的人很多都撞到过cc switch local proxy failed while handling codex endpoint /responses这串英文。它的特征是看起来很深奥里面还带着codex endpoint /responses很容易让人以为是 Codex 本身坏了或者是 MCP 出了问题。先解释一下上下文。cc-switch 这类工具的作用是帮你管理多份 Codex 配置比如同时维护 OpenAI 官方、DeepSeek、其他兼容服务好几套模型供应商配置需要哪个就“切换”到哪个它会重写config.toml。有些配置里包含了一个本地网关服务Codex 通过这个网关转发模型请求报错文本里的“local proxy”指的就是这个本地 API 网关/中转服务不是 Codex 的一部分。所以这个报错的本质是Codex 把一个请求发到了本地某个服务的/responses端点那个服务在转发/处理请求时返回了失败。它发生在模型请求层和 MCP 工具调用是两条线。之所以很多人把它和 MCP 混在一起是因为 cc-switch 在重写配置的时候可能顺手把mcp_servers段落也覆盖掉了于是模型配置和 MCP 配置同时坏了表现成“一启动 Codex 就报这个错MCP 工具也没了”。5.2 逐步排查链路从配置到服务到请求遇到这类报错别慌按下面这个链路一步步来每一步都能帮你缩小问题范围。第一步复现报错并确认边界。新开一个 Codex 会话不调用任何 MCP 工具只问一个简单问题比如“11等于几”。如果这个普通对话本身就报local proxy failed那基本可以确定问题在模型请求链路MCP server 是无辜的。如果普通对话正常只有涉及 MCP 操作时才报错才需要考虑 MCP 配置的问题。第二步检查当前生效的配置。打开~/.codex/config.toml重点看model_providers段落里当前 provider 的base_url指向哪里。如果它指向http://127.0.0.1:xxxx或http://localhost:xxxx那这个本地网关服务就是报错的主角。第三步确认本地网关服务还活着。看对应的进程有没有在跑、监听端口是否正常。直接拿 curl 打一下curl -X POST http://127.0.0.1:8080/responses \ -H Content-Type: application/json \ -H Authorization: Bearer $KEY \ -d {model:deepseek-chat,input:hello}如果 curl 本身返回错误说明是网关服务挂了或者路径不对问题不在 Codex如果 curl 正常但 Codex 报错说明 Codex 传给这个服务的请求格式或鉴权头有问题继续往下查。第四步检查密钥是否有效。看model_providers里配置的env_key对应的环境变量是否设置、是否过期。很多“local proxy failed”其实是上游 API 鉴权失败网关把 401 或 403 原样返回给 CodexCodex 只能用一句笼统的“local proxy failed”告诉你。第五步检查 MCP 段落有没有被覆盖。config.toml里搜一下mcp_servers如果整个段落消失了那就是 cc-switch 这类工具重写配置时把 MCP 配置冲掉了。如果你有备份直接 diff 一下两个版本很快就能确认是谁改掉的。第六步修复并固化。把mcp_servers段落补回去把model_providers修正到正确指向。然后建议你把自己常用的 MCP 配置段单独备份成一个文件之后每次切换供应商配置后核对一下配置别依赖工具自动合并。5.3 容易被误判成 MCP 问题的其他症状在排障过程中有些症状看起来像 MCP 坏了实际是其他部分的问题这里列几个容易误判的。Codex 能启动但模型说“没有可用工具”同时你明明配置了 MCP Server。这种情况一般不是 MCP 的问题而是当前模型不支持工具调用或者wire_api配置不对。不同模型对 tools 的支持程度不一样换成不支持工具的模型Codex 自然就没有工具可用。MCP Server 进程启动了但一调用就返回空结果或报错。这个问题要去看 Server 自己的日志而不是盯着 Codex 的界面。你在配置的时候给 Server 起一个独立终端窗口手动跑一遍就能看到它到底在报什么错。很多 Python 脚本在本地直接跑没问题被 Codex 拉起来就报错多半是环境变量没传进去或者工作目录不对。响应非常慢每次调用工具都像卡死。一个常见原因是 npx 每次都在重新解析和下载包可以提前用npm install -g modelcontextprotocol/server-xxx全局装好然后把command改成直接调用全局包路径省去 npx 的动态下载步骤速度和稳定性都会改善。Windows 上的坑更多一些很多人报“codex windows 安装未完成”然后 MCP 也配不起来。安装问题先确认 PATH 是否正确、是否装了新版再回头看 MCP。Windows 下启动 MCP Server 时command里的解释器路径、cmd /c的用法都要格外注意路径里的反斜杠也要按 TOML 字符串规则转义。6. 用了 MCP 之后这几件事越早知道越好MCP 配置本身不难但真正用好需要建立几个习惯。第一代码仓库要管理好你的配置。我现在的做法是把~/.codex/config.toml的常用模板放进 dotfiles 仓库新机器克隆下来就能用。要注意的是里面不要有明文密钥用一个# 请设置环境变量 XXX的注释代替环境变量单独在 shell 配置里维护。这样既方便同步又不会泄密。第二MCP Server 不是越多越好。每挂一个 ServerCodex 在每次会话里都会多出一批工具描述这些描述会占用模型的上下文窗口。工具太多不仅增加 token 成本还会稀释模型对关键工具的注意力。我的体会是保持在三到五个以内真正高频使用、真正解决问题才值得挂上去。临时需要的功能用完就摘掉。第三指令要明确。别指望模型每件事都自己想起来去调用工具。你给 Codex 说“帮我看下这个 token 的余额”它可能不知道要调用哪个 MCP 工具。但你说“用 mytools 里的 get_token_balance 查一下 0x1234 的余额”它就知道该干什么了。工具调用是模型的一种选择而你的指令是影响这个选择的最大因素。第四Server 返回的内容质量决定工具效果。MCP Server 给你返回一段杂乱无章的巨大 JSON模型很难从中提取出有用信息如果你在 Server 端做好格式化、精简、只返回必要字段模型的分析质量会明显上升。工具返回内容本身就是给模型的“上下文”垃圾进垃圾出这个道理在 MCP 场景下同样成立。第五保持 Codex 本体更新。MCP 支持迭代非常快旧版本可能缺少新字段、不支持新的传输协议。你遇到一些莫名其妙的配置不识别、远程连接失败先升级到最新版再排查往往能省掉大量时间。最后分享一个我自己的排查习惯遇到任何 MCP 相关疑难杂症先在终端手动把那个 server 命令原样执行一遍。这个动作能帮你区分至少一半的问题——是 Codex 不会连还是 Server 起不来又或者是 upstream 接口本身有问题。把这个做熟了MCP 对你来说就不再是玄学而是有清晰边界的工程问题。