限制 Codex 的 MCP Tool 写权限，不能只依赖提示词，也不能只把 Codex 设置成只读模式。更可靠的做法是分三层处理：先在 Codex 中关闭或排除具体写入工具，再用审批策略拦截未授权调用，最后在 MCP Server 或下游系统的账号权限中落实只读身份。涉及远程数据库、代码仓库、工单系统和云资源时，服务端权限才是最终边界。

如果目标是“允许 Codex 查询，但不允许它创建、修改、删除”，建议采用“只暴露读工具 + 只读凭证 + 默认需要审批”的组合。因为 Codex 的文件系统沙箱主要约束本地命令和本地文件，并不会自动阻止 MCP Server 通过 API 修改外部系统。即使当前工作区是只读的，一个拥有写权限的 MCP Tool 仍可能改变远程数据。

## 一、先分清三种“写权限”，不要把它们混为一谈

很多人配置 MCP 权限时，看到 `workspace-write`、`read-only` 或审批提示，就以为所有写操作都已经被限制。事实上，Codex 使用 MCP 时至少涉及三类不同边界。

第一类是本地文件写权限。比如 Codex 通过命令行修改代码、生成配置文件、删除临时文件，这部分通常受到 Codex 沙箱模式影响。只读沙箱可以限制模型直接修改工作区；工作区可写模式允许它在指定目录中编辑文件；更宽松的模式则可能允许访问更广泛的本机资源。

第二类是 MCP Server 对外部系统的写权限。比如一个 MCP Tool 可以向数据库执行更新语句，可以创建 Git 分支，可以关闭工单，可以发送消息，也可以修改云平台配置。这些操作不是 Codex 本地文件写入，不能简单依靠本地沙箱阻止。

第三类是工具调用权限。即使 MCP Server 具备写能力，Codex 是否能够发现、调用和执行这些工具，还受到 MCP 工具启用状态、工具过滤、审批策略以及当前会话设置的影响。

可以用下面的方式理解各层边界：

| 权限层 | 主要控制对象 | 能否限制远程 MCP 写操作 | 适合解决的问题 |
|---|---|---:|---|
| Codex 沙箱 | 本地命令、本地文件、进程访问 | 通常不能完全限制 | 防止直接改动工作区或执行危险命令 |
| MCP 工具启用与过滤 | Codex 可见、可调用的工具 | 可以减少调用入口 | 禁止暴露创建、更新、删除类工具 |
| 审批策略 | 工具调用前是否需要人工确认 | 可以拦截未经确认的调用 | 防止模型自动执行敏感动作 |
| MCP Server 权限 | Server 使用的账号、令牌和接口能力 | 可以从服务端强制限制 | 确保即使误调用也无法写入 |
| 下游系统权限 | 数据库、代码平台、云平台的角色权限 | 可以形成最终约束 | 防止通过其他接口绕过 Codex 配置 |

其中最重要的是最后两层。Codex 的配置属于客户端控制，MCP Server 使用的身份和下游系统角色属于服务端控制。只要写权限没有在服务端撤掉，就不能把“工具未被调用”误认为“工具没有写能力”。

## 二、先盘点 MCP Tool，再决定哪些工具可以开放

限制写权限之前，不要先凭工具名称猜测风险。一个工具叫 `search`，可能只是查询；也可能在查询后自动创建缓存、保存会话或更新远程状态。一个工具叫 `update`，也不一定意味着可以修改核心数据，可能只是更新本地索引。因此，真正需要确认的是工具的输入参数、执行逻辑和下游接口。

建议对每个 MCP Server 做一次工具清单，至少回答四个问题：

- 工具是否只读，还是会创建、修改、删除数据；
- 写入对象是什么，是本地文件、远程记录、权限配置，还是消息内容；
- 是否支持批量操作、通配范围或递归执行；
- 工具执行前是否有二次确认、预览、事务回滚或幂等保护。

可以按照“查询、准备、提交、破坏”四个等级进行判断。查询类工具通常包括搜索、读取、列举、获取详情；准备类工具可能生成草稿、构造变更计划或创建未提交的临时对象；提交类工具会真正写入业务系统；破坏类工具则包含删除、撤销、覆盖、发布、发送和权限变更。

不要只看工具描述里的“read”或“write”字样。MCP 工具描述是给客户端和模型理解用途的元数据，不应当被视为安全边界。工具描述写成“仅用于同步”并不代表它没有修改行为，最终仍要检查 Server 的实现和凭证权限。

在审计过程中，尤其要关注以下几种容易被忽略的写操作：

