给 Codex 接入 PowerShell.MCP：从零认识 MCP，到在 Windows 上配好可用环境

前几天我一直在折腾 Windows 下的开发环境，希望尽可能获得接近 Linux 的命令行体验，所以陆续装了 neovim、neovide、yazi、bat、ripgrep、dust、fd、fzf、zoxide 等一批工具。等这些工具逐渐顺手之后，一个新的问题就冒出来了：能不能让 AI 助手直接更自然地使用我这套本机终端能力？

答案是可以，而其中一个关键接口，就是最近越来越常见的 MCP。

我是个 MCP 新手，在这之前几乎没真正用过它。本文就把这次从认识 MCP、选择 PowerShell.MCP、到最终把它接入 Codex 的过程完整记录下来。文章不会假设你已经有经验，而是尽量用新手能看懂的方式说明每一步到底在干什么。

一、MCP 到底是什么？为什么会和 AI 工具扯上关系？

MCP 全称是 Model Context Protocol，可以理解成一套让 AI 客户端与外部工具、外部服务对接的协议。

如果只说定义，听起来还是有点抽象。换个更容易理解的说法：

• AI 模型本身擅长理解语言、生成答案
• 但它默认并不会操作你的电脑、读你的数据库、调用你的本地脚本
• MCP 的作用，就是给 AI 提供一套“可插拔的工具接口”

通过 MCP，一个 AI 客户端可以接入各种能力，比如：

• 文件系统
• 数据库
• 浏览器自动化
• 本地命令行
• 笔记系统
• 搜索服务
• 自定义脚本

所以，MCP 的本质不是某个具体软件，而是一种标准化接入外部能力的方式。

我倾向于认为，理解这点很重要，因为很多人第一次接触 MCP 时，会误以为“装了 MCP 就自动变强了”。其实不是。真正有价值的是：你把什么能力通过 MCP 暴露给 AI。

二、为什么我选 PowerShell.MCP？

既然目标是在 Windows 上让 Codex 更自然地使用本机环境，那么我最需要的不是浏览器能力，也不是数据库能力，而是一个可靠的、适合 Windows 的终端能力入口。

这时候，PowerShell.MCP 就非常合适。

它的核心思路很直接：把 PowerShell 会话包装成一个 MCP Server，供支持 MCP 的客户端调用。

这样做有几个现实好处。

1. 它天然适合 Windows

虽然 Windows 也能装很多 Linux 风格工具，但最终最稳、最原生、最适合系统管理的命令环境，仍然是 PowerShell。

比如下面这些事，本质上就更适合交给 PowerShell：

• 读取和修改环境变量
• 调用 PowerShell 模块
• 查询系统状态
• 做批量文件处理
• 编排本机命令
• 跑一段持续存在的终端会话

2. 它不是一次性命令，而是“会话型”能力

普通命令执行器，往往是一条命令跑完就结束。PowerShell.MCP 更像是给 AI 一个可持续工作的 PowerShell 控制台。

这点很关键，因为它意味着 AI 可以：

• 启动一个会话
• 在里面连续执行多条命令
• 共享上下文
• 查询当前路径
• 等待某个命令完成

也就是说，它更适合真实开发工作流，而不只是“执行一条命令然后退出”。

3. 它和我现有的工具链很搭

我机器上已经装了一批命令行工具：

• ripgrep
• fd
• bat
• fzf
• yazi
• jq
• git
• lazygit
• dust
• ffmpeg
• imagemagick

当这些工具和 PowerShell 组合起来时，AI 能做的事情就多很多了。比如先用 fd 找文件，再用 rg 搜内容，再用 bat 预览，再用 jq 处理 JSON。这种组合拳，远比单一工具有价值。

三、配置之前，我先确认了哪些前置条件？

在真正安装前，我先检查了两件事。

1. Codex 本身支持 MCP 配置吗？

答案是支持。

Codex 的用户配置文件在：

1

C:\Users\cy\.codex\config.toml

这个文件除了可以配置模型、项目信任级别、Provider 等内容之外，也支持声明 MCP Server。它的结构大致是：

1
2
3
4
5

[mcp_servers.server_name]
command = '可执行文件路径'
enabled = true
startup_timeout_sec = 20
tool_timeout_sec = 120

