[Bug]: Cursor's apply_patch still fails on exact-match / mid-turn drift after #1017

[Vincent-HD]

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

1. Run OpenCodex 2.11.1 with the Cursor provider (nativeLocalExec on or off; both hit the same apply path for writes).
2. Use Codex App on the Cursor route with cursor/grok-4.5.
3. In a multi-file agent turn, edit via edit_file / multi_edit while the target can change between read and apply (dirty tree / previous partial edit / concurrent change).
4. Observe OpenCodex emit a valid *** Begin Patch payload, then Codex reject it locally with Failed 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.ts
• src/adapters/cursor/protobuf-events.ts (translateStructuredEditCall / replacementHunk)
• src/adapters/cursor/native-exec-fs.ts
• src/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.

[github-actions]

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

[Ingwannu]

I checked the current Cursor translation path and the boundary described here. The post-#1144 converter is producing a valid Codex apply_patch call; 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. nativeLocalExec does 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.