Codex + MCP 配置实战指南：从环境搭建到工具接入

我最早接触 Codex 是通过命令行跑一个小任务：把仓库里的几段重复代码抽成公共函数。原本预期它和普通补全工具差不多，结果它在没有我手动改文件的情况下，自己完成了重构、跑了测试、还顺手改了文档格式。当时我就意识到，这东西的真正价值不在“生成代码”，而在“把一个端到端任务执行完”。而真正让它从“能做事”升级为“能接手完整工作流”的关键，是 MCP 协议。这篇文章我会从安装开始，把 Codex 和 MCP 的配置链路一条条拆开讲清楚，覆盖环境准备、协议机制、外部工具接入、报错排查和安全边界，适合刚接触 Codex、准备把它接入真实项目或团队工具链的开发者参考。

1. 为什么非要折腾 Codex + MCP：这套组合能解决什么实际问题

很多人第一次看到“MCP”三个字母，第一反应是“又一个新协议要学”。但如果你只用一句话理解它，就是：让 AI 模型能像操作电脑外设一样，去调用现实世界的工具和数据。

1.1 从自动补全到自主交付，差距就在“能用什么工具”

大模型本身再强，它也只是在一个封闭的上下文里做推理。你问它“帮我查一下数据库里最近一周的订单量”，如果它没有数据库连接能力，它就只能告诉你“你应该用 SQL 查”，然后给你一段 SELECT 语句。这对你来说，价值约等于零，因为你还得自己打开数据库客户端、执行、导出、分析。

但接上 MCP 之后，Codex 可以直接调用一个数据库 MCP 服务器，自己连接 MySQL、执行查询、读取返回结果，再根据结果生成分析结论。整个链路从“它给建议，你手动执行”变成了“它直接执行，你负责审核”。我在实际项目里的体感是，前者是效率工具，后者才叫生产力工具，差距不是一点点。

另一个典型场景是前端项目里接设计稿。以前设计师把 Figma 链接发给你，你要自己切图、量间距、导图标。现在配置好 Figma MCP，让 Codex 读取设计稿上的节点和样式信息，它生成的前端代码能精确对齐设计稿的布局参数。这个工作流一旦跑通，重复的“切图-写样式-对参数”环节基本可以交给它了。

1.2 MCP 不是又一个接口标准，而是 LLM 的“外设总线”

MCP 全称 Model Context Protocol，是一个开放的通信协议，定义了 AI 模型（Host）如何发现、连接、调用外部能力（Server）。你可以把它类比成计算机里的 USB 接口：以前每种设备都要单独做一条专用线缆，现在所有设备都遵循同一个接口标准，插上就能用。

在 Codex 的语境里，Codex 是 MCP Host，它负责读取你的指令、维护对话上下文、决定什么时候调用工具。而外部的文件系统、数据库、设计软件、接口文档、浏览器自动化工具这些，都通过这些 MCP Server 暴露给 Codex。每个 Server 可以是一个本地进程、一个远程服务，甚至是一个容器。

这套设计带来的直接好处是：工具和模型彻底解耦。你想给 Codex 加新能力，不需要改 Codex 本身，只需要在配置文件里加一个 MCP Server 的声明，填好运行命令和参数，重启后就能用。我后来接了五六个内部工具和外部服务，Codex 的主程序一次都没动过，全部是在配置层完成的。

1.3 谁适合现在就搞，谁可以再等等

先泼一盆冷水：如果你连命令行都不太熟，或者你的项目里根本没有需要反复执行的外部操作，那暂时可以不折腾 MCP。它解决的是“高频、重复、可脚本化”的外部操作问题，而不是“偶尔手动执行一次”的场景。

反过来，如果你满足下面任意一条，我建议你今今天就动手配：

• 日常开发里频繁要在多个工具之间切换，比如查数据库、看设计稿、调接口文档、操作浏览器。
• 你想让 Codex 独立完成一整条任务链，而不是一次只回答一个问题。
• 你希望团队里其他人也能用同一套 AI 工具链，而不需要每个人做重复配置。
• 你在做安全测试、运维巡检、数据分析这类需要反复调用专业工具的工作。

这套组合的核心价值，说到底就是把“会思考”的模型和“会执行”的工具接在一起。配置过程不复杂，但里面的细节坑很多，下面按顺序一步步来。

2. 装 Codex 之前，先把环境底子打对

