Repository navigation
[Bug]: Cursor's apply_patch still fails on exact-match / mid-turn drift after #1017 #1388
Description
Client or integration
Codex App
Area
Provider adapter
Summary
After #1017 / #1144, Cursor edit_file / multi_edit convert into valid Codex apply_patch payloads. That grammar fix works.
The remaining defect is different: converted patches still fail hard at Codex apply time with:
apply_patch verification failed: Failed to find expected lines in …Failed to find context '…'
especially when the worktree drifts mid-turn, whitespace does not match exactly, or old_string is non-unique.
Expected: once OpenCodex converts a structured edit into a valid patch, apply either succeeds or fails with actionable recovery diagnostics (nearest match / already-applied / refreshed old_string), instead of opaque exact-match rejection and retry storms.
nativeLocalExec: "on" does not bypass #1017 — writes still go through structured edit → apply_patch. Follow-up to closed #1017.
Reproduction
- Run OpenCodex
2.11.1with the Cursor provider (nativeLocalExecon or off; both hit the same apply path for writes). - Use Codex App on the Cursor route with
cursor/grok-4.5. - In a multi-file agent turn, edit via
edit_file/multi_editwhile the target can change between read and apply (dirty tree / previous partial edit / concurrent change). - Observe OpenCodex emit a valid
*** Begin Patchpayload, then Codex reject it locally withFailed to find expected lines/Failed to find context.
Minimal cases of the remaining gap (OpenCodex converter semantics + Codex-style exact matcher):
| Case | Result | Note |
|---|---|---|
| Happy path | ✅ | converter + apply succeed |
| Stale context after drift | ❌ Failed to find expected lines |
file changed before apply |
| Whitespace mismatch | ❌ | tabs/spaces must match exactly |
Ambiguous / non-unique old_string |
❌ | must be unique |
Git-style @@ -n,m +n,m @@ |
❌ Failed to find context |
bare @@ only |
Missing *** Begin Patch |
❌ | freeform envelope fragility |
multi_edit second depends on first |
❌ against ORIGINAL | independent/original-file semantics |
| Converter ok, apply fails on drift | ❌ | remaining gap after #1017 |
| Trailing-newline-only | converter rejects | intentional sharp edge |
| Indent-mangled but apply “succeeds” | exact match can succeed with wrong result |
Relevant code:
src/adapters/cursor/tool-definitions.tssrc/adapters/cursor/protobuf-events.ts(translateStructuredEditCall/replacementHunk)src/adapters/cursor/native-exec-fs.tssrc/adapters/cursor/exec-policy.ts
Version
2.11.1
Operating system
NixOS 26.11 (Linux x86_64)
Provider and model
cursor / cursor/grok-4.5
Logs or error output
apply_patch verification failed: Failed to find expected lines in <file>:
editor = "nvim";
apply_patch verification failed: Failed to find context '-3,7 +3,7 @@' in <file>
apply_patch verification failed: invalid patch: The first line of the patch must be '*** Begin Patch'
Checks
- I searched existing issues and documentation. ([Bug]: Cursor adapter consistently emits invalid Codex apply_patch payloads #1017 closed via fix(cursor,responses): convert structured edits and keep replay across empty deltas (#1017) #1144; this is the remaining post-conversion apply-brittleness gap)
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
github-actions commentedon Aug 10, 2026
Automated translation bookkeeping — detected language: English.
[-][Bug]: Cursor structured edits convert cleanly, but apply_patch still fails on exact-match / mid-turn drift after #1017[/-][+][Bug]: Cursor's apply_patch still fails on exact-match / mid-turn drift after #1017[/+]Ingwannu commentedon Aug 10, 2026
I checked the current Cursor translation path and the boundary described here. The post-#1144 converter is producing a valid Codex
apply_patchcall; the quoted failures occur later in the Codex host's local patch executor, after the provider adapter has returned the tool call.Exact-match rejection on drift, whitespace mismatch, or a non-unique old block is fail-closed behavior. OpenCodex does not own the target filesystem bytes at that point, and making the proxy apply a fuzzy or nearest-match edit would add filesystem authority and can silently modify the wrong occurrence.
nativeLocalExecdoes not change that boundary for writes.So the reproduction does not currently demonstrate an OpenCodex adapter defect. Please report the minimal stale-context case to the Codex client/runtime with the target bytes before apply and the exact generated patch. We can keep this issue open as upstream tracking and consider narrow retry guidance later, but we should not add fuzzy application or claim that a valid patch must succeed after the file has changed.
fix(cursor): harden structured-edit apply_patch conversion
fix(cursor): harden structured-edit apply_patch conversion