昨天在使用windbg Pre的时候突然发现工具栏顶部多了几个按钮，是接入MCP的更新版本，但是在使用的时候发现需要安装VSCODE，并且windbg是通过VSCode内置的ai引擎来实现对话的，这对一个习惯了使用CLI的人无法接受，于是就进行了手操，让他支持了本地的codex CLI：利用 WinDbg 自带的 MCP 代理，让本地 Codex CLI 发现调试会话、读取目标状态并调用调试工具；在此基础上，用脚本实现点击 WinDbg 的“Install MCP”按钮启动 Codex，以及 WinDbg 重启后自动打开 Codex。

整个方案使用 WinDbg 已有的 Custom 客户端配置、stdio MCP 和 Windows UI Automation。最终部署没有修改 WinDbg 的 EXE、DLL 或 Windows 协议处理程序。

本文中的“本地 Codex”指运行在本机的 Codex 客户端，不表示模型推理一定在本地完成。调试输出可能随 Codex 请求发送到其配置的模型服务。

对话输入与回答显示在独立的 Codex 终端。WinDbg 负责调试、提供工具并展示执行结果；本文没有给 WinDbg 增加内嵌聊天面板。

配置完成后，可以采用以下任一种方式工作：

连接成功后，在 Codex 中输入自然语言，例如：

Codex 会通过 MCP 调用 WinDbg 工具。后续可以在明确目标状态后，继续请求调用栈、模块、寄存器、断点及当前停止位置分析。

本次实测环境如下。它们是验证基线，不应理解为所有未来版本的固定要求。

注意：截至本文整理时，Microsoft 文档列出的正式支持客户端是 VS Code with GitHub Copilot 和 GitHub Copilot CLI；其他兼容 MCP 的客户端通过自定义配置尝试接入。本文验证的是 Codex 的具体接入结果，并不将其描述为 Microsoft 官方保证的完整兼容方案。

WinDbg 默认的“Install MCP”按钮容易让人误以为，AI 调试必须依赖 VS Code。实际上，按钮负责的是向选定客户端安装连接配置；调试能力由 WinDbg 自身提供。

本次对目标版本的静态分析发现，主要逻辑集中在 DbgX.Mcp.dll：

选择 VS Code 时，安装入口类似：

它携带的核心配置是标准 stdio MCP 服务器定义：

这份定义可以转换为 Codex 的 MCP 配置。通信关系如下：

Microsoft 文档也说明了“AI 客户端 → stdio 代理 → 每个 WinDbg 进程的命名管道”这一架构。因此，配置 Codex 的关键是复用代理，而非模拟 VS Code 的全部行为。来源：WinDbg MCP overview

以下操作在 Windows PowerShell 中执行。

先确认 WinDbg 安装情况，以及代理执行别名是否存在：

Microsoft 的设置文档要求支持 MCP 的 WinDbg 版本；当前文档给出的起点是 1.2610.1001.0。实际配置时还应确认安装包内有代理，并且界面能找到 MCP 设置。来源：Set up and use WinDbg MCP

本方案优先使用包族执行别名。它的路径不包含具体 WinDbg 版本号，便于应用更新后继续定位；如果该别名不可用，启动脚本会尝试从当前包的安装目录查找代理。

然后检查 Codex：

若你的 Codex 是直接安装的 codex.exe，后两条命令相应替换为 codex.exe。本文脚本会优先查找 codex.cmd，再查找 codex.exe。

确认普通 Codex 会话已经能够正常启动和使用已有登录。MCP 负责工具连接，不会替用户完成模型服务的认证。

本文使用 Windows 原生 Codex。若把客户端放在 WSL 内，Windows 执行别名、命名管道、路径转换和权限继承都需要另行验证，不能直接照搬这里的运行结果。

文章配套文件夹 WinDbgCodex 包含实际使用的脚本：

文件职责如下：

建议将整个文件夹复制到固定的可写目录，例如：

复制完成后检查：

本机首次实测时，脚本位于 %TEMP%\WinDbgCodex。该目录适合临时验证，长期使用建议复制到固定位置，并同步更新后面填写的 Custom 命令。不要移动仍被后台监听器使用的目录。

脚本使用 $PSScriptRoot 查找配套文件，所以源码中的绝对用户名不需要修改。首次正式启动时，会在脚本目录下创建 Workspace，作为 Codex 的工作目录。

启动器需要完成三件事：找到 WinDbg 代理、构造 Codex 的 stdio MCP 配置、启动交互式 Codex。

本文通过 -c 给新会话注入名为 windbg_local 的 MCP 服务器。Codex 官方文档支持 stdio 服务器，也支持在 config.toml 中保存配置；这里采用会话参数，便于独立测试和撤销。来源：Codex MCP

配套的完整 Launch-WinDbgCodex.ps1 如下：

这段脚本有几个与实际部署有关的细节：

代理在这里使用默认参数 args=[]。不要仅为“固定窗口”随手增加 --pid：本次版本的 IL 显示，PID 选择与 -relay 分支相关；默认合并模式仍应通过会话工具选择目标。

先做配置解析检查：

预期返回的关键字段是：

再实际启动：

也可以双击目录中的 Launch-WinDbgCodex.cmd。