1. 查询时自动记录用户、更新时间或访问日志。  
2. “同步”“刷新”“修复”“应用变更”这类看似辅助性的操作。  
3. 发送邮件、消息、评论、通知或创建外部任务。  
4. 通过通用 HTTP、数据库或脚本工具间接执行任意写入。

如果无法确认一个工具是否只读，应当按可写工具处理，而不是按只读工具处理。权限配置的原则不是证明它安全，而是在不确定时先不给能力。

## 三、在 Codex 端关闭写工具或只允许明确的工具集合

当 MCP 配置支持工具启用和禁用过滤时，应优先采用“白名单”方式：只启用已经确认的查询工具，而不是启用全部工具后再逐个排除写工具。

不同 Codex 版本和发行渠道的配置项名称可能存在差异，常见配置会围绕 MCP Server 的启用状态以及工具允许、禁用列表展开。使用前应以当前版本的 Codex 配置说明或命令行帮助为准，不要直接照抄其他版本的字段。配置思路可以抽象为：

```toml
[mcp_servers.example]
command = "..."
args = ["..."]
enabled = true

# 仅保留确认过的查询工具
enabled_tools = ["search_records", "get_record", "list_projects"]

# 或明确禁用写入工具
disabled_tools = ["create_record", "update_record", "delete_record"]
```

上面的字段示例表达的是配置意图，不代表所有版本都支持完全相同的字段名。实际落地时要确认三件事：配置是否被当前 Codex 读取，工具名是否与 MCP Server 实际暴露的名称一致，以及过滤后工具是否真的从会话工具列表中消失。

白名单和黑名单的差异很大。黑名单适合工具数量少、名称稳定、已经完成审计的 Server；白名单更适合第三方 Server、工具数量较多或工具会随版本变化的场景。只要 Server 新增了一个写工具，黑名单可能因为没有及时补充而失效，白名单则不会自动放行新工具。

还要注意工具过滤只限制“当前客户端可调用哪些工具”，并不一定改变 MCP Server 自身的权限。如果其他客户端、脚本或同一 Server 的另一个连接仍使用原来的写入凭证，远程系统依然是可写的。因此，过滤配置应该被视为减少暴露面，而不是最终授权。

对开发阶段比较实用的做法是准备两套配置：

- 查询配置：只加载检索、读取、分析工具，使用只读账号；
- 变更配置：单独加载写工具，使用独立账号，并强制人工审批。

不要让同一个长期会话同时拥有大量查询工具和高风险写工具。任务完成后，关闭不需要的 MCP Server，能够减少模型选错工具、误解参数和扩大操作范围的机会。

## 四、用审批策略拦截调用，但不要把审批当成唯一防线

审批策略解决的是“调用前是否需要人确认”，而不是“工具有没有写权限”。当 Codex 处于需要审批的模式时，模型准备调用敏感 MCP Tool，通常会把调用动作、参数或执行请求交给用户确认。用户可以查看目标对象、操作类型和输入内容，然后决定是否继续。

这层控制对以下场景很有价值：

- 第一次使用一个不熟悉的 MCP Server；
- 工具可能修改数据，但暂时无法拆分成独立的只读和写入 Server；
- 操作范围不固定，需要人工确认目标项目、记录或文件；
- 写入动作低频但后果较大，例如发布、删除、发送或权限变更。

不过，审批存在三个现实限制。

第一，用户可能没有认真检查参数。一个看起来普通的“更新记录”调用，参数中可能包含批量条件、全表范围或覆盖字段。审批如果只是机械点击，就失去了审查意义。

第二，自动化模式可能减少或跳过交互式确认。为了让任务连续执行，用户可能开启更宽松的审批策略，但这会让写工具在获得调用资格后直接运行。尤其是无人值守任务、持续集成和远程终端环境，不能依靠人工审批作为稳定安全机制。

第三，审批不能阻止 Server 内部的附带写入。如果一个读取工具在服务端会更新缓存、写审计表或触发同步，Codex 看到的只是一次读取调用，人工很难仅凭工具名称判断全部副作用。

因此，审批策略应当与工具分层结合。查询工具可以在信任度较高的环境中减少打扰；所有创建、修改、删除、发布、发送和权限变更类工具，则应保持逐次确认，或者干脆不在普通会话中加载。

更稳妥的确认方式不是只问“是否执行”，而是检查四项内容：操作对象、影响范围、写入字段、是否可撤销。涉及批量操作时，还要确认筛选条件和预计数量。若工具不能展示变更预览，应把它视为更高风险工具，而不是因为操作名称简单就自动放行。

