前两篇，我们把 MCP 的「内服」和「外用」都聊透了。内服是 in-process 的内存调用，直接在项目里 import server 对象；外用是 out-of-process，分子进程和远程网络两条路。这两篇举例用的都是 Claude Code。

但现在手上不止一个 Agent 工具，我平时 Claude Code 和 Codex 换着用。为了彻底弄清这两兄弟的管理策略，我又巴拉拉的找了一大批资料，看完后，集中汇总整理，分享出来。

这篇就横向对比一下两者在 MCP 管理上的异同，顺便给整个 MCP 系列收个尾，值得一提的是，Codex APP版和CLI版共享配置。

结论先给

其实只有一句话，记住它：

Claude Code：把 MCP 当成一个专门的东西，给它单独设计了 local / project / user 三种 scope。

Codex：把 MCP 当成 config.toml 里的普通一类配置，作用范围靠配置文件的层级决定。

一个像「专门的 MCP 工程」，一个像「配置体系里的一个模块」。差异都从这里来，这概念有点深奥？没事，看完就懂了。

一、相同的部分：命令几乎一模一样

好消息是，两者的日常命令长得基本一样，会了一个另一个也就会了：

两点值得记一下：

一是 mcp add都不是"安装程序"，它不会把脚本复制到哪去，只是记录一条"如何启动这个 MCP server"的配置。就是存下 command 和 args，用的时候按配置把进程拉起来。

二是 stdio 的启动命令前面都要用 -- 分隔。-- 后面的东西会原样传给 server，不然 server 自己的参数容易被 CLI 当成自己的参数解析掉。这是两边共同的坑。（为什么要提这个，因为我吃过亏啊.........）

举个例子，假设你的 mcp.py 脚本要接收一个 --port 参数：

# 错误：--port 会传给 claude，claude就会报错说不认识claude mcp add demo /usr/bin/python3 /data/mcp.py --port 9000 # 正确：demo后面添加独立的`--`，之后的整段都原样交给 mcp.pyclaude mcp add demo -- /usr/bin/python3 /data/mcp.py --port 9000

其中-- 就是一道分水岭，左边是给 CLI 的（比如 --scope、--transport），右边是给 server 的。记不清的时候，把启动命令一律放 -- 后面就不会错。

二、最大的不同：作用域怎么来的

这是两者真正分道扬镳的地方，也是前面那句结论的核心。

Claude Code 的作用域，写在命令里。加一个 --scope 就切换：

claude mcp add --scope local   demo -- ...   # 当前项目可用，只对你，不进 Gitclaude mcp add --scope project demo -- ...   # 当前项目可用，团队共享，可进 Gitclaude mcp add --scope user    demo -- ...   # 所有项目可用，只对你

同名 server 撞车时，优先级是 local > project > user，而且不合并字段，直接用优先级最高的那一整条。

Codex 没有 --scope 这个概念，作用域是靠配置文件放在哪决定的：

~/.codex/config.toml   用户级，默认对所有项目生效
.codex/config.toml     项目级，只在当前项目生效（且项目要被信任才加载）

所以 codex mcp add 默认就是往用户级 ~/.codex/config.toml 写。你想要"项目级 MCP"，Codex 里没有 --scope project 这种写法，得手动在项目根目录的 .codex/config.toml 里加一段。

一句话对照：Claude 是「MCP 自己带作用域」，Codex 是「配置文件层级决定作用域」。

三、配置文件长什么样：JSON vs TOML

顺着上面看一眼落地的配置文件，风格差异也很直观。

Claude Code 用 JSON（项目级在 .mcp.json，用户级在 ~/.claude.json）：

{  "mcpServers": {    "demo": {      "command": "/usr/bin/python3",      "args": ["/data/mcp.py"],      "env": {        "FOO": "bar"      }    }  }}

Codex 用 TOML（就是 config.toml 里的一张表）：

[mcp_servers.demo]command = "/usr/bin/python3"args = ["/data/mcp.py"] [mcp_servers.demo.env]FOO = "bar"

一个小差异值得留意：Claude 的 .mcp.json 支持 ${VAR}、${VAR:-default} 这种变量展开，团队共享时用来处理机器差异和密钥很方便；Codex 这边则靠 TOML 的 env、cwd 等字段来处理启动环境。

至于 transport，两者都支持 stdio（本地进程）和 HTTP（远程服务），日常够用，其余都是细枝末节，这里就不展开了。

四、从 Claude 迁到 Codex 的小抄

如果你像我一样两个工具换着用，记住这张对照就够搬家了：

唯一对不齐的是 Claude 的 local：它是"写在你私有文件里、但只绑定当前项目路径"，Codex 没有完全等价的东西，写用户级就对所有项目生效，写项目级又变成了项目文件。这正是前面说的，Codex 是配置层覆盖，Claude 是 MCP 自带作用域。

不过我前面也说过了，local的使用比较鸡肋，不重要。

还有个实用提醒：团队共享的配置里，别把路径写死成 /data/mcp.py 这种绝对路径，要灵活处理，别把配置共享出去之后，发现队友那儿没有，就尴尬了。

收个尾

到这，MCP 系列三篇就齐了：

第一篇：从MCP的in-process看智能体工具接入的实现

第二篇：为开发助力，业务已有的接口可以这么接入Claude Code

从怎么写一个 MCP，到怎么把它接进 Agent，再到换了工具怎么管，一条线走下来，MCP 这块心里应该有底了。

回到开头那句"看完就懂了"，现在再看应该就不深奥了：

所谓「专门的 MCP 工程」，就是 Claude 把作用域做进了 mcp add 命令本身，一个 --scope 就切；

所谓「配置体系里的一个模块」，就是 Codex 压根没这个命令参数，你把配置写进哪个 config.toml，它的作用范围就是哪，主打一个随心所欲。

一个靠命令，一个靠文件位置，区别就这么点。

真要动手时，记住这句话就行：Claude Code 把 MCP 当成一个专门的安装系统，Codex 把它当成 config.toml 里的一个模块。剩下的，查一下命令就能搞定。