安装 Codex 本身不难，难的是安装完之后各种工具链缺胳膊少腿。我见过太多人卡在“明明装好了，却跑不起来”的尴尬阶段，最后发现是 Node.js 版本太老或者 Git 没配好。所以这一节把环境检查放在前面，按顺序捋一遍。

2.1 版本要求：Node.js、Git、系统环境的红线

Codex CLI 是基于 Node.js 开发的，官方推荐的安装方式也是通过 npm 全局安装。所以 Node.js 是第一道门槛。

我建议直接装 Node.js 20 或以上版本。18 也能跑，但有些依赖包在 18 上会有兼容提示，为了避免后续排查问题时分不清是 Codex 的问题还是 Node 的问题，不如一步到位。装完后用两个命令确认：

node -v npm -v

看到类似v20.x.x和10.x.x这样的输出就说明 Node 环境没问题。

Git 不是 Codex 运行的必需条件，但 Codex 的很多典型用法都建立在 Git 仓库之上，比如自动提交代码、生成提交信息、分析 diff。如果你机器上还没有 Git，顺手装掉。装完执行：

git --version

另外要留意系统环境：Linux 和 macOS 上安装最顺畅，Windows 上虽然能跑，但需要你提前装好 WSL2 或者在原生环境里配置好 PATH。我个人的建议是 Windows 用户至少准备一个 WSL2 环境，后面接 MCP Server 的时候能少踩很多坑，因为不少 MCP Server 依赖的包在 Linux 环境下更稳定。

2.2 两种安装方式评测，以及我第一次踩的版本坑

Codex 的安装方式主要有两种：npm 全局安装和直接下载预编译二进制文件。

npm 方式最简单：

npm install -g @openai/codex

装完直接执行codex --version就能看到版本号。这是我最推荐的方式，因为后续升级只需要npm update -g @openai/codex，非常省事。

另一种方式是去官方 GitHub Releases 页面下载对应平台的二进制包，这种方式适合网络环境特殊、或者你不想装 Node.js 的情况。但二进制包需要手动管理版本，升级麻烦，我一般不用。

我第一次安装时踩过一个不算坑的坑：当时我本地已经有一个旧版本的 Codex，执行npm install -g @openai/codex之后没有强制刷新，导致 shell 缓存里还是旧版本。执行命令时发现行为不对，一度怀疑是配置问题。后来用npm ls -g @openai/codex一看，版本没变，才意识到需要重启终端或者执行hash -r刷新命令缓存。这个细节写在文档里的不多，但遇到“明明升级了却没变化”的情况，先别怀疑配置，先检查这个。

2.3 装完怎么验证真的能用了

验证 Codex 是否安装成功，最直接的方法是跑一个最简单的交互命令：

codex

首次运行会引导你完成登录和 API Key 配置。如果你之前已经配置过 OpenAI 的 API Key，也可以直接在环境变量里指定，环境变量名通常是OPENAI_API_KEY。Codex 启动后，先让它做一件不需要联网外部工具的小事，比如：

codex "输出当前目录下的文件列表，并简要说明每个文件的用途"

这一步会验证三件事：Codex 能正常启动、能连接到大模型 API、能正确解析你的指令并返回结果。等这条链路通了，我们再去折腾 MCP。

提示：如果你用的是第三方模型服务商，而不是 OpenAI 官方 API，可以在 Codex 的配置里指定自定义模型提供商，这个在后面的“接入 DeepSeek 等兼容端点”部分会详细讲。

3. MCP 机制拆解：Host / Client / Server 到底怎么协作

安装只是热身，真正决定 Codex 能发挥多大作用的，是你怎么配置 MCP。很多人配置 MCP 的时候只照着模板抄，抄完能跑就完事，但一旦出问题就完全不知道从哪查起。所以我专门用一节讲 MCP 的协作机制，这部分搞懂了，后面排错会简单很多。

3.1 一次 MCP 调用的完整链路

假设你让 Codex “读取本地的项目说明文件，然后帮忙整理成 README”。当 Codex 判断需要访问文件系统时，它会走这样一条链路：

1. Codex 作为 MCP Host，根据当前对话意图，决定需要调用文件系统工具。
2. Host 向已注册的 MCP Client 发出请求，询问有哪些可用工具。
3. Client 启动对应的 MCP Server 进程，并通过标准输入输出（stdio）与 Server 通信。
4. Server 收到“读取某路径文件”的请求后，执行真实操作，把文件内容返回给 Client。
5. Client 把结果回传给 Host（Codex），Codex 把文件内容整合进上下文，继续推理并生成 README。

