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

[growth-wizard-digital]

Client or integration

Codex App, through OpenCodeX's Cursor provider adapter, using a fresh native multi-agent child routed to cursor/grok-4.6.

Area

Tools / MCP / web search

Summary

Fresh Cursor-routed Codex Desktop subagents can respond but cannot execute the Desktop terminal tool. The same fresh task succeeds on a native gpt-5.6-terra child.

This is not a sandbox or permission problem. The parent exposes Codex Desktop's unified custom terminal tool as exec; the Cursor adapter's generic tool-use path only preserves bare exec_command / shell_command aliases, which are absent from this child catalog.

Reproduction

1. Start a fresh Codex Desktop task through OpenCodeX.
2. Spawn a fresh cursor/grok-4.6 subagent with no inherited conversation context.
3. Ask it to execute a harmless local command such as pwd.
4. The child replies, but cannot use the bridge:
   • Tool not found: exec_command
   • Tool not found: shell_command
5. A bridge-only prompt reports a Cursor-native catalog plus mcp_opencodex-responses_request_user_input, with neither shell bridge alias present.
6. Run the identical task with a fresh native gpt-5.6-terra child: pwd succeeds with exit code 0.

Version

OpenCodeX 2.14.2; Codex Desktop runtime 0.148.0-alpha.9.

Operating system

macOS on Apple Silicon.

Provider and model

cursor/grok-4.6

Logs or error output

Cursor child:
Tool not found: exec_command
Tool not found: shell_command

Native Terra control:
pwd
/Users/.../Documents/Codex/...
exit code 0

Description

The installed adapter already recognizes unified exec as an execution-path tool:

const CURSOR_EXECUTION_PATH_TOOL_NAMES = [
  CODEX_UNIFIED_EXEC_TOOL, // "exec"
  CODEX_EXEC_COMMAND_TOOL,
  CODEX_SHELL_COMMAND_TOOL,
];

However, its generic-tool-use filter uses the narrower bare-alias predicate:

function isBareCodexExecCommandTool(tool) {
  return isBareCodexShellBridgeTool(tool);
}

const execTools = tools?.filter(isBareCodexExecCommandTool);

That excludes unified exec. In addition, src/adapters/cursor/native-exec.ts returns an error for a Responses client tool over native MCP-exec: bridge suspension is not implemented.

Expected behavior:

