[Bug]: Cursor adapter consistently emits invalid Codex apply_patch payloads

[Vincent-HD]

Environment

• OpenCodex: 2.10.0
• Provider: Cursor
• Model: cursor/grok-4.5
• Codex Desktop: 0.146.0
• OS: Linux
• Current config: nativeLocalExec is enabled
• The same behavior was previously observed with nativeLocalExec disabled as well

Problem

When using cursor/grok-4.5 through OpenCodex with Codex Desktop, file edits repeatedly produce malformed Codex apply_patch calls.

Observed failures include:

• Add-file lines missing the required + prefix
• Invalid hunk/context formatting
• Patch-like text that is not valid Codex freeform patch syntax

Codex then rejects the call locally with errors such as:

apply_patch verification failed: invalid hunk

The OpenCodex request itself completes with HTTP 200, so this does not look like a transport or filesystem failure. The failure appears to occur at the Cursor adapter/model tool-contract boundary.

Expected behavior

The Cursor adapter should either:

1. preserve apply_patch as a native custom/freeform tool;
2. expose a provider-compatible structured edit tool; or
3. clearly report that this model/provider combination cannot reliably execute Codex apply_patch.

A model producing patch-like text that is rejected on every edit attempt makes the Cursor route effectively unusable for repository changes.

Related

• [architecture][memory] Make 32 concurrent tool-recall sessions protocol-safe and memory-bounded #820 — custom/freeform tool conversion and tool-call protocol invariants
• Add Cursor (IDE/agent) as a client — localMode-ready integration #974 — experimental Cursor client integration

I can provide a redacted session capture with the malformed tool arguments and local rejection results if needed.

[github-actions]

_{Automated translation bookkeeping — detected language: unknown.}

[olddonkey]

I feel this is extremely useful as cursor is a good agent platform.

[ZachDreamZ]

Opened a fix: #1036. It adds provider-compatible structured edit tools (\�dit_file\ / \multi_edit) to the Cursor route and converts their exact-match replacements into valid Codex apply_patch payloads server-side, so models like cursor/grok-4.5 no longer emit malformed patch text. Malformed calls are dropped with a clear error instead of being relayed for local rejection after HTTP 200.

[Vincent-HD]

I feel this is extremely useful as cursor is a good agent platform.

yes, for work i'm only using cursor and for personal work I use codex, and I would really love to ditch cursor and just have a proper Codex + vscode setup.

Cursor is getting bloated and I STILL want an IDE for daily usage

[lidge-jun]

Status update so this does not look abandoned.

Your report is confirmed at the code level: the Cursor route advertises the freeform apply_patch tool, but there is no structured-edit translation on dev — so when the model emits an edit in Cursor's own shape, nothing converts it into a valid Codex patch. That is exactly the malformed-hunk failure you described, and nativeLocalExec being on or off does not change it, which matches what you observed.

A fix is in review: #1036. It converts Cursor's structured edit calls into valid apply_patch payloads, with validation and explicit drop errors rather than silent best-effort patching. The conversion logic looks right.

I have asked for one change before it can land. The PR decides whether a call is Cursor's synthetic edit tool by its NAME (edit_file / multi_edit), and both call sites receive that name from the wire — so a genuine client or MCP tool that happens to use the same name would be hijacked and either silently re-emitted as a patch, or dropped with an error naming a conversion the user never requested. The fix is to tag the synthetic tools when they are injected and convert only tagged calls; the PR already has a comment describing that flag, so it is a small change rather than a rework.

Keeping this issue open until that lands, since a fix in review is not a fix shipped. If you are able to try #1036's branch against your cursor/grok-4.5 setup and report whether the malformed patches stop, that would be genuinely useful — the PR's tests all drive our own synthetic caller, so real-model output is the evidence they cannot provide.