整个过程对你来说是无感的，你只看到 Codex 自动读文件、生成文档，但底层其实是 Host、Client、Server 三者之间完成了一次标准化的 RPC 调用。

有个容易混淆的点：MCP Host 和 MCP Client 在 Codex 这个场景下不是一个概念。Codex 本身是 Host，而它内部会为每个 MCP Server 创建一个 Client 实例来管理连接生命周期。你在配置文件里声明的是 Server，Host 和 Client 的交互是 Codex 帮你处理的。所以新手配置时，只需要关心一件事：把 Server 定义清楚。

3.2 MCP Server 的三种形态和通信方式

MCP Server 常见的有三种形态：

本地命令型是最常见的，所以配置文件里command和args字段基本就是用来描述“怎么启动这个 Server”。比如一个基于 Node.js 的 MCP Server，通常是：

[mcp_servers.文件工具] command = "npx" args = ["-y", "某个-mcp-server-package"]

远程服务型则不需要command，而是需要填url和对应的认证信息。这类适合已经有人搭好了公共服务，你只需要连上去。

理解这几种形态之后，配置的时候就不会晕了：看到command就想到“这是一个本地进程”，看到url就想到“这是一个远程接口”。

3.3 config.toml 的关键字段解读

Codex 的配置文件路径在~/.codex/config.toml。如果你之前没用过 Codex，这个文件可能不存在，第一次启动 Codex 会自动创建，或者需要你手动建目录。

核心字段有几个：

• model：指定用哪个模型。比如model = "gpt-5"或者model = "deepseek/deepseek-chat"。
• model_provider：指定用哪个模型服务商。默认是 OpenAI，但你完全可以通过model_providers字段注册自定义服务商。
• mcp_servers：MCP Server 的配置区块，下面每个子区块就是一个独立的 MCP Server。

举个例子，一个最简配置长这样：

model = "gpt-5" model_provider = "openai" [mcp_servers.filesystem] command = "npx" args = ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]

这段配置的意思是：注册一个叫filesystem的 MCP Server，通过npx启动指定的包，并允许它访问/Users/me/projects目录。解释一下这里的逻辑：npx -y 包名 参数的作用是自动下载并运行指定的 npm 包，后面的路径参数是传给这个 Server 的使用配置，告诉它允许操作哪个目录。

配置文件里还可以给不同的 Server 区分环境变量，这个在后续接 Figma、MySQL 的时候会用到，因为每个服务需要的密钥和连接参数都不一样。

4. 第一个实战配置：接入本地文件系统 MCP

理论讲再多，不如动手配一个。我选的第一个实战案例是本地文件系统 MCP，因为它是所有 MCP Server 里最容易验证的，而且每个开发者电脑上都能用。

4.1 为什么从文件系统入手，而不是一开始就接数据库或设计工具

原因有两条。第一，文件系统 MCP 不需要任何 Token、密钥、外部依赖，只要 Node.js 能跑，它就能跑，排查问题最简单。第二，它覆盖了 MCP 配置的所有核心步骤：声明命令、传参数、验证调用、处理权限边界。把这套流程跑通了，后面接任何 MCP Server 都是同一个套路。

另外，文件系统 MCP 的实际价值也不低。我经常让 Codex 帮我批量读取项目里的多个文档，或者整理某个目录下的配置文件，接入之后它可以直接操作，效率提升非常明显。尤其是处理多文件任务时，它不用一次一次地手动接收文件内容，而是自己决定“我该读哪个文件”，这个过程完全不需要你干预。

4.2 配置文件：一个能安全落地的示例

先新建配置目录：

mkdir -p ~/.codex

然后编辑~/.codex/config.toml，加入文件系统 Server：

[mcp_servers.filesystem] command = "npx" args = ["-y", "@modelcontextprotocol/server-filesystem", "/Users/yourname/projects"]

这里的/Users/yourname/projects替换成你希望 Codex 能访问的项目根目录。有一点要特别注意：不要图方便把根目录直接写成/或者C:\，因为文件系统 MCP 一旦启动，它对这个目录下的文件有完整的读写权限。我后面在安全边界那节会细说，这里先记住一个原则：只给它访问它“需要”的路径，不要给它“所有”的路径。

保存退出后，重启 Codex，然后用这样一句指令测试：

codex "用文件系统工具列出 /Users/yourname/projects 下的所有 markdown 文件，并汇总每个文件的标题"