这一步非常重要，因为如果客户端本身根本不认 mcp_servers 这一段，后面做再多都是白搭。

2. 本机 PowerShell 版本够不够？

PowerShell.MCP 对 PowerShell 版本有要求，我实测本机 pwsh 版本是：

1

7.5.3

也就是说，前置条件满足。

如果你还停留在老的 Windows PowerShell 5.x，那就先不要急着装 PowerShell.MCP，而是优先升级到 PowerShell 7。

四、实际安装过程：怎么把 PowerShell.MCP 装到本机？

安装命令本身并不复杂，在 PowerShell 7 里执行：

1

Install-PSResource PowerShell.MCP -TrustRepository

这条命令会通过 PowerShell 的资源仓库把模块安装下来。

安装完成后，我没有立刻去猜它装在哪，而是直接用模块提供的方法查真实路径：

1
2

Import-Module PowerShell.MCP
Get-MCPProxyPath

在我的机器上，返回的实际路径是：

1

C:\Users\cy\文档\PowerShell\Modules\PowerShell.MCP\1.7.4\bin\win-x64\PowerShell.MCP.Proxy.exe

这里有一个我觉得很值得记下来的经验：不要凭 README 猜安装路径，也不要手抄一个看起来像的目录。 最稳的方式就是直接取模块返回的真实路径。

因为版本号可能变，安装位置也可能因环境不同而不同。既然模块自己能告诉你答案，就没必要靠猜。

五、Codex 侧怎么配置？

拿到 PowerShell.MCP.Proxy.exe 的真实路径之后，就可以把它加进 Codex 的配置文件了。

我的配置文件是：

1

C:\Users\cy\.codex\config.toml

我往里面追加了这样一段：

1
2
3
4
5

[mcp_servers.powershell]
command = 'C:\Users\cy\文档\PowerShell\Modules\PowerShell.MCP\1.7.4\bin\win-x64\PowerShell.MCP.Proxy.exe'
enabled = true
startup_timeout_sec = 20
tool_timeout_sec = 120

这几个字段可以这样理解：

• mcp_servers.powershell：定义一个名为 powershell 的 MCP Server
• command：告诉 Codex 启动哪个可执行文件
• enabled：是否启用
• startup_timeout_sec：启动超时时间
• tool_timeout_sec：工具调用超时时间

这里还有一个容易被忽视的小点。

有些文档会给出一个“转义后的路径”，方便你粘贴到某些 JSON 配置里；但 Codex 用的是 TOML，通常直接写原始 Windows 路径即可，只要放在引号里就行。

六、怎么确认它真的已经被 Codex 识别了？

只改配置文件还不够，必须做验证。

我这次最重要的验证命令是：

1

codex mcp list

实际看到的结果里，已经能列出 powershell 这个 server，状态是 enabled。这就说明两件事：

1. Codex 成功读到了配置
2. 它把这个 MCP Server 识别成一个可用的本地工具入口

如果你也做这一步，重点关注下面几个字段：

• Name
• Command
• Status

只要 Status 是 enabled，通常就说明主配置已经接好了。

七、配置过程中我踩到的坑

虽然整体过程不算复杂，但还是有几个细节值得单独说。

1. 不要先假设 Codex 一定支持某种写法

很多时候，我们在网上搜到的是 Claude Desktop、Cursor 或其他客户端的示例配置。如果直接照抄，很容易踩坑。

我这次比较稳的做法是：

• 先确认 PowerShell.MCP 仓库 README 的启动方式
• 再确认 Codex 自己支持怎样的 MCP 配置结构
• 最后再拼装最终配置

这个顺序看起来慢一点，但能减少很多无效试错。

2. Windows 路径、编码和转义要小心

我的模块路径里包含中文目录 文档。这说明在 Windows 上做这类配置时，最好实测一次，不要想当然地认为路径一定是纯英文。

如果你的配置工具或命令行环境对编码处理不好，就可能出问题。

好在这次写到 Codex 的 TOML 配置里，直接使用真实路径是可行的。

3. 看到“Unsupported”不一定是错误

codex mcp list 里有一个 Auth 字段。我实际看到的是：

1

Unsupported

刚开始看这个词很容易紧张，以为是接入失败。其实不是。

这里的含义更接近：这个 MCP Server 不是那类需要独立认证流程的服务。 对本地 stdio 型 MCP 来说，这通常是正常现象，不代表不可用。

