ask-chat-mcp

一个能让 Claude 直接与 ChatGPT 商议的 MCP 服务器——专才对专才，以实际文件为基础，只读，双向都没有大小限制。

为委派而生，而非为审阅而生。当问题真正具有技术性时——模型背后的数学原理、某个推导是否成立、需要论证权衡的设计——有用的做法是把两个有能力的模型放在一起，让它们报告各自的结论，而不是把每一次交流都转给一个人，再由这个人去裁决一个他/她并不面对的主题。

因此，双方都以完整的技术深度交流。没有人为旁观者降低解释的难度，因为循环中本来就没有旁观者：提问的人之所以委派出去，正是为了不必坐在中间。

flowchart TD
    You([You]) -->|"'Ask Chat'"| Claude[Claude]
    Claude -->|"the problem + file PATHS"| MCP["ask-chat MCP server"]
    MCP -->|"codex exec --sandbox read-only"| Codex[Codex CLI]
    Codex -->|"opens the files itself"| Repo[("your repo, read-only")]
    Codex <-->|"one thread, kept open"| GPT["ChatGPT (your subscription)"]
    GPT -->|"answer + what context it still needs"| Codex
    Codex -->|"full answer, nothing truncated"| MCP
    MCP -->|"arrives as if YOU wrote it"| Claude
    Claude -->|"what Claude makes of it"| You

这张图要说明的三件事：

• 跨越边界的是路径，绝不是文件内容。 ChatGPT 自己打开文件，因此没有需要预算的负载，也没有任何内容会被截断。

• 每一条回复都会说明它仍然需要什么上下文。 补齐这些内容并再次提问是正常路径，而不是错误情形——一个基于沉默假设的自信回答，正是这个设计要防止的失败。

• 回复以你的回合形式返回，而不是一份报告。Claude 会像回答你一样去回答它。

目录

• 为什么不自动化 ChatGPT 桌面应用

• 环境要求

• 安装

• 工具

• 配置

• 设计说明

• 局限

为什么不自动化 ChatGPT 桌面应用

显而易见的做法——驱动桌面应用的窗口、粘贴提示词、抓取回复——正是这个领域里那些知名 MCP 服务器所做的。但这对这个用例来说是一条死路，值得明确说明原因，因为这些原因在真正构建之前并不明显：

• 提示词有一个实际的上限。 它通过剪贴板粘贴进入输入框，大段粘贴会被静默截断。大约 12k 字符是安全预算。这不足以容纳一个真正的问题加上它所依赖的文档。

• 回复同样会被截断，而且更糟糕的是，截断是隐形的。 它必须从应用的可访问性树中读回，而虚拟化的滚动容器不会把屏幕外的内容保留在那里。长回答回来时是不完整的，而且没有任何迹象表明它被截断了。

• 它会占据你的屏幕。 窗口必须被聚焦，击键会被发送给它。运行时你无法打字，而且一次只能调用一个，这是硬性限制。

• 它会在 UI 变化时崩溃，因为渲染出来的可访问性树并不是任何人承诺要保持稳定的接口。

改用 Codex CLI 可以同时消除这四点。它以无头模式运行，直接从磁盘读取文件，并在 stdout 上返回答案。关键在于，它使用 ChatGPT 订阅进行身份验证，所以这不是按 token 计费的 OpenAI API——而是你已经付费的计划。

环境要求

• Node.js 18+

• Codex CLI，已用你的 ChatGPT 账户登录：

npm install -g @openai/codex
codex login          # choose "Sign in with ChatGPT"

安装

git clone https://github.com/spe-investigator/ask-chat-mcp.git c:\src\ask-chat-mcp
cd c:\src\ask-chat-mcp
.\install.ps1 -DefaultCwd c:\src\YourProject

install.ps1 会验证前置条件、执行构建、报告 Codex 是否已安装并登录，以及向 Claude Code 注册服务器。它是幂等的——拉取更新后可以重新运行。

重启 Claude Code，并用 /mcp 确认。

工具

ask_chatgpt

传递路径，而不是内容。 这正是关键所在：没有需要花掉的负载预算，所以发送实际文件即可。