如果配置正确，Codex 会调用filesystem这个 Server，而不是自己去猜。一个容易忽略的验证点是：当 Codex 调用了外部工具时，交互界面里一般会显示工具调用的过程信息。如果只看到它的纯文本回答，没有看到任何“调用工具”的迹象，说明它没有真正走 MCP 链路，这时候就要去看配置是不是有问题。

4.3 验证过程中最容易踩的三个认知误区

第一个误区是“配置文件写对了就一定能用”。实际上，npx 首次启动要联网下载包，如果你的环境里 npx 的源没配好，或者网络不通，Server 会启动失败。判断方法很简单：在终端里手动执行一遍配置文件里的 command 和 args，如果能正常跑起来，说明命令本身没问题；如果手动执行都报错，说明问题在依赖或网络，不在 Codex。

第二个误区是“改了配置不需要重启”。Codex 读取 MCP 配置的时机主要是在启动阶段，你改完config.toml后，必须把当前 Codex 会话退出，重新运行，新的 Server 配置才会生效。这个和热更新是两个机制。

第三个误区是“MCP Server 越多越好”。每个 Server 占用独立的进程资源，而且每次对话开始时 Host 都要枚举一遍可用工具。如果你挂了十来个 Server，不仅启动慢，Codex 在决定“该调用哪个工具”时也会更容易选错。我实际用的 Server 长期保持在五六个之内，够用就好。

5. 高频场景的 MCP 接入模板：Figma、MySQL、蓝湖、DeepSeek

文件系统是开胃菜，真正让人眼前一亮的是把 Codex 接入设计、数据、团队协作这些高频工具。这一节我不会只给配置模板，而是把“为什么这么配”和“配的时候要准备什么”一起讲清楚。

5.1 Figma MCP：Token 在哪获取，以及完整配置流程

Figma MCP 是我接入之后使用频率最高的 Server 之一。它让 Codex 能直接读取设计稿中的图层、样式、布局参数，对前端开发特别有用。接它之前，你需要准备一个 Figma API Token。

很多人不知道 Token 在哪拿。进入 Figma 网页版，点击左下角头像，选择 Settings，进入安全设置里有一个 Personal access tokens 的选项，点 Generate new token，选好有效期和作用范围，生成后复制保存。注意：Token 只在生成时显示一次，关掉弹窗就再也看不到了。

拿到 Token 后，在~/.codex/config.toml里添加：

[mcp_servers.figma] command = "npx" args = ["-y", "figma-developer-mcp", "--stdio", "--figma-api-key=你的token"] [mcp_servers.figma.env] FIGMA_API_KEY = "你的token"

更推荐的做法是用环境变量注入，避免把 Token 明文写在配置文件里。Codex 支持在env字段里设置环境变量，所以可以写成：

[mcp_servers.figma] command = "npx" args = ["-y", "figma-developer-mcp", "--stdio"] env = { FIGMA_API_KEY = "你的token" }

配置好之后，我给 Codex 发一句“读取这个 Figma 文件的封面区域，生成对应 HTML/CSS”，它就会自己去计算设计稿的参数。省掉的工具切换时间，累计下来非常可观。

注意：Figma MCP 的请求会消耗你的 Figma API 配额。如果团队里共用一个 Token，最好做好频率限制，不要在 CI 环境里高频调用。

5.2 MySQL MCP：连接串配置与权限边界

数据库 MCP 的配置核心是连接串。MySQL 的 MCP Server 通常会要求你提供一个标准的数据库连接字符串，格式类似：

mysql://用户名:密码@主机地址:端口/数据库名

在 Codex 配置文件里注册：

[mcp_servers.mysql] command = "npx" args = ["-y", "@benborla29/mcp-server-mysql"] env = { MYSQL_CONNECTION_STRING = "mysql://root:你的密码@localhost:3306/mydb" }

配置完成后，Codex 就可以执行实际的 SQL 查询。但这个能力是把双刃剑。我在配置数据库 Server 时给自己定了几条规矩：

• 绝不使用 root 账号。单独创建一个只读账号，或者只授权给特定数据库，最大程度降低误操作。
• 默认只开放 SELECT 权限。读数据足够解决绝大多数“帮我分析数据”的需求。
• 真正的写操作（INSERT/UPDATE/DELETE）通过额外的审计机制处理，不要在 AI 工具配置里放开。

这么做不是因为 Codex 不可信，而是因为 AI 在推理过程中可能因为上下文误解而执行了错误的语句。给它一个超集权限，等于把整个数据库暴露在潜在风险下。接入 MCP 的时候，能力和安全边界要一起设计。