八、配好以后，它适合拿来做什么？

对新手来说，真正难的往往不是“怎么装”，而是“装好以后该怎么用”。

我觉得，PowerShell.MCP 最适合下面几类事情。

1. 持久终端会话

如果某个任务不是一条命令能解决，而是需要多步执行，那么它会很有用。

比如：

• 先进入某个目录
• 再查文件
• 再搜索内容
• 再跑脚本
• 再根据结果继续处理

这种连续动作非常符合真实开发场景。

2. Windows 系统级操作

对于 Windows 环境，PowerShell 的优势很明显。

例如：

• 查询系统信息
• 管理 PowerShell 模块
• 批量操作文件
• 调整环境变量
• 获取服务状态

如果你平时就已经在用 PowerShell 管理机器，那把这层能力通过 MCP 提供给 Codex，是非常自然的选择。

3. 调用你现有的命令行工具链

如果你的电脑已经像我一样装了一堆命令行增强工具，那 PowerShell.MCP 的价值会放大很多。

它不是替代这些工具，而是把它们串起来。

例如：

• 用 fd 找项目文件
• 用 rg 搜关键字
• 用 bat 预览内容
• 用 jq 过滤 JSON
• 用 git 查状态
• 用 lazygit 做交互式辅助

这时 AI 真正获得的是“组合能力”，不是单工具能力。

九、哪些事情不建议一上来就交给它？

这点必须强调。

PowerShell.MCP 很强，但强也意味着风险高。它不是一个只读搜索器，而是一个可能对系统产生真实影响的入口。

所以我不建议新手一上来就把下面这些操作完全交给 AI：

• 批量删除文件
• 修改系统关键配置
• 装卸软件
• 修改注册表
• 处理密钥、密码、敏感目录
• 大范围扫描个人隐私数据

我倾向于认为，比较稳的策略是：

• 先让 AI 解释它准备执行什么
• 再让它给出命令
• 你看过没问题后再执行

也就是说，在熟悉之前，把它当成“高能力助手”，而不是“全自动管理员”。

十、如果你也是 MCP 新手，我建议按这个顺序入门

这次实际折腾下来，我觉得新手最舒服的路径大概是这样：

第一步：先理解 MCP 不是魔法，而是接口

先建立正确心智模型：MCP 只是“给 AI 接工具”的标准方式，不是装上就自动什么都会。

第二步：只接一个你最需要的 MCP

不要一开始就接十几个 MCP Server。对 Windows 用户来说，先接一个 PowerShell.MCP 已经足够你理解整个流程。

第三步：先验证，再实战

先确认：

• 模块装好了
• 路径拿对了
• config.toml 写对了
• codex mcp list 能看到结果

不要跳过这一步。

第四步：从低风险任务开始用

先让它做查询、列目录、搜文件、看状态、跑只读命令，不要一上来就让它改系统。

十一、我这次的最终结果

这次最终完成的状态是：

• PowerShell.MCP 已成功安装到本机
• 已拿到真实 proxy 路径
• 已写入 C:\Users\cy\.codex\config.toml
• 已通过 codex mcp list 验证，Codex 能识别 powershell 这个 MCP Server

也就是说，从“我完全没用过 MCP”到“Codex 能在本机认出并加载 PowerShell.MCP”，这条链路已经打通了。

对我来说，这件事的价值并不只是“多装了一个工具”，而是：我终于开始把本机环境能力，用一种更标准、更可复用的方式接给 AI。

这一步迈出去之后，后面无论是接更多本地工具、接数据库能力，还是接其他服务，理解成本都会低很多。

十二、总结

如果你和我一样，是在 Windows 上折腾开发环境，又想让 Codex 更自然地调用本机能力，那么 PowerShell.MCP 是一个非常值得尝试的起点。

它的优点在于：

• 足够贴近 Windows 原生环境
• 配置逻辑相对清晰
• 很适合和现有命令行工具链结合
• 能帮助你真正理解 MCP 的工作方式

但也别忘了，它的能力很强，风险也不低。对新手来说，最重要的不是“装上”，而是建立正确的使用边界。

如果后续我再继续折腾更多 MCP，或者把这套 Codex + Windows 命令行工作流打磨得更顺手，我再继续记录。