files 是一个指针，而非白名单。它表示从这里开始；ChatGPT 可以在 cwd 内打开它需要的任何其他内容，并且会在这么做时告诉你。因此，不完整的列表会优雅地降级，而不是产生错误的答案——cwd 才是真正的边界。

线程

默认情况下，会话中的第一次调用会启动一个 Codex 线程，而之后的每次调用都会延续它，因此 ChatGPT 会保留你已讨论内容的上下文，而不是冷冰冰地面对每个问题。

会话边界就是服务器进程。MCP 客户端会为每个会话生成一个 stdio 服务器，因此线程保存在内存中，不需要按仓库或客户端注册表：新会话以干净状态开始，两个并发会话会获得独立的线程，而不是互相踩踏一个共享线程。

last 是按目录限定的，因为除非另行指定，Codex 会按工作目录过滤记录的会话。

chatgpt_status

报告 Codex 是否已安装并登录，以及此会话当前位于哪个线程。在依赖 ask_chatgpt 之前先检查它，也可以用它来解释失败而无需猜测。

配置

设计说明

只读。 Codex 是一个可以编辑文件的编码代理。一个能够改写你工作树的咨询专家是负担，而不是特性。codex exec 本身已经默认使用只读沙箱，而在新线程上还会显式传入 --sandbox read-only，因此这一保证不依赖于某个默认值保持不变。在恢复的线程上该标志不可用——见下文。

每条回复都会报告自身的充分性。 提示词要求 ChatGPT 明确说明它收到的上下文是否足够，精确指出它仍然想要什么——一个文件、一个定义、一项测量结果、一个约束——并标出回答的哪些部分建立在它不得不做的假设之上。这比听上去更重要：一个简报良好的模型的失败模式不是拒绝回答，而是围绕一个没人知道存在的缺口自信作答。指出这个缺口会让下一次调用变得轻而易举，因为补充一个文件只需一个路径。

没有哪个标志是凭信仰传入的。 已安装的构建会被探测一次，只有它在广告中声明支持的可选标志才会被使用。Codex 发展很快；猜测它的接口只会让这个项目变得脆弱，毫无收益。

exec 和 exec resume 是分开探测的，因为它们接受的选项不同——resume 会直接拒绝 --sandbox 和 --cd。假设两者共用同一套标志，调用就会死在参数解析阶段，而不是做任何实际工作——这个问题就是这样被发现的。因此，在恢复的线程上，只读保证依赖于 codex exec 的默认值加上线程创建时所采用的政策，而不是第二个显式标志；工作目录无论如何都来自被生成的进程。

两个方向都没有长度限制。 提示词通过 stdin 使用 codex exec - 传入，因此它绝不会接触到命令行，也不会撞上约 32k 的参数上限。答案通过 --output-last-message 返回，从文件中读取，而不是从同时携带进度输出的流中解析出来。进度信息进入 stderr，并保留用于诊断。

Windows shim 处理。 npm 将 codex 安装为 .cmd shim，而自 2024 年的参数注入修复以来，Node 拒绝直接生成它。失败的直接生成会改为通过 shell 重试。由于提示词经由 stdin 而非 argv 传输，这种重试对于唯一一个任意文本输入来说不会带来引号转义风险。

局限

• Codex 必须已登录。 codex login 是一个交互式浏览器流程；它无法被自动化，chatgpt_status 会在登录失效时告诉你。

• 文件访问被限制在 cwd 内。 这是有意为之。把它指向你想要审查的仓库根目录即可。

• 它并不快。 一个针对真实文件的有实质内容的回答需要几十秒。默认超时是五分钟。

• 线程随会话生死。 重启客户端会开启一个新线程。session: "last" 可以拾取前一个线程，但没有先前线程的列表可供选择。

• 线程在 ChatGPT 中不可见。 Codex 将它们以 JSONL 格式记录在 ~/.codex/sessions/ 下；它们不会出现在 ChatGPT 侧边栏或 Projects 中。这个设计的任何部分都无法改变这一点（openai/codex#21079）。