5.3 蓝湖 MCP 和内部工具接入的思路

蓝湖是很多设计师和前端协作时候用到的平台。如果你的团队用了蓝湖管理设计资产，可以找一下蓝湖是否提供了对应的 MCP Server 或 API Token。接入思路和 Figma 完全一样：准备好 Token，把它作为环境变量传给 MCP Server，然后在 Codex 里声明这个 Server。配置代码就不再重复了，照着 Figma 的模板把包名和 Token 替换掉就行。

这里我想多说一句内部的、不对外公开的工具接入。很多人觉得只有“大厂工具”才有 MCP 支持，其实只要你的内部平台有 HTTP API，你就可以用一个通用 HTTP MCP Server 包一层，把内部 API 暴露给 Codex。我之前给团队的内部监控系统做过一次类似封装，配置思路是：

1. 确认内部 API 是否需要 Token 或签名。
2. 选一个支持 OpenAPI 规范的 MCP Server，让它自动把接口转换成工具。
3. 在 Codex 配置里注册，并限制可访问的接口范围。

这种方式让整个团队都能用自然语言查询监控指标，而不需要每个人都记住复杂的 API 调用方式。MCP 的价值不只是接外部工具，更是把团队内部的知识和系统也变成 AI 可以调用的工具。

5.4 接入 DeepSeek 等兼容端点时的模型配置思路

Codex 本身是为 OpenAI 模型设计的，但它对兼容 OpenAI API 格式的第三方模型服务商支持得也很好。如果你用的是 DeepSeek 或者其他兼容端点，不必放弃 Codex 的本地体验，只需要在配置文件里注册自定义模型提供商。

在~/.codex/config.toml里加：

model_providers.deepseek = { name = "DeepSeek", base_url = "https://api.deepseek.com/v1", env_key = "DEEPSEEK_API_KEY", wire_api = "responses" }

然后在顶层设置默认模型：

model = "deepseek/deepseek-chat" model_provider = "deepseek"

设置完之后，在终端导出DEEPSEEK_API_KEY，或者直接在配置里通过环境变量指定，就可以让 Codex 跑在 DeepSeek 模型上了。这里要提醒一句：不同的模型能力差异很大，如果你发现 Codex 在某个模型下特别容易漏调用工具，先检查不是 MCP 配置的问题，而可能是模型本身的工具调用能力较弱。遇到这种情况，换个更强或更适合工具调用的模型，往往比折腾配置更有效。

6. 配置过程中我踩过的坑和完整排查链路

这一节是整篇教程里最“值钱”的部分。配置 MCP 本身不难，难的是报错之后怎么定位。我把真实遇到过的几个问题整理成完整的排查过程，希望你在遇到类似情况时，不用像我一样从头绕。

6.1 Codex 请求端点转发失败的完整排查过程

先描述一下现象：我配置好一个 MCP Server 之后，重启 Codex 开始对话，结果请求没有正常返回，控制台日志里出现了一个类似 “config switch 在转发 Codex 请求端点时报告失败” 的错误。当时我第一反应是配置写错了，把 MCP 配置删了重写了好几遍，问题依旧。

后来我才意识到，问题根本不在 MCP，而在上层。这个错误的核心含义是：Codex 在向模型服务端发起请求时，本地的网络链路配置有问题，请求没有到达预期的模型服务端点。

排查过程我按这个顺序走了一遍：

1. 先验证基础连通性：单独用 curl 请求一次模型服务的 API 端点，比如curl -X POST https://api.openai.com/v1/responses -H "Authorization: Bearer 你的key" -d '{"model":"gpt-5"}'。如果这一直失败，问题一定不在 MCP。
2. 检查环境变量：看当前 shell 里有没有设置过影响请求目标地址的变量（比如OPENAI_BASE_URL之类）。如果之前为了接第三方服务改过这类变量，指向的旧地址已经失效，Codex 就会把请求发错地方。
3. 检查本地网络转发配置：很多开发环境里会配置本地的网络转发服务来统一管理 API 请求出口。如果这个转发服务的端口、规则或者证书配置更新过，而 Codex 的请求还指向旧配置，就会出现端点处理失败。
4. 查看 Codex 日志：Codex 在运行时会输出详细的调试信息，可以用Codex的 verbose 模式或者直接查看日志文件，定位到具体的请求 URL。如果请求 URL 和你预期的模型端点不一致，那十有八九是环境变量或本地网关配置覆盖了默认地址。
5. 最小化验证：临时把 MCP 配置全部注释掉，只保留最基础的模型配置。如果问题依然存在，说明和 MCP 无关，聚焦到模型配置；如果问题消失，再逐个恢复 MCP 配置，找到触发问题的那个 Server。

