Skip to content

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

Closed
Closed
[Bug]: Cursor subagents drop Codex Desktop unified exec bridge#1661
Labels
bugSomething isn't workingtoolstool_calls, MCP, web-search / sidecar tools

Description

@growth-wizard-digital
growth-wizard-digital
opened on Aug 14, 2026

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

Checks

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

Activity

  1. coderabbitai commented on Aug 14, 2026

    @coderabbitai
    coderabbitaiBot
    on Aug 14, 2026 – with coderabbitai
    Contributor
    🔗 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!

  2. github-actions
    closed this as not plannedon Aug 14, 2026

  3. github-actions commented on Aug 14, 2026

    @github-actions
    github-actionsBot
    on Aug 14, 2026 – with GitHub Actions
    Contributor

    Issue reopened

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

  4. growth-wizard-digital
    changed the title [-][Bug] Cursor subagents drop Codex Desktop unified exec bridge[/-] [+][Bug]: Cursor subagents drop Codex Desktop unified exec bridge[/+] on Aug 14, 2026
  5. github-actions
    added
    bugSomething isn't working
    toolstool_calls, MCP, web-search / sidecar tools
    on Aug 14, 2026
  6. github-actions
    reopened this on Aug 14, 2026

  7. Ingwannu commented on Aug 14, 2026

    @Ingwannu
    Ingwannu
    on Aug 14, 2026
    Owner

    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.

  8. lidge-jun commented on Aug 14, 2026

    @lidge-jun
    lidge-jun
    on Aug 14, 2026
    Owner

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

  9. lidge-jun
    closed this as completedon Aug 14, 2026

  10. growth-wizard-digital commented on Aug 14, 2026

    @growth-wizard-digital
    growth-wizard-digital
    on Aug 14, 2026 – with ChatGPT Codex Connector
    Author

    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.

  11. GAOHANG-G commented on Aug 15, 2026

    @GAOHANG-G
    GAOHANG-G
    on Aug 15, 2026 – with ChatGPT Codex Connector

    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".

  12. GAOHANG-G commented on Aug 16, 2026

    @GAOHANG-G
    GAOHANG-G
    on Aug 16, 2026 – with ChatGPT Codex Connector

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingtoolstool_calls, MCP, web-search / sidecar tools

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions