Repository navigation
[Bug]: Cursor adapter consistently emits invalid Codex apply_patch payloads #1017
Description
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:
- preserve apply_patch as a native custom/freeform tool;
- expose a provider-compatible structured edit tool; or
- 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.
Activity
github-actions commentedon Aug 4, 2026
Automated translation bookkeeping — detected language: unknown.
olddonkey commentedon Aug 4, 2026
I feel this is extremely useful as cursor is a good agent platform.
ZachDreamZ commentedon Aug 5, 2026
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.
fix(cursor): address CodeRabbit + Codex review feedback on lidge-jun#…
Vincent-HD commentedon Aug 5, 2026
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
docs(devlog): fold four audit rounds into the triage unit
docs(devlog): split scheduling advice out of the triage dependency co…
lidge-jun commentedon Aug 6, 2026
Status update so this does not look abandoned.
Your report is confirmed at the code level: the Cursor route advertises the freeform
apply_patchtool, but there is no structured-edit translation ondev— 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, andnativeLocalExecbeing 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_patchpayloads, 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.5setup 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.fix(cursor): expose structured edit tools that convert to valid apply…
fix(cursor): address CodeRabbit + Codex review feedback on lidge-jun#…
fix(cursor): gate structured-edit conversion on provenance, not tool …
fix(cursor): expose structured edit tools that convert to valid apply…
fix(cursor): address CodeRabbit + Codex review feedback on #1017
fix(cursor): gate structured-edit conversion on provenance, not tool …
fix(cursor): derive structured edits from final catalog
Merge pull request #1144 from lidge-jun/codex/260806-stack10-cursor-r…
Wibias commentedon Aug 7, 2026
Closing as fixed on dev.
The Cursor structured-edit issue was fixed by #1144. The adapter now converts Cursor-compatible structured edits into valid Codex apply_patch freeform payloads, preserves the original call ID, and fails explicitly on malformed or ambiguous replacements instead of forwarding invalid patch data.
#1144 includes regression coverage for the affected path.
fix(cursor): harden structured-edit apply_patch conversion
docs(devlog): fold four audit rounds into the triage unit
docs(devlog): split scheduling advice out of the triage dependency co…
fix(cursor): expose structured edit tools that convert to valid apply…
fix(cursor): address CodeRabbit + Codex review feedback on lidge-jun#…
fix(cursor): gate structured-edit conversion on provenance, not tool …
fix(cursor): derive structured edits from final catalog
Merge pull request lidge-jun#1144 from lidge-jun/codex/260806-stack10…
fix(cursor): harden structured-edit apply_patch conversion