这里使用的 -ExecutionPolicy Bypass 只作用于新启动的 PowerShell 进程，脚本没有修改机器级执行策略。若本机存在强制执行策略、AppLocker 或 WDAC 限制，仍应遵循本机允许的脚本运行方式。

这一步的成功标准是看到 Codex 交互界面，并能输入命令。此时尚未要求 WinDbg 加载调试目标。

在 WinDbg 中打开：

启用 Enable Server，将 Client 设为 Custom。

在 Custom client command 中填写：

可在 PowerShell 中生成本机对应的完整命令，复制输出后填入 WinDbg：

本次版本的客户端启动逻辑按第一个空格分离可执行文件和参数。因而首项使用不带空格的 powershell.exe；带空格的脚本路径放进 -File 参数并加双引号。不要把一个带空格的 PowerShell 安装路径直接放在首项，假定其解析器一定能正确识别。

点击 OK 应用设置后，再执行：

这是本次部署中容易遗漏的一步：设置已经在当前窗口生效，并不等于已经落盘。本机的自动保存处于关闭状态，应用设置后，磁盘配置仍是旧内容；执行“Save workspace”后，才读回了新的 Custom 命令。

本次商店版默认配置位于：

可只读验证对应节点：

应能看到类似内容：

如果使用其他工作区，先确认当前窗口实际加载与保存的设置位置。优先通过应用界面修改；运行中的 WinDbg 可能在保存工作区时覆盖外部直接编辑的 XML。

在 WinDbg 的 MCP 控件中启用 MCP Service。首次启动可能显示隐私与安全确认。按当前调试环境确认启动，并保留已有的 Secure Mode、Cross Prompt Injection Mitigation 设置。

Enable Server 是功能设置，MCP Service 是当前进程的服务运行状态。这两个状态不能混为一谈。启用了功能，但未启动当前会话的服务时，Codex 仍可能连上代理，却找不到可用 WinDbg 会话。

普通权限下，可以点击 Open Chat 使用刚配置的 Custom 命令。在本次管理员模式的 WinDbg 中，Open Chat 被程序自身禁用；此时可先手动运行启动器，或使用下一节的监听脚本。提权的 WinDbg 命名管道需要具备相应访问权限的客户端，不能仅凭窗口都属于同一用户名判断一定可访问。

连接分三层检查：

在 Codex 终端中输入：

本次实际界面显示：

工具数量与 WinDbg 版本、代理模式、上游会话连接情况有关，不应把“必须恰好 15 个”设为通用判断条件。

继续输入：

只有一个可用 WinDbg 会话时，默认代理会尝试自动连接。多个会话时，应明确选择，再调用 connect_session。这是 WinDbg 官方会话管理方式。来源：Set up and use WinDbg MCP

本次真实协议测试完成了：

代理返回了工具清单和已连接的 WinDbg 会话，随后 Codex 自身的 /mcp 也显示连接成功。这比仅看到一个 Codex 新进程更能说明链路已经打通。

Custom 配置本身不会改变“Install MCP”的全部行为。在本次版本中，各客户端的安装行为如下：

因此，若只做前面几步，Custom 下的“Install MCP”仍只复制配置。点击后启动 Codex，是由配套监听器额外完成的。

监听器使用 Windows UI Automation 订阅指定 WinDbg 窗口子树中的 InvokePattern.InvokedEvent。事件到来后，检查控件名称是否为 Install MCP；匹配则把对应进程 ID 放入队列，由 PowerShell 循环启动 Codex。

主流程：

启动方式：

若 WinDbg 是管理员进程，应在管理员 PowerShell 中运行此命令，使监听器和其启动的 Codex 能访问目标窗口与 MCP 管道。该脚本本身不会自动申请提权。

然后点击 WinDbg 中的 Install MCP。本次实测日志中出现了 install-click，并实际打开了可操作的 Codex 窗口。

原有 JSON 复制动作仍然执行，所以同时出现“配置已复制”的通知是正常现象。这里没有把按钮的程序代码改成 Codex，而是在现有按钮事件之后补上启动动作。

此监听器依赖目标版本的控件名称和 UI Automation 行为。语言或界面版本改变后，可能需要调整匹配条件；它不是 Microsoft 提供的 Codex 集成接口。

保持监听器运行，然后正常关闭、重新启动 WinDbg。

监听器发现新的进程和窗口后，会在约 4 秒后启动新的 Codex 终端。这个等待时间只用于给窗口完成初始化，不表示调试目标或 MCP 服务已经就绪。

本次用户实际重启后，确认看到了自动出现的 Codex 窗口。进入新窗口后，仍应检查 MCP 服务和会话选择；重启会改变 WinDbg PID，不能复用上一轮记下的 PID。

多窗口情况下还有一个边界：监听器知道是哪一个 WinDbg 触发启动，但当前启动器没有把该 PID 锁定到代理。多个 WinDbg 窗口并存时，务必通过 list_sessions / connect_session 核对目标。

若旧 Codex 仍在运行，它可能保留旧 MCP 会话。新的 WinDbg 进程、旧代理和新 Codex 窗口之间的对应关系，应以新一轮的工具结果为准。

配置完成后的操作分工很明确：