## 五、在 MCP Server 和下游系统实现真正的只读约束

如果目标是“无论 Codex 怎么调用，都不能写入”，必须在 MCP Server 或下游系统撤销写权限。客户端配置可以被误改、被覆盖，也可能因为版本升级而行为变化；服务端账号权限才是更稳定的强制边界。

最常见的实现方式是为只读场景单独创建身份，不要直接复用开发者个人账号。数据库连接使用只读角色，代码托管平台使用只能读取仓库内容的令牌，工单系统使用不包含创建和更新权限的服务账号，云平台则只授予查询资源状态所需的最小权限。

如果 MCP Server 自己提供多个操作类别，可以从接口层拆分为两个 Server 或两个运行配置：一个只提供读取工具，另一个才提供变更工具。这样比在同一个通用工具中依靠模型理解参数更可靠。例如，不要暴露一个支持任意 SQL 的工具，再要求模型只执行查询；更安全的方式是由 Server 提供受限查询接口，禁止传入更新、删除、执行脚本等语句。

对数据库场景尤其要避免把高权限连接交给通用 MCP 工具。一个名为“执行查询”的接口，如果底层账号拥有写权限，模型只需要改变输入内容，就可能执行更新语句。可以采用数据库只读角色、只读副本、固定查询接口、参数化查询和语句级校验，必要时在数据库层拒绝写入语句。

对代码仓库和云资源也要采用相同思路。只读凭证应当不具备推送、合并、删除分支、创建密钥、修改策略或发布资源的权限。若业务必须支持写操作，应使用短时凭证、限定仓库或项目范围，并将高风险操作放入独立流程，而不是把完整管理员凭证配置到 MCP Server 的环境变量中。

环境变量本身也值得检查。很多 MCP Server 通过令牌、连接字符串或配置文件获得权限。如果只在 Codex 中禁用了某个写工具，却仍把管理员令牌传给 Server，后续任何新工具、通用脚本接口或配置错误都可能重新暴露写能力。更安全的顺序是先降低凭证权限，再做客户端工具过滤。

## 六、按风险设计一条可落地的限制路径

如果你现在已经接入了一个具备写能力的 MCP Server，不必一开始就重构全部系统，可以按以下顺序收紧。

第一步，停止在生产数据上测试。将 MCP Server 指向测试项目、沙箱环境或只读副本，避免用真实业务数据验证权限行为。不要因为工具名称看起来安全，就直接让它连接生产账号。

第二步，列出工具和实际副作用。通过 MCP 初始化信息、工具说明和 Server 实现确认所有工具名称、参数、接口目标以及可能的附带写入。无法确认的工具暂时关闭。

第三步，建立最小白名单。只开放完成任务所需的查询工具，关闭创建、更新、删除、发送、发布、同步和权限变更类工具。任务不需要的 Server 也不要加载。

第四步，替换凭证。把个人账号和管理员令牌换成专门的只读服务账号，限制项目、仓库、数据库或租户范围，并设置合理的过期和轮换机制。

第五步，保留敏感操作审批。即使服务端已经限制了部分权限，仍应对剩余写入操作启用人工确认，重点查看目标、范围和参数，不要只确认工具名称。

第六步，做反向验证。分别测试查询、创建、更新、删除和批量操作，确认被禁用的工具不会出现在可调用列表中，服务端只读账号会拒绝写请求，Codex 沙箱也确实阻止了不应发生的本地文件修改。

可以用下面的判断标准验收：

| 验收问题 | 合格状态 |
|---|---|
| Codex 是否能看到写工具 | 普通只读会话看不到，或调用前必需审批 |
| MCP Server 使用什么身份 | 专用最小权限账号，不是个人管理员账号 |
| 远程写请求是否会被服务端拒绝 | 使用只读身份测试时明确失败 |
| 本地文件是否仍可能被修改 | 由只读沙箱或工作区权限限制 |
| Server 新增工具是否会自动放行 | 默认不放行，采用白名单或重新审核 |
| 出现误操作后能否追踪 | 有调用日志、账号标识和操作记录 |

落地时最容易卡在“工具过滤配置不生效”。常见原因包括配置文件路径错误、字段名与版本不匹配、工具名写错、MCP Server 返回的名称与文档描述不同，以及修改配置后没有重新启动会话。排查时不要只看配置文件是否保存，应直接查看 Codex 当前会话能够发现的工具列表。

