openinterpreterCodexMCP Server 接口深度解析用 JSON-RPC 与 MCP 标准传输控制本地 Codex 引擎【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter本文基于仓库中的 codex_mcp_interface.md 原文档展开系统讲解 Codex 实验性 MCP Server 接口它以标准 Model Context ProtocolMCPstdio 传输承载 JSON-RPC 2.0 协议用于从任意 MCP 客户端控制本地 Codex 引擎管理线程thread、轮次turn、账号、配置与审批。读完本文你将能够启动该 MCP 服务、理解其线程/轮次对象模型、订阅实时事件流、处理服务端发起的审批请求并掌握codex/codex-reply两个核心工具的参数结构同时了解接口背后的 Rust 实现调用链与稳定性边界。一、接口定位实验性状态与基本形态原始文档在开头就明确了三个关键事实状态experimental接口可能随时变更不保证向后兼容服务二进制codex mcp-server或独立的codex-mcp-server可执行文件传输标准 MCP over stdio即 JSON-RPC 2.0 行分隔line-delimited编码。从源码结构看这个接口与 Codex 的app-server共用同一套协议类型文档指出类型定义位于 protocol 目录common、v1、v2等文件由 app-server 的实现消费。MCP Server 本身则是独立的 crate入口在 mcp-server/src/main.rs它通过arg0_dispatch_or_else支持二进制被重命名分发如codex或codex-mcp-server两种调用形态最终都调用 lib.rs 中的run_main启动服务。二、启动 MCP 服务器并接入客户端文档给出的标准接入方式是管道连接任意 MCP 客户端codex mcp-server | your_mcp_client对于交互式排查文档推荐官方 Inspector 工具npx modelcontextprotocol/inspector codex mcp-server此外要注意区分两个容易混淆的入口codex mcp-server是把 Codex 自身作为 MCP 服务器暴露而codex mcp子命令是用于管理在config.toml中配置的、由 Codex 去启动的第三方 MCP server launcher。两者方向相反。2.1 底层事件循环三个并发任务run_main在 lib.rs 中构建了典型的三任务管道这解释了为什么传输必须基于行分隔 JSONstdin 读取任务用BufReader按行读取标准输入每行反序列化为一条 JSON-RPC 消息放入容量为CHANNEL_CAPACITY 128的有界 channel注释说明这是吞吐与内存的折中对交互式 CLI 足够消息处理任务MessageProcessor定义于 message_processor.rs消费消息按 Request / Response / Notification / Error 四类分发处理stdout 写入任务把OutgoingMessage序列化为 JSON 字符串并追加换行符写出——这正是line-delimited约定的实现位置。典型退出路径是 stdin 读到 EOFincoming_tx被 dropshutdown 依次传播到 processor 与 stdout 任务最后由tokio::join!汇合退出。初始化阶段还会完成配置构建支持-cCLI 覆盖strict_config在 mcp-server 场景下为false、认证配置校验、OTel 遥测初始化服务名codex_mcp_server、状态库state_db初始化以及EnvironmentManager构建。MessageProcessor内部持有ThreadManager会话来源标记为SessionSource::Mcp、ActiveTurnRegistry与出站消息发送器并安装了 git attribution、image generation、skills 等扩展。2.2 initialize 握手一次且仅一次MCP 客户端连接后必须先发送initialize。handle_initialize的行为见 message_processor.rs重复调用会返回invalid request: initialize called more than once错误客户端的clientInfo.name与version会被拼接成 user-agent 后缀用于向模型后端标识调用方响应中serverInfo为codex-mcp-server 当前包版本标题Codex并额外保留一个非规范字段serverInfo.user_agent能力声明为toolstoolListChanged。三、线程与轮次v2 API 是新的集成面文档明确要求所有新集成应使用 v2 的 thread/turn API。完整方法一览thread/start、thread/resume、thread/fork、thread/read、thread/listturn/start、turn/steer、turn/interruptaccount/read、account/login/start、account/login/cancel、account/logout、account/rateLimits/readconfig/read、config/value/write、config/batchWritemodel/list、app/list、collaborationMode/list语义上thread/start创建线程turn/start提交用户输入turn/interrupt中断进行中的轮次thread/list/thread/read暴露持久化历史。兼容层方面getConversationSummary仍保留给需要按conversationId或rolloutPath查摘要的老客户端文档特别提示优先用conversationId查询因为按rolloutPath的查询在非本地 thread store 下不可用。完整的请求/响应形状文档指向 app-server 的 README 与 v2.rs 中的协议定义app-server/README.md 中对 Thread / Turn / Item 三个核心原语有更完整的描述线程包含多个轮次轮次由用户消息开始、以 agent 消息结束并包含多个 item。从 MCP Server 的实现看它把客户端请求收敛为 MCP 标准方法面initialize、ping、tools/list、tools/call以及资源/提示相关方法的占位实现当前仅打日志未识别的方法统一返回 JSON-RPCmethod not found错误。而客户端的notifications/cancelled通知会被解析为中断操作通过ActiveTurnRegistry用请求 id 找到对应 thread再向 Codex 提交Op::Interrupt见 message_processor.rs这正是文档所述stop an in-flight turn能力在 MCP 传输上的落点。四、模型目录model/listmodel/list返回当前 Codex 构建可用的模型目录支持可选分页limit返回数量上限缺省由服务端决定cursor上一页响应中的nextCursor不透明字符串。响应结构data有序模型列表。每个模型包含id、model、displayName、descriptionsupportedReasoningEfforts对象数组每项含reasoningEffort模型自身声明的字符串值常见取值none|minimal|low|medium|high|xhigh与description面向人类的标签defaultReasoningEffort给 UI 的建议档位inputModalities模型可接受的输入类型supportsPersonality是否支持个性指令isDefault是否为多数用户的推荐模型upgrade可选的推荐升级模型 idupgradeInfo可选的升级元数据含model升级目标 id、upgradeCopy展示文案、modelLink升级链接、migrationMarkdown展示升级建议时的 Markdown。nextCursor翻页游标可选。app-server README 中对该方法的补充值得注意客户端应保留supportedReasoningEfforts数组的原始顺序而不是从档位名称自行推导顺序还可传includeHidden: true显示hidden: true的条目。五、协作模式collaborationMode/list实验性该端点不接受分页一次返回全部内置协作模式预设。响应要点data有序的 collaboration mode mask叠加在基础模式之上的部分设置对reasoning_effort、developer_instructions这类三态字段省略字段表示保持当前值置null表示清空设置具体值表示更新内置预设不设置model其中 Plan 预设将reasoning_effort设为 medium模型选择由客户端自行保持或覆盖。与turn/start配合的规则当collaborationMode携带settings.developer_instructions: null时含义是使用所选模式内置的指令而不是清空指令。六、事件流codex/event通知会话运行期间服务端持续推送通知codex/event载荷是序列化后的 Codex 事件其形状与 core/src/protocol.rs 中的Event/EventMsg类型一致部分通知带_meta.requestId用于与发起它的请求做关联fuzzyFileSearch/sessionUpdated、fuzzyFileSearch/sessionCompleted遗留模糊搜索流的进度通知。客户端应渲染这些事件并在出现审批请求时将其呈现给用户见下节。实现层面outgoing_message.rs 的send_event_as_notification把事件包进 params并在OutgoingNotificationMeta中附加 MCP 规范允许_meta字段requestId可选与threadId可选。后者存在的动机是同一 MCP 连接上可能多路复用多个线程threadId让客户端能把事件路由到正确的会话。同文件的单元测试如test_send_event_as_notification_with_meta_and_thread_id固化了线上的精确形状包括jsonrpc:2.0、_meta.requestId以及msg.type: session_configured等字段。七、工具调用codex与codex-replyMCP 工具面由tools/list暴露两个工具参数结构在 codex_tool_config.rs 中定义并有逐字段固化的 JSON Schema 测试verify_codex_tool_json_schema、verify_codex_tool_reply_json_schema作为可执行文档codex启动新会话参数kebab-casedeny_unknown_fields字段说明prompt必填初始用户提示词model可选覆盖模型名如gpt-5.2、gpt-5.2-codexcwd可选会话工作目录相对路径按服务进程 cwd 解析approval-policy可选枚举untrusted/on-request/neversandbox可选枚举read-only/workspace-write/danger-full-accessconfig可选对象逐项覆盖CODEX_HOME/config.toml中的配置base-instructions可选替换默认指令集developer-instructions可选以 developer 角色注入的指令compact-prompt可选压缩会话时使用的提示词codex-reply继续既有会话参数字段说明threadId会话线程 id逻辑上必填字段本身保留可选以兼容老客户端conversationId已废弃为向后兼容仍接受prompt必填下一轮用户提示词get_thread_id的解析顺序是优先threadId缺失时回退conversationId两者皆无则报错。7.1 响应形状content 与 structuredContent 双轨两个工具返回标准 MCPCallToolResult。为兼容偏好structuredContent的客户端Codex 会把内容块在structuredContent中镜像一份并附带threadId。文档给出的示例{ content: [{ type: text, text: Hello from Codex }], structuredContent: { threadId: 019bbed6-1e9e-7f31-984c-a05b65045719, content: Hello from Codex } }工具定义中声明的outputSchema恰为{ threadId: string, content: string }且两者均 required与该示例严格一致。另外注意历史线形兼容细节outgoing_message.rs 在序列化响应时会移除 rmcp 新增的resultType字段以保持老客户端认识的历史线形{ content: [...], isError: false }该行为有专门的回归测试锁定。7.2 调用执行链路tools/call的处理在 message_processor.rs按工具名路由到codexhandle_tool_call_codex或codex-replyhandle_tool_call_codex_session_replycodex分支把参数反序列化为CodexToolCallParam经into_config生成有效Config其中approval_policy、sandbox枚举通过From实现映射到核心协议类型config字段经json_to_toml转换后作为 CLI 覆盖参与配置分层随后 spawn 独立异步任务执行会话避免阻塞消息处理主循环codex-reply分支先校验会话存在性不存在则返回带threadId的错误CallToolResult同样在独立任务中继续会话配置解析失败、缺prompt等错误都以工具错误结果文本 content形式返回而非 JSON-RPC 协议错误。八、审批服务端到客户端的反向请求当 Codex 需要批准应用变更或执行命令时服务端向客户端发起 JSON-RPC请求方向与工具调用相反文档列出的两个请求applyPatchApproval { conversationId, callId, fileChanges, reason?, grantRoot? }execCommandApproval { conversationId, callId, approvalId?, command, cwd, reason? }客户端对每个请求必须回复{ decision: allow | deny }。这两个 RPC 名可以在 app-server 协议 schema 中确认见 ServerRequest.json。而在 MCP Server 的当前 Rust 实现中审批是通过 MCP 规范的elicitation/create请求承载的参数中带codex_elicitation字段区分类型命令审批exec_approval.rscodex_elicitation: exec-approval附带codex_command命令 token 数组、codex_cwd、codex_parsed_cmd解析后的命令结构、codex_call_id、codex_event_id等关联字段提示语形如 Allow Codex to run\cmdincwd?;补丁审批patch_approval.rscodex_elicitation: patch-approval附带codex_changes文件 → 变更的映射、可选codex_reason与codex_grant_root。客户端响应体统一为{ decision }其中decision是ReviewDecisionallow/deny 及理由。两条关键实现细节体现了防御性设计响应在独立 tokio 任务中等待不会阻塞主 agent 循环客户端响应反序列化失败、或 oneshot 通道异常时实现会保守地以denied(approval request failed)提交决策——即解析失败即拒绝审批权永远偏向安全侧。决策最终通过Op::ExecApproval/Op::PatchApproval提交回 Codex 线程把客户端的人类决策接回引擎主循环。九、Auth 辅助端点文档将账号相关的完整请求/响应形状与流程示例委托给 app-server README 的 Auth endpoints (v2) 一节即 codex-rs/app-server/README.md。MCP 侧对应的方法面是account/read、account/login/start、account/login/cancel、account/logout、account/rateLimits/read。集成登录流程时应以该节为准。十、v1 遗留兼容方法为存量 app 客户端服务端仍接受一个窄化的 v1 兼容面getConversationSummarygetAuthStatusgitDiffToRemotefuzzyFileSearch、fuzzyFileSearch/sessionStart、fuzzyFileSearch/sessionUpdate、fuzzyFileSearch/sessionStop这些方法与事件流中的fuzzyFileSearch/sessionUpdated、fuzzyFileSearch/sessionCompleted通知共同构成遗留模糊搜索流程。新集成不应依赖它们。十一、兼容性与稳定性边界接口处于实验阶段方法名、字段与事件形状都可能演进。要获得权威 schema应直接查阅类型定义app-server-protocol/src/protocol 下的common、v1、v2文件v2 进一步拆分为 account.rs、model.rs、thread.rs、turn.rs、collaboration_mode.rs、config.rs、notification.rs 等模块服务端接线app-server/ 目录MCP Server 实现细节与回归测试mcp-server/src 及 mcp-server/tests其中codex_tool.rs套件配合 mock 模型服务器做端到端验证。十二、集成者清单Checklist以codex mcp-server启动服务通过 stdio 接入 MCP 客户端先完成initialize握手重复初始化会被拒绝新集成一律走 v2 的thread/*与turn/*方法仅当必须兼容旧客户端时才使用getConversationSummary等 v1 方法持续消费codex/event通知渲染进度用_meta.requestId/_meta.threadId把事件归属到具体请求与线程实现elicitation/createexec-approval / patch-approval的应答逻辑响应体为{ decision }在无法解析客户端响应时按实现约定视为 deny用model/list拉模型目录保留supportedReasoningEfforts顺序、用nextCursor翻页用collaborationMode/list拉协作模式预设三态字段省略/null/具体值各有语义用codex/codex-reply工具调用会话时按 kebab-case 参数表传参并预期content与structuredContent双份输出含threadId因接口实验性锁定协议版本以所使用 Codex 构建对应的app-server-protocol源文件为准不要跨版本假设字段稳定。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
openinterpreter（Codex）MCP Server 接口深度解析：用 JSON-RPC 与 MCP 标准传输控制本地 Codex 引擎
openinterpreterCodexMCP Server 接口深度解析用 JSON-RPC 与 MCP 标准传输控制本地 Codex 引擎【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter本文基于仓库中的 codex_mcp_interface.md 原文档展开系统讲解 Codex 实验性 MCP Server 接口它以标准 Model Context ProtocolMCPstdio 传输承载 JSON-RPC 2.0 协议用于从任意 MCP 客户端控制本地 Codex 引擎管理线程thread、轮次turn、账号、配置与审批。读完本文你将能够启动该 MCP 服务、理解其线程/轮次对象模型、订阅实时事件流、处理服务端发起的审批请求并掌握codex/codex-reply两个核心工具的参数结构同时了解接口背后的 Rust 实现调用链与稳定性边界。一、接口定位实验性状态与基本形态原始文档在开头就明确了三个关键事实状态experimental接口可能随时变更不保证向后兼容服务二进制codex mcp-server或独立的codex-mcp-server可执行文件传输标准 MCP over stdio即 JSON-RPC 2.0 行分隔line-delimited编码。从源码结构看这个接口与 Codex 的app-server共用同一套协议类型文档指出类型定义位于 protocol 目录common、v1、v2等文件由 app-server 的实现消费。MCP Server 本身则是独立的 crate入口在 mcp-server/src/main.rs它通过arg0_dispatch_or_else支持二进制被重命名分发如codex或codex-mcp-server两种调用形态最终都调用 lib.rs 中的run_main启动服务。二、启动 MCP 服务器并接入客户端文档给出的标准接入方式是管道连接任意 MCP 客户端codex mcp-server | your_mcp_client对于交互式排查文档推荐官方 Inspector 工具npx modelcontextprotocol/inspector codex mcp-server此外要注意区分两个容易混淆的入口codex mcp-server是把 Codex 自身作为 MCP 服务器暴露而codex mcp子命令是用于管理在config.toml中配置的、由 Codex 去启动的第三方 MCP server launcher。两者方向相反。2.1 底层事件循环三个并发任务run_main在 lib.rs 中构建了典型的三任务管道这解释了为什么传输必须基于行分隔 JSONstdin 读取任务用BufReader按行读取标准输入每行反序列化为一条 JSON-RPC 消息放入容量为CHANNEL_CAPACITY 128的有界 channel注释说明这是吞吐与内存的折中对交互式 CLI 足够消息处理任务MessageProcessor定义于 message_processor.rs消费消息按 Request / Response / Notification / Error 四类分发处理stdout 写入任务把OutgoingMessage序列化为 JSON 字符串并追加换行符写出——这正是line-delimited约定的实现位置。典型退出路径是 stdin 读到 EOFincoming_tx被 dropshutdown 依次传播到 processor 与 stdout 任务最后由tokio::join!汇合退出。初始化阶段还会完成配置构建支持-cCLI 覆盖strict_config在 mcp-server 场景下为false、认证配置校验、OTel 遥测初始化服务名codex_mcp_server、状态库state_db初始化以及EnvironmentManager构建。MessageProcessor内部持有ThreadManager会话来源标记为SessionSource::Mcp、ActiveTurnRegistry与出站消息发送器并安装了 git attribution、image generation、skills 等扩展。2.2 initialize 握手一次且仅一次MCP 客户端连接后必须先发送initialize。handle_initialize的行为见 message_processor.rs重复调用会返回invalid request: initialize called more than once错误客户端的clientInfo.name与version会被拼接成 user-agent 后缀用于向模型后端标识调用方响应中serverInfo为codex-mcp-server 当前包版本标题Codex并额外保留一个非规范字段serverInfo.user_agent能力声明为toolstoolListChanged。三、线程与轮次v2 API 是新的集成面文档明确要求所有新集成应使用 v2 的 thread/turn API。完整方法一览thread/start、thread/resume、thread/fork、thread/read、thread/listturn/start、turn/steer、turn/interruptaccount/read、account/login/start、account/login/cancel、account/logout、account/rateLimits/readconfig/read、config/value/write、config/batchWritemodel/list、app/list、collaborationMode/list语义上thread/start创建线程turn/start提交用户输入turn/interrupt中断进行中的轮次thread/list/thread/read暴露持久化历史。兼容层方面getConversationSummary仍保留给需要按conversationId或rolloutPath查摘要的老客户端文档特别提示优先用conversationId查询因为按rolloutPath的查询在非本地 thread store 下不可用。完整的请求/响应形状文档指向 app-server 的 README 与 v2.rs 中的协议定义app-server/README.md 中对 Thread / Turn / Item 三个核心原语有更完整的描述线程包含多个轮次轮次由用户消息开始、以 agent 消息结束并包含多个 item。从 MCP Server 的实现看它把客户端请求收敛为 MCP 标准方法面initialize、ping、tools/list、tools/call以及资源/提示相关方法的占位实现当前仅打日志未识别的方法统一返回 JSON-RPCmethod not found错误。而客户端的notifications/cancelled通知会被解析为中断操作通过ActiveTurnRegistry用请求 id 找到对应 thread再向 Codex 提交Op::Interrupt见 message_processor.rs这正是文档所述stop an in-flight turn能力在 MCP 传输上的落点。四、模型目录model/listmodel/list返回当前 Codex 构建可用的模型目录支持可选分页limit返回数量上限缺省由服务端决定cursor上一页响应中的nextCursor不透明字符串。响应结构data有序模型列表。每个模型包含id、model、displayName、descriptionsupportedReasoningEfforts对象数组每项含reasoningEffort模型自身声明的字符串值常见取值none|minimal|low|medium|high|xhigh与description面向人类的标签defaultReasoningEffort给 UI 的建议档位inputModalities模型可接受的输入类型supportsPersonality是否支持个性指令isDefault是否为多数用户的推荐模型upgrade可选的推荐升级模型 idupgradeInfo可选的升级元数据含model升级目标 id、upgradeCopy展示文案、modelLink升级链接、migrationMarkdown展示升级建议时的 Markdown。nextCursor翻页游标可选。app-server README 中对该方法的补充值得注意客户端应保留supportedReasoningEfforts数组的原始顺序而不是从档位名称自行推导顺序还可传includeHidden: true显示hidden: true的条目。五、协作模式collaborationMode/list实验性该端点不接受分页一次返回全部内置协作模式预设。响应要点data有序的 collaboration mode mask叠加在基础模式之上的部分设置对reasoning_effort、developer_instructions这类三态字段省略字段表示保持当前值置null表示清空设置具体值表示更新内置预设不设置model其中 Plan 预设将reasoning_effort设为 medium模型选择由客户端自行保持或覆盖。与turn/start配合的规则当collaborationMode携带settings.developer_instructions: null时含义是使用所选模式内置的指令而不是清空指令。六、事件流codex/event通知会话运行期间服务端持续推送通知codex/event载荷是序列化后的 Codex 事件其形状与 core/src/protocol.rs 中的Event/EventMsg类型一致部分通知带_meta.requestId用于与发起它的请求做关联fuzzyFileSearch/sessionUpdated、fuzzyFileSearch/sessionCompleted遗留模糊搜索流的进度通知。客户端应渲染这些事件并在出现审批请求时将其呈现给用户见下节。实现层面outgoing_message.rs 的send_event_as_notification把事件包进 params并在OutgoingNotificationMeta中附加 MCP 规范允许_meta字段requestId可选与threadId可选。后者存在的动机是同一 MCP 连接上可能多路复用多个线程threadId让客户端能把事件路由到正确的会话。同文件的单元测试如test_send_event_as_notification_with_meta_and_thread_id固化了线上的精确形状包括jsonrpc:2.0、_meta.requestId以及msg.type: session_configured等字段。七、工具调用codex与codex-replyMCP 工具面由tools/list暴露两个工具参数结构在 codex_tool_config.rs 中定义并有逐字段固化的 JSON Schema 测试verify_codex_tool_json_schema、verify_codex_tool_reply_json_schema作为可执行文档codex启动新会话参数kebab-casedeny_unknown_fields字段说明prompt必填初始用户提示词model可选覆盖模型名如gpt-5.2、gpt-5.2-codexcwd可选会话工作目录相对路径按服务进程 cwd 解析approval-policy可选枚举untrusted/on-request/neversandbox可选枚举read-only/workspace-write/danger-full-accessconfig可选对象逐项覆盖CODEX_HOME/config.toml中的配置base-instructions可选替换默认指令集developer-instructions可选以 developer 角色注入的指令compact-prompt可选压缩会话时使用的提示词codex-reply继续既有会话参数字段说明threadId会话线程 id逻辑上必填字段本身保留可选以兼容老客户端conversationId已废弃为向后兼容仍接受prompt必填下一轮用户提示词get_thread_id的解析顺序是优先threadId缺失时回退conversationId两者皆无则报错。7.1 响应形状content 与 structuredContent 双轨两个工具返回标准 MCPCallToolResult。为兼容偏好structuredContent的客户端Codex 会把内容块在structuredContent中镜像一份并附带threadId。文档给出的示例{ content: [{ type: text, text: Hello from Codex }], structuredContent: { threadId: 019bbed6-1e9e-7f31-984c-a05b65045719, content: Hello from Codex } }工具定义中声明的outputSchema恰为{ threadId: string, content: string }且两者均 required与该示例严格一致。另外注意历史线形兼容细节outgoing_message.rs 在序列化响应时会移除 rmcp 新增的resultType字段以保持老客户端认识的历史线形{ content: [...], isError: false }该行为有专门的回归测试锁定。7.2 调用执行链路tools/call的处理在 message_processor.rs按工具名路由到codexhandle_tool_call_codex或codex-replyhandle_tool_call_codex_session_replycodex分支把参数反序列化为CodexToolCallParam经into_config生成有效Config其中approval_policy、sandbox枚举通过From实现映射到核心协议类型config字段经json_to_toml转换后作为 CLI 覆盖参与配置分层随后 spawn 独立异步任务执行会话避免阻塞消息处理主循环codex-reply分支先校验会话存在性不存在则返回带threadId的错误CallToolResult同样在独立任务中继续会话配置解析失败、缺prompt等错误都以工具错误结果文本 content形式返回而非 JSON-RPC 协议错误。八、审批服务端到客户端的反向请求当 Codex 需要批准应用变更或执行命令时服务端向客户端发起 JSON-RPC请求方向与工具调用相反文档列出的两个请求applyPatchApproval { conversationId, callId, fileChanges, reason?, grantRoot? }execCommandApproval { conversationId, callId, approvalId?, command, cwd, reason? }客户端对每个请求必须回复{ decision: allow | deny }。这两个 RPC 名可以在 app-server 协议 schema 中确认见 ServerRequest.json。而在 MCP Server 的当前 Rust 实现中审批是通过 MCP 规范的elicitation/create请求承载的参数中带codex_elicitation字段区分类型命令审批exec_approval.rscodex_elicitation: exec-approval附带codex_command命令 token 数组、codex_cwd、codex_parsed_cmd解析后的命令结构、codex_call_id、codex_event_id等关联字段提示语形如 Allow Codex to run\cmdincwd?;补丁审批patch_approval.rscodex_elicitation: patch-approval附带codex_changes文件 → 变更的映射、可选codex_reason与codex_grant_root。客户端响应体统一为{ decision }其中decision是ReviewDecisionallow/deny 及理由。两条关键实现细节体现了防御性设计响应在独立 tokio 任务中等待不会阻塞主 agent 循环客户端响应反序列化失败、或 oneshot 通道异常时实现会保守地以denied(approval request failed)提交决策——即解析失败即拒绝审批权永远偏向安全侧。决策最终通过Op::ExecApproval/Op::PatchApproval提交回 Codex 线程把客户端的人类决策接回引擎主循环。九、Auth 辅助端点文档将账号相关的完整请求/响应形状与流程示例委托给 app-server README 的 Auth endpoints (v2) 一节即 codex-rs/app-server/README.md。MCP 侧对应的方法面是account/read、account/login/start、account/login/cancel、account/logout、account/rateLimits/read。集成登录流程时应以该节为准。十、v1 遗留兼容方法为存量 app 客户端服务端仍接受一个窄化的 v1 兼容面getConversationSummarygetAuthStatusgitDiffToRemotefuzzyFileSearch、fuzzyFileSearch/sessionStart、fuzzyFileSearch/sessionUpdate、fuzzyFileSearch/sessionStop这些方法与事件流中的fuzzyFileSearch/sessionUpdated、fuzzyFileSearch/sessionCompleted通知共同构成遗留模糊搜索流程。新集成不应依赖它们。十一、兼容性与稳定性边界接口处于实验阶段方法名、字段与事件形状都可能演进。要获得权威 schema应直接查阅类型定义app-server-protocol/src/protocol 下的common、v1、v2文件v2 进一步拆分为 account.rs、model.rs、thread.rs、turn.rs、collaboration_mode.rs、config.rs、notification.rs 等模块服务端接线app-server/ 目录MCP Server 实现细节与回归测试mcp-server/src 及 mcp-server/tests其中codex_tool.rs套件配合 mock 模型服务器做端到端验证。十二、集成者清单Checklist以codex mcp-server启动服务通过 stdio 接入 MCP 客户端先完成initialize握手重复初始化会被拒绝新集成一律走 v2 的thread/*与turn/*方法仅当必须兼容旧客户端时才使用getConversationSummary等 v1 方法持续消费codex/event通知渲染进度用_meta.requestId/_meta.threadId把事件归属到具体请求与线程实现elicitation/createexec-approval / patch-approval的应答逻辑响应体为{ decision }在无法解析客户端响应时按实现约定视为 deny用model/list拉模型目录保留supportedReasoningEfforts顺序、用nextCursor翻页用collaborationMode/list拉协作模式预设三态字段省略/null/具体值各有语义用codex/codex-reply工具调用会话时按 kebab-case 参数表传参并预期content与structuredContent双份输出含threadId因接口实验性锁定协议版本以所使用 Codex 构建对应的app-server-protocol源文件为准不要跨版本假设字段稳定。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3 and GLM 5.3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
