CLI feature request: experimental hash-anchored edit mode to reduce edit failures and retries

[ndycode]

What variant of Codex are you using?

CLI

What feature would you like to see?

I'd like Codex CLI to support an experimental hash-anchored edit mode (alongside apply_patch) to improve edit reliability, especially when models struggle with strict patch formatting.

The core idea is to let read/search tools return stable per-line anchors (short content-hash IDs), and let an edit tool target those anchors directly instead of reproducing exact old text.

Research-driven motivation (from the Harness Problem write-up):

• Benchmark shape: 16 models, 3 edit formats, 180 tasks per run, 3 runs.
• Reported patch-format failure rates were high for several non-Codex models (examples in the post: Grok 4 at 50.7%, GLM-4.7 at 46.2%).
• The write-up reports that hashline-style anchored edits matched or beat replace-style edits for most tested models.
• Reported impact examples: Grok Code Fast 1 from 6.7% to 68.3%, and Grok 4 Fast output tokens down 61% due to fewer edit retry loops.

Proposed CLI PoC scope:

1. Add an experimental edit tool (or mode), e.g. apply_anchored_edit, behind a feature flag.
2. Return line anchors from read/search output (example format: lineNumber:hash|content).
3. Support operations like replace_range, insert_after, and delete_range using anchor IDs.
4. Enforce optimistic concurrency: if anchors no longer match current file content, reject safely with a clear conflict message.
5. Keep full backward compatibility by preserving apply_patch and using anchored mode as opt-in (or adaptive fallback).

Why this matters:

• Edit failures and retry loops are still a practical reliability issue in real workflows.
• Existing Codex issues show recurring pain around patch/edit reliability and fallback behavior (for example: Apply_Patch is not working at all on windows system #9661, The model claims that it can not use the built in apply_patch tool, and tend to use bash/python to replace in files #10330).
• A prior request for this concept (Implement hash based edit tool #11601) was closed as not planned, but this request includes concrete rollout/guardrail and measurement criteria.

Suggested acceptance criteria:

1. Add a benchmark mode for edit-tool reliability (failure rate + retries + token usage).
2. Demonstrate reduced failed edit attempts vs. patch-only baseline on the same task set.
3. Show no correctness regressions on existing Codex CLI edit workflows.
4. Keep the feature gated/experimental until reliability data is strong.

Additional information

Primary reference: https://blog.can.ac/2026/02/12/the-harness-problem/

Related prior issue: #11601

If maintainers prefer a minimal first step, a benchmark-only branch (no default behavior change) would still be very useful to validate feasibility in Codex CLI.

[ndycode]

if this gets implemented, could it ship first behind a pre-release experimental CLI flag?

I want to run it on real repos early and send concrete repros, benchmark data, and fixes before any default rollout.

Happy to help test and contribute.

[ndycode]

Closing this to avoid duplicate noise since maintainers already gave a clear not-planned response on #11601 (comment 3892906518). If direction changes in the future, this can be reopened with new evidence.