• Preserve unified Desktop exec when filtering and prioritizing Cursor execution tools.
• Do not instruct a child to call exec_command or shell_command unless that exact name is present in its catalog.
• Relay the resulting client tool call back to Codex Desktop so the nested tools.exec_command(...) operation executes.
• Add regressions for a fresh cursor/* subagent with unified exec, including generic tool-use prompts.

Related issues

• [Bug] Cursor adapter: false "Shell/Read blocked" reports caused by shell-tool name mismatch + native-exec rejections #399 / PR fix(cursor): stop false shell blocked reports and cmd/command mismatch (#399) #402 fixed legacy shell_command / exec_command aliasing and argument normalization.
• Merged PR fix(cursor): pin unified exec so wait cannot ship alone #1583 pins unified exec during catalog truncation. This report concerns the separate generic-filter path, which still selects only bare shell aliases.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[coderabbitai]

🔗 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]
#429 - fix(cursor): stop injecting shell-alias hint into user prompts; reject empty exec_command [merged]
#627 - fix(cursor): steer Windows bridge shell away from PS 5.1 syntax loops [merged]
#1583 - fix(cursor): pin unified exec so wait cannot ship alone [merged]

---

📝 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!

[github-actions]

Issue reopened

The report now contains the information required by the automated check. Thanks for updating it.

[Ingwannu]

Confirmed and fixed in PR #1673. The defect was the second-stage generic tool-use filter: transport budgeting already retained unified exec, but the prompt filter recognized only bare exec_command / shell_command and removed the actual Desktop execution tool. The fix filters by the full Responses-owned execution path, keeps alias guidance conditional on an alias actually existing, and proves unified exec is registered and relayed back to Codex rather than falling into native local exec. Keeping this issue open until the PR is independently reviewed and merged.

[lidge-jun]

Fixed by cherry-picking #1673 (fix(cursor): preserve unified exec in generic tool filtering) onto dev at 2eedccb13.

[growth-wizard-digital]

Follow-up: the Cherry-picked #1673 logic is present in the current stable release (v2.18.2), but a fresh Codex Desktop subagent still reproduces the failure.

Live reproduction

1. Upgrade to 2.18.2, run ocx ensure && ocx sync, and restart Codex.
2. Launch a fresh cursor/grok-4.6 subagent with: “use exactly 1 currently available Codex execution tool to run pwd”.
3. The subagent catalog contains Cursor-native Shell / AwaitShell and mcp_opencodex-responses_request_user_input, but no Responses execution client tool.
4. The first Shell call is rejected by nativeShellDisabledMessage(), which instructs the model to use shell_command or exec_command; neither exists in that catalog.

The newly added unified functions.exec recognition does not cover this subagent profile because it never receives functions.exec in the request tool list. Therefore the generic-tool filter has no execution-path tool to preserve.

Narrow working fix tested locally
Only reject Cursor-native read/write/shell/fetch when the request actually advertises a Responses execution client tool. If the catalog has no such bridge, retain Cursor native execution as the fallback:

if (!cursorUnsafeNativeLocalExecEnabled(deps)
    && clientToolsAdvertiseExecutionPath(deps.clientToolDefs)) {
  // existing native-exec rejection branches
}

where clientToolsAdvertiseExecutionPath recognizes exec, functions__exec, exec_command, and shell_command.

After restarting the proxy with that guarded fallback, a fresh Grok 4.6 subagent ran pwd successfully (stdout /, exit 0).

This should be a safe fallback for bridge-less child tool catalogs; it avoids enabling the global providers.cursor.nativeLocalExec: "on" workaround, which permits native local execution for every Cursor request. Please reopen or track as a follow-up to #1673.

[GAOHANG-G]

Follow-up: this is still reproducible on OpenCodeX v2.19.0 after a full Codex Desktop restart.

Environment

• OS: Windows
• OpenCodeX: 2.19.0
• Codex Desktop CLI runtime recorded in the child rollouts: 0.147.0-alpha.6.6
• Fresh parent task controlled by main/gpt-5.6-luna at high reasoning effort
• All tests were read-only; no files or configuration were changed

Reproduction

From the fresh parent task, I spawned three fresh child agents at high reasoning effort and gave each the same task:

1. List up to eight entries in an existing local workspace directory.
2. Read the first line of an existing Markdown file.
3. Report the tool actually used.

Tested children:

• cursor/grok-4.6
• cursor/kimi-k3
• volcengine-agent-plan/deepseek-v4-flash as a positive control

I verified routing through the newest matching usage.jsonl records and inspected each child's rollout JSONL rather than relying on model self-report.

Results

Child	Route	Tool intent	Host-recognized calls in rollout	Result
cursor/grok-4.6	provider=cursor, requestedEffort=high, status=200	Yes	function_call/custom_tool_call=0, outputs 0	Failed
cursor/kimi-k3	provider=cursor, requestedEffort=high, status=200	Yes	function_call/custom_tool_call=0, outputs 0	Failed
volcengine-agent-plan/deepseek-v4-flash	provider=volcengine-agent-plan, requestedEffort=high, status=200	Yes	custom_tool_call=1, output 1	Succeeded

The Cursor children planned or attempted Cursor-native Glob / Read / Shell operations, but those operations were rejected and redirected to the Responses bridge. The advertised child catalog still did not contain exec, exec_command, shell_command, or an equivalent Responses execution MCP tool. Consequently, no client tool call was relayed back to Codex Desktop, and both Cursor rollouts contained zero host-recognized tool calls.

The Volcengine child, under the same parent task, workspace, permissions, and global OCX configuration, produced a real custom_tool_call, received its output, and completed both reads successfully.

Conclusion

This appears to be the same bridge-less child catalog problem described in the previous v2.18.2 follow-up, and it remains present in v2.19.0. It affects at least two Cursor models, so it does not appear specific to Grok. The successful positive control also argues against a general Codex sandbox, workspace, or global OCX configuration problem.

Could this issue be reopened, or tracked as a follow-up regression to #1673? A safe fix should restore/inject the Responses-owned execution path for fresh Cursor children, or provide a narrowly guarded bridge-less fallback, without requiring global providers.cursor.nativeLocalExec: "on".

[GAOHANG-G]

Still reproducible on OpenCodeX v2.22.0 with Codex child runtime 0.148.0-alpha.9. Tracking the bridge-less child catalog case in #1830. This differs from #1763: the Cursor child receives no Responses execution tool in its advertised catalog, whereas #1763 fixes the input contract when exec is already present.