另一个常见问题是“只读工具仍然造成变化”。这通常不是 Codex 权限配置错误，而是 Server 的实现包含隐式写入。例如查询时刷新远程缓存、自动创建不存在的项目、记录状态或触发同步。遇到这种情况，要回到 Server 代码、接口文档和服务端日志中确认行为，不能仅靠工具命名解决。

## 七、常见误区：哪些做法看似限制，实际并不够

### 只把 Codex 设为只读沙箱

这只能主要限制本地文件和命令执行，不能自动改变 MCP Server 使用的远程账号权限。Codex 仍可能调用一个拥有写权限的远程 API。正确做法是同时限制 MCP 工具和 Server 凭证。

### 只在系统提示词中写“不要修改数据”

提示词属于行为约束，不是权限控制。模型可能误判工具用途，用户也可能在后续任务中改变指令。凡是不能发生的操作，都应该通过工具过滤、审批或服务端角色真正禁止。

### 只删除明显叫“delete”的工具

写操作不只有删除。创建、更新、提交、发布、发送、同步、执行脚本、修改权限都可能带来业务影响；一个通用请求工具还可能间接调用任意写接口。应按实际副作用审计，而不是按名称筛选。

### 只依靠每次弹出的确认窗口

确认窗口适合减少误操作，但无法替代最小权限。面对高频调用、批量参数或无人值守任务，人工确认可能流于形式。服务端拒绝未授权请求，才是不能绕过的限制。

### 让查询和写入共用一套高权限凭证

这是风险最大的配置之一。即使暂时隐藏了写工具，未来新增工具、配置恢复或 Server 逻辑变化，都可能重新使用高权限身份。只读会话应使用只读凭证，写入会话使用独立、范围受限且可审计的凭证。

### 用一个“万能 MCP Tool”承载所有动作

例如同时支持读取文件、执行命令、访问数据库、调用 HTTP 接口的通用工具，很难通过名称或简单配置判断风险。更好的方向是将查询与变更拆分，把参数范围和目标范围收窄，并让高风险操作拥有单独的授权流程。

## 八、总结：把限制写权限做成多层防线

限制 Codex 的 MCP Tool 写权限，推荐采用明确的优先级：普通会话只加载经过审计的读工具；Codex 端使用工具白名单或禁用写工具；敏感调用保持人工审批；MCP Server 使用只读、最小权限、范围受限的服务账号；数据库、代码仓库和云平台再从下游系统层拒绝写入。

如果只能先做一件事，应优先替换 MCP Server 使用的高权限凭证，因为这是最接近最终边界的控制。随后再补充工具过滤和审批策略，分别减少暴露面和误操作概率。这样即使 Codex 误选工具、配置失效或 Server 新增接口，远程系统也不会轻易被写入。

可以在 MCP 服务端把涉及创建、更新、删除的能力移出可用列表，只保留查询类接口；同时在 Codex 侧仅暴露只读工具集合。这样即使模型想调用写操作，也不会拿到对应的工具入口，从源头降低误操作风险。

将 MCP 工具切换为只读能力

我希望 Codex 可以查询 MCP 工具返回的信息，但不希望它对外部系统做任何修改，这种场景应该怎么配置？

怎样让 Codex 只读取 MCP 工具数据而不执行写入？

更稳妥的方式是把读写能力拆成两个独立工具：一个只提供读取方法，另一个承载写入方法。再配合权限控制，只把读取工具接入 Codex。这样权限边界更清晰，也便于后续审计和维护。

把读写接口拆分并单独授权

有些 MCP 工具一个服务里既有查询也有修改能力，我只想让 Codex 使用查询部分，避免它调到写接口，有没有更稳妥的做法？

如果某个 MCP 工具同时包含读写接口，怎么阻止它执行写操作？

可以给 MCP 服务配置最小权限的访问令牌，只开放指定资源、指定环境或指定动作范围。例如只允许某个测试环境的有限字段更新，不授予删除和批量修改权限。再结合服务端校验，能把写入风险控制在较小范围内。

用最小权限令牌和受限作用域

如果我必须保留写入能力，但希望写操作只在很小的范围内生效，应该怎么做才能减少影响面？

能不能通过权限令牌限制 Codex 对 MCP 的修改范围？

PingCodeDocs

限制Codex的MCP Tool写权限不能只依靠只读沙箱或提示词，应从工具过滤、调用审批、MCP Server权限和下游系统角色四层同时控制。普通会话只开放经过审计的查询工具，写入工具使用独立配置和人工审批，服务端则采用只读凭证、最小权限和范围限制，最终通过反向测试确认创建、修改、删除及批量操作确实无法执行。

Codex 如何限制 MCP Tool 写权限