我那次最后定位到的原因，是之前为了另一个项目设置过指向旧 API 网关的环境变量，Codex 检测到了它并尝试把请求转发过去，而那个网关已经不再响应。解决办法是把无关的环境变量清理掉，让 Codex 走默认的 API 配置，问题立刻消失。这个坑非常隐蔽，因为你不会第一时间想到模型请求和本地转发配置之间的关系。

6.2 MCP 工具注册不上：从日志到配置的定位顺序

另一个高频问题是：配置好mcp_servers，但 Codex 在对话中好像完全不知道这些工具的存在，对话里也没有任何工具调用痕迹。

这个问题的排查顺序应该是：

1. 先确认配置文件有没有被读到。在 Codex 交互界面里用一个简单的指令触发 MCP Server，比如post soak。如果配置格式错误或者文件位置不对，Codex 可能压根没加载这个文件。
2. 手动执行一遍 MCP Server 的启动命令。比如配置里写的是npx -y some-mcp-server，就在终端直接跑一遍。如果手动执行都有错误，说明不是 Codex 的问题，而是这个依赖包启动失败。常见的失败原因是 Node 版本不兼容、缺少系统依赖、包名拼写错误。
3. 检查 MCP Server 启动后的输出格式。MCP 需要 Server 在标准输入输出上按照协议格式通信，如果 Server 打印了额外的业务日志到标准输出，就会破坏协议通信，导致 Codex 无法识别。有些 Server 会提供参数把日志重定向到标准错误输出，配置时留意一下。
4. 检查是否给了 Server 正确的参数。很多 Server 在初始化时需要明确指定允许访问的路径、数据库名或接口地址，如果参数缺失，Server 虽然启动成功，但没有暴露任何工具，Codex 自然调不到。

我当时踩过的一个典型问题是：文件系统 MCP 没有传允许访问的目录参数，Server 空转，Codex 枚举工具时一个都看不到。加上目录参数之后，重新启动，工具才正常注册。

6.3 资源占用、循环调用和权限过大的边界问题

配置层面全部跑通之后，还有几个“用着用着才会遇到”的问题。

第一个是资源占用。MCP Server 是独立进程，如果你配置了多个基于 npx 的 Server，每个首次启动都要下依赖包，内存和 CPU 占用都不低。我遇到过同时挂了四个 Server 后，Codex 明显变慢的情况。解决思路是把常驻的 Server（比如数据库）改成安装到本地后用可执行文件直接启动，避免每次都走 npx 解析流程。

第二个是循环调用。Codex 在决策过程中可能因为上下文不够，反复调用同一个工具而得不到有效结果。比如让它读一个巨大的日志文件，它读了一部分发现不够，又去读下一部分，反复多次，不仅浪费 token，还有可能把上下文撑爆。遇到这种情况，最好在指令里明确限制读取范围，或者让 Server 提供过滤能力，减少无效调用。

第三个是权限边界，这个前面提过，但值得再强调一遍。MCP 的能力是实打实的系统调用权限，不是停留在“建议”层面的。文件系统 MCP 可以删文件，数据库 MCP 可以删数据，HTTP MCP 可以发请求。给 Codex 配置这些工具的时候，权限要给到“刚好够用”，而不是“越多越好”。

我个人的习惯是：每个 MCP Server 都单独建一个最小权限账号或专用路径，Token 单独生成，不共用生产密钥。这个习惯让我在一次误操作中保住了数据——那一次 Codex 错误地理解了我要修改的文件路径，但因为它只有特定目录的权限，操作被限制在了沙箱目录里，没有波及整个项目。

最后说点实在的

配置 Codex 加 MCP 这件事，本质上是在给 AI 装“手”和“眼睛”。装好之前，它只是一个会聊天的编辑器插件；装好之后，它才真正变成能接手完整任务的协作者。整个过程中我最大的体会是：不要追求一次性接入所有工具，先从一个最常用的场景开始，跑通链路，再逐步扩展。每加一个 MCP Server，都先想清楚三个问题：它需要什么权限、它能解决什么具体问题、出了问题我能不能快速切断它。按这个节奏来，你能把 Codex 变成真正好用的生产力工具，而不是给自己埋一堆坑。