【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载导读当用户通过 Cursor 路由的模型如 cursor/gpt-5.6-luna使用 opencodex 的 Browser 插件时浏览器无法启动。本实验计划WP1针对该问题的核心疑点——Cursor 是否会调用 opencodex 注入的客户端工具——设计了一套单次实时请求即可验证整个假设矩阵的探针方案以McpToolDefinition的 provider 标识与命名一致性为变量构造 V_A/V_B/V_C 三种变体通过决策表收敛根因方向并用 A-gate 审计修正了探针自身的协议过滤盲区。读完本文你将掌握如何对私有协议边界做最小干扰、单请求、多假设并行的实时探针设计以及 opencodex 在 Cursor 适配层中工具广告tool advertisement链路的完整实现细节。背景为什么 Browser 插件在 Cursor 路由下不可用问题最初被归类为权限问题但 WP1 根因分析001_wp1_root_cause.md将其修正为工具广告 / Cursor 协议缺口tool-advertisement / Cursor-protocol gap进一步细化为未注册 / 合成 provider 路由缺口unregistered / synthetic-provider routing gapBrowser 插件并非一组专用工具而是通过客户端 MCP 工具mcp__node_repl__js运行browser-client.mjs驱动的。opencodex 将 Codex 客户端工具mcp__node_repl__js及其余所有客户端工具挂在合成 provider idopencodex-responses源码常量OCX_RESPONSES_TOOL_PROVIDER定义于 tool-naming.ts之下通过RequestContext.tools注入。Cursor 只把已注册、可路由的 MCP provider下的工具登记进模型的可调用目录合成 provider 不可路由于是这些工具被隐藏/拒绝模型目录里根本看不到它们。对照实验证明差异在 Cursor 路由本身同构 subagent 在非 Cursor 模型gpt-5.6-sol上能拿到完整 MCP 工具套件含mcp__node_repl__js与全部mcp__codex_apps__*工具而在 cursor/gpt-5.6-luna 上工具清单里只有 Cursor 原生 agent 工具Shell、Glob、rg、ReadFile、WebSearch 等没有任何注入工具。参考桥接方案的线索合成 provider 并非天生不可调用为了收敛方向两个 sol 检索 agentErdos、Anscombe解析了公开可工作的桥接方案Hardcode84/opencode-cursor与funny-vibes/agent-vibes的线上协议得到三条关键事实McpToolDefinition的结构是{name, description, input_schema, provider_identifier, tool_name}其中provider_identifier是普通字符串不是枚举或注册令牌。一个可工作的桥接以合成 provider idopencode广告工具模型侧名称统一为mcp_opencode_tool并且只通过RequestContext.tools注入不做任何mcp.json注册。模型随后发出mcpArgs桥接按toolName || name剥离前缀路由不依赖provider_identifier做分发。因此未注册的合成 provider id本身不构成阻塞证据。真正的约束是一致性name mcp_provider_tool、provider_identifier provider、tool_name tool三者必须对齐。另外stock cursor-agent 中还存在已知的额外闸门工具启停、--approve-mcps、版本相关的目录陈旧catalog staleness。这些对直接的RequestContext注入路径不适用但被记录下来以防干扰实验判断。真正的谜题exec_command 能被调用node_repl 却不能从代码阅读看opencodex 早已通过buildCursorToolDefinitions广告客户端工具实现见 tool-definitions.tsproviderIdentifier为opencodex-responsesname为裸线上名如exec_command/node_repl__jsCursor 将其显示为mcp_opencodex-responses_name。而且exec_command确实被 Cursor 模型调用过tool-definitions.ts 注释记载了真实会话中出现mcp_opencodex-responses_exec_command的痕迹相关名称归一化逻辑见 tool-naming.ts 的normalizeCursorWireName。但mcp__node_repl__jsBrowser从未被调用。这说明此前opencodex-responses 被整体丢弃的根因至少是不完整的该 provider 下至少有一个客户端工具是可调用的。由此产生三个相互竞争的假设需要通过一次实时探针来区分假设主张验证点H1命名opencodex 把name设为裸toolName而非mcp_provider_tool。Cursor 仍能浮出exec_command被系统提示强化但其他客户端工具因模型侧名称不符合工作桥接的mcp_provider_tool约定而被丢弃/隐藏改命名后是否可调用H2provider idopencodex-responses下的工具是二等公民同一工具改挂 provider idopencodex与工作参考一致即可调用改 provider 后是否可调用H3行为所有客户端工具其实都已浮出gpt-5.6-luna 只是不会自发调用 node_replexec_command 因系统提示强化而胜出强制调用提示下是否仍不调用此时代码协议无需修复探针设计单请求、三变体、零重启探针的目标是在隔离且无代理重启的前提下区分 H1/H2/H3驱动脚本导入createLiveCursorTransport使用~/.opencodex/auth.json中的 cursor 访问令牌通过OPENCODEX_CURSOR_TEST_TOKEN传入向 api2.cursor.sh 发起一次实时会话。这是纯出站 h2 请求不启动第二个 server、不写 pid 文件、不写配置、不做 Codex 同步对端口 10100 上的在线代理零干扰。buildCursorToolDefinitions增加一个环境变量门控OCX_CURSOR_TOOL_PROBE1的实验分支在同一个请求里以三种变体方案广告同一个探针工具赋予不同的模型侧名称。一次实时轮次即可测完整个矩阵预算1 次 Cursor 请求变体providernametoolName含义V_Aopencodex-responses裸probe_aprobe_a当前方案V_Bopencodexmcp_opencodex_probe_bprobe_b工作参考方案provider 前缀命名V_Copencodex-responsesmcp_opencodex-responses_probe_cprobe_c当前 provider 预加前缀命名提示词强制工具使用Call every tool available to you exactly once with minimal args, then stop.配合toolChoice: auto、parallelToolCalls: true捕获每一个tool_call_start/tool_call_delta帧。哪个变体的名字出现在tool_call_start中就证明 Cursor 使哪个变体可调用。决策表从探针帧到根因结论观测结果结论修复方向只有 V_A 触发当前方案本就可调用node_repl 失败属于 H3行为/强化问题系统提示强化而非 provider 重接线V_B和/或 V_C触发但 V_A 不触发命名/provider 是关键H1/H2以一致的mcp_provider_tool命名广告客户端工具并按 name 路由入站 mcpArgs前缀剥离已由normalizeCursorWireName完成全部不触发即使强制工具提示也无法浮出任何客户端工具否定廉价修复升级为 NEEDS_HUMAN转向 B-2 真实 mcpServers 桥接或 Shell-trampoline均为更大工程预算与安全约束实时 Cursor 探针请求目标 1 次硬上限 6 次目标预算。每个变体矩阵计为一次请求。绝不重启/杀死代理进程ocx.pid。前后核对 pid 未变化。所有实验脚手架env 分支 探针脚本在给出任何 DONE 结论前必须移除只有真实、经过测试的修复若有才允许提交。完成前必须通过tsc与bun test tests/cursor-*.test.ts。A-gate 审计探针自身的协议过滤盲区本实验计划附带了一次主裁决审计sol reviewer Ohm 因工作区额度耗尽离线退回 AUDIT-LOOP-01 直接独立审计结论为GO-WITH-FIXES并折叠进一个阻塞性问题BLOCKER健全性代码可验证最初的隔离脚本直接驱动createLiveCursorTransport.run()方案对 provider-id 变体不健全。mcpArgsFromToolCallprotobuf-events.ts与mapSyntheticMcpExecToToolEventsprotobuf-events.ts都硬过滤args.providerIdentifier OCX_RESPONSES_TOOL_PROVIDER。因此变体 Bprovideropencodex的调用永远不会以tool_call_start形式从run()浮出——它会路由到 native-exec 的mcpExec→toolNotFound对 CursorServerMessage 观察者不可见。此外该脚本绕过了真实/v1/responses的系统提示注入buildCursorToolGuidanceSystemNote实现见 tool-guidance.ts负结果将具有误导性。FIX已折叠改为走真实路径——向 127.0.0.1:10100 上的在线代理POST/v1/responses回环请求无需 API keyisApiAuthRequired为 false开启debug:true并从/api/debug/logs环形缓冲读取原始协议帧。原始帧在OCX_RESPONSES浮出过滤之前捕获因此任意providerIdentifier下的 toolCall 都可观测且完整生产工具处理路径系统提示、cursorToolsForActivePrompt被忠实执行。零重启、零配置写入pid 前后核对不变。这个修正本身就是一个值得沉淀的通用方法论探针必须与被测对象共享同一观察平面——如果观察者位于过滤点之后那么任何被该过滤点拦截的变体都会产生不可调用的假阴性。后续实验结果的走向与本计划的价值按计划执行后详见 003_wp1_experiment_result.mdH1 与 H2 均被忠实证据否定——即使是完全复刻工作参考方案provideropencode、namemcp_opencode_tool、同一requestContextArgs通道cursor/gpt-5.6-luna 依然不可调用注入工具且每次回退到 Cursor 原生 ShellshellToolCall/shellStreamArgsmcpArgs出现 0 次。实验收敛出新的主导假设 H4原生工具挤出native-tool crowd-out注入 MCP 工具始终在场但模型总是绑定原生工具套件。最终真实修复004_fix_mcp_tools_channel.md发现真正有效的是顶层AgentRunRequest.mcp_tools通道McpTools包装器。修复在 protobuf-request.ts 中落地encodeCursorRunRequest在 modelDetails 之后用buildCursorToolDefinitions构造mcpTools: create(McpToolsSchema, { mcpTools: mcpToolDefs })并保留RequestContext.tools作为第二通道。此前的 phase45 之所以废弃该通道是因为用错了赋值形状wire type 7 非法 tag 导致 Cursor 解析崩溃并非通道本身不兼容——这恰好印证了本实验计划区分『通道被拒』与『形状写错』的方法论价值。后续加固005_hardening.md进一步修正了通道一致性问题mcp_tools必须与RequestContext.tools、事件态clientToolNames共用同一个cursorToolsForActivePrompt过滤后的可见集合否则通用工具计数提示下会广告出事件态不认识的工具调用时被当作未知 Responses 工具拒绝。对应回归测试位于 tests/providers/cursor/cursor-blob.test.ts正常提示 →mcp_tools [mcp__node_repl__js]通用工具计数提示 → 仅[exec_command]空工具 /toolChoice:none→ 通道保持 unset。结语一份可复用的协议边界实验模板这份实验计划的核心价值不在于某个特定结论而在于它示范了如何在私有、未文档化、且在线服务不可随意重启的协议边界上做严格实验先通过外部工作实现解析出协议的约束面provider 字符串与命名的一致性再从自身代码找出反例exec_command 可调用以收窄谜题用单请求多变体的矩阵设计把假设压缩到一次实时探测最后用 A-gate 审计把探针本身的观察盲区过滤点之后的假阴性也纳入验证范围。这套假设矩阵 单请求探针 决策表 观察面审计的方法可以直接复用于其他需要与专有协议上游对齐的适配层调试场景相关的完整脉络可从 260711_cursor_browser_bridge 目录下的 000-005 系列文档与 src/adapters/cursor 源码继续深入。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐opencodex 在 Cursor 路由下客户端工具不可调用的实验证伪B-1 假设的现场验证与 NEEDS_HUMAN 结论opencodex 在 Cursor 路由下客户端工具不可调用的实验证伪B 1 假设的现场验证与 NEEDS_HUMAN 结论 本文记录 opencodexSuperstructAPI网关请求路由的验证层设计SuperstructAPI网关请求路由的验证层设计 你是否还在为API网关的请求验证逻辑而烦恼数据格式错误、参数缺失、类型不匹配等问题是否经常导致服务异常开发工具opencodex Codex WebSocket 端到端验证指南101 升级、多轮中断与工具调用的协议一致性验收opencodex Codex WebSocket 端到端验证指南101 升级、多轮中断与工具调用的协议一致性验收 opencodex 是面向 OpenAI创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考