[Regression]: Cursor subagents still receive no Responses exec bridge in v2.22.0

[GAOHANG-G]

Client or integration

Codex App, through OpenCodeX's Cursor provider adapter, using a fresh native multi-agent child.

Area

Tools / MCP / web search

Summary

A fresh Cursor-routed subagent can respond, and the OpenCodeX route succeeds, but the child receives no Responses-owned execution path in its advertised request tool catalog. It therefore cannot complete a harmless read-only local-file task.

This report does not claim a confirmed root cause. The catalog and host-side rollout evidence indicate a bridge-less child profile: Cursor-native operations are rejected or redirected, while the suggested Responses execution tool is not present.

Reproduction

1. On Windows, use OpenCodeX v2.22.0 from Codex Desktop.
2. Spawn a fresh cursor/grok-4.6 subagent at high reasoning effort.
3. Assign a read-only local-file task.
4. Observe that the child's advertised catalog contains Cursor-native Read/Grep/Shell-style tools plus the OpenCodeX request_user_input bridge, but no Responses execution client tool such as exec, exec_command, or shell_command.
5. Cursor-native operations are rejected or redirected, but the suggested Responses execution tool does not exist in the catalog.
6. The child cannot read the file.

Version

• OpenCodeX: v2.22.0
• Codex Desktop build: 26.810.52044
• Codex child runtime: 0.148.0-alpha.9

Operating system

Windows

Provider and model

• Requested model: cursor/grok-4.6
• Resolved model: grok-4.6
• Provider: cursor
• Route result: HTTP 200
• Reasoning effort: high

Sanitized host-side evidence

• Cursor child: 0 host-recognized tool calls and 0 tool outputs; the task could not read the file.
• Positive control under the same parent task, workspace permissions, and OpenCodeX configuration: volcengine-agent-plan/deepseek-v4-flash completed the same read-only task with 4 host-recognized exec calls and 4 outputs.

The successful route therefore shows request routing, not execution-tool availability or task completion.

Difference from prior fixes

This differs from #1673 and #1763. Those changes preserve or convert unified exec when an execution tool already exists. In this Cursor child request, no execution path is present in the advertised tool catalog, so there is nothing for those preservation or input-contract paths to carry forward.

Expected behavior

Provide a safe execution path for this profile by either:

• injecting or preserving a Responses-owned execution client tool; or
• adding a narrowly guarded fallback only when the child catalog has no Responses execution bridge.

Users should not need to globally enable Cursor-native local execution.

Checks

• I searched existing open and closed issues and reviewed [Bug]: Cursor subagents drop Codex Desktop unified exec bridge #1661, fix(cursor): preserve unified exec in generic tool filtering #1673, and fix(responses): preserve unified exec input contract #1763.
• I removed secrets, tokens, account details, request credentials, local identifiers, and personal data.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• [Bug]: Cursor subagents drop Codex Desktop unified exec bridge #1661

🔗 Related PRs

#321 - docs(cursor): document exec policy and catalog troubleshooting [merged]
#402 - fix(cursor): stop false shell blocked reports and cmd/command mismatch (#399) [merged]
#1529 - fix(codex): keep direct MCP tools visible for routed models [merged]
#1673 - fix(cursor): preserve unified exec in generic tool filtering [open]
#1801 - fix(cursor): teach code-mode nested-helper contract in tool guidance [open]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Wibias]

Follow-up after reviewing #1661/#1673 and the current Cursor path: #1661's original defect is fixed. That bug was specifically exec being present in the parsed client catalog and then being removed by Cursor's second-stage generic-tool filter; #1673 corrected that filter and current dev still preserves a Responses-owned execution-path tool when one reaches the Cursor adapter.

#1830 is a separate successor bug: the fresh Cursor child ends up with no Responses execution path in the advertised Cursor catalog, so #1673 has nothing to preserve. The later v2.18.2/v2.19.0/v2.22.0 reproductions should therefore be tracked here rather than treated as a regression of the #1673 filter itself.

Current investigation is focused on where exec disappears before Cursor registration. The leading OpenCodex-local hypothesis is the interaction between Cursor's tool_mode = code_mode_only, supports_search_tool = false, and Cursor's exact 120,000-byte McpTools limit: current source comments/tests already document that disabling deferred discovery under Code Mode can inflate exec.description dramatically, and the Cursor budget intentionally drops an individually oversized exec and then drops wait with it. That would closely match the #1830 surface where small tools survive but exec/wait do not.

I would not use the previously suggested bridge-less native-exec fallback as the fix: absence of a client bridge is not an authorization signal, and enabling Cursor-native fs/shell/fetch on that basis would weaken the existing server-local policy boundary. The safer fix should keep the Responses-owned execution path within Cursor's transport budget.

[Wibias]

Draft fix is now in #1832.

The patch addresses the catalog-projection seam rather than weakening Cursor execution policy: Cursor routed rows keep tool_mode = code_mode_only and now advertise Codex deferred tool exposure (supports_search_tool = true) in both template and template-less paths, while web_search_tool_type remains absent so Cursor still does not opt into the hosted-search sidecar.

TDD was RED first: on current dev, the two focused Cursor catalog assertions failed exactly because both paths returned supports_search_tool = false. The production patch is now on clean head e93078ca694dcfaadeb72819552a98274871fe6b; React Doctor and typecheck are already green, with the full Cross-platform suite still running.

The existing 120 KB Cursor tool-catalog limit, #1673/#1583 execution-path preservation, and fail-closed Cursor-native local-exec policy are unchanged. A credential-dependent live Cursor child re-probe is still desirable before treating the issue as fully closed.

[lidge-jun]

Fixed on dev by #1832 (merged as 0313716c2).

Cursor routed catalog rows now enable deferred code-mode tool discovery (supports_search_tool: true) on both the template path and the template-less fallback. They still omit hosted web-search metadata, because the runTurn transport bypasses that separate sidecar — the two bits were being conflated, and turning the discovery bit off was what pushed the nested MCP catalog into exec.description.

That inflation is the mechanism behind your symptom: once the whole catalog is inlined into one tool's description, the advertised catalog can exceed Cursor's 120KB serialized limit, and what gets trimmed is exactly the Responses execution bridge the child needed.

Evidence added alongside the fix, measured on the real protobuf serializer rather than inferred from the flag:

• a deferred catalog serializes inside CURSOR_TOOL_BYTES_LIMIT and keeps both exec and wait; the same two tools exceed the cap once the nested catalog is inlined into exec.description;
• when the budget must trim, exec and wait are what survive, and the trimmed result fits — which is the direct inverse of the catalog you observed.

One caveat worth stating plainly. This closes the mechanism we can prove from the code and the wire budget. Your report was from a fresh Cursor-routed child on Windows, and I have not reproduced that exact live child here. If a fresh cursor/grok-4.6 subagent still comes up with no Responses execution tool in its advertised catalog after this ships, please reopen with the observed catalog — that would point somewhere other than the byte budget, and I would rather reopen than have you work around it.

Closing as completed. The change is on dev and ships with the next release; it is not in a published version yet.