Apply_patch issue wtih squashed lines and zero/duplicate edit action

What version of Codex CLI is running?

0.114.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4

What platform is your computer?

darwin-aarch64

What terminal emulator and version are you using (if applicable)?

Ghostty

What issue are you seeing?

In the case of apply_patch, the model sometimes squashes multiple logical patch lines into a single string line. Since the current codex-apply-patch parser relies on a
strict line-based Lark grammar (expecting physical LF characters), these squashed lines cause parsing to fail.

1. Common Failure Patterns

The following patterns were identified as the primary causes of infinite Agent retry loops:

• Code Squashing: ;+added_line or }+added_line (missing newline between code and diff prefix).
• Marker Squashing: code();*** End Patch (marker appended to code).
• Indentation Issues: Patches being entirely indented during copy-paste, leading to misaligned markers.
• Whitespace Inconsistency: ; +line (space between delimiter and prefix) failing strict prefix detection.

1. Proposed Solution: Two-Stage Parsing & Heuristic Repair

We have implemented a robust, two-stage parsing architecture in apply-patch/src/parser.rs:

• Stage 1: Strict Parsing (Trusting): Attempts to parse the patch as-is. This preserves the architectural integrity and ensures zero overhead for valid patches.
• Stage 2: Heuristic Repair (Recovery): If Stage 1 fails (and ParseMode is not Strict), a new auto_repair_patch function is invoked.
• Context-Aware Splitting: Uses a heuristic pipeline to split lines only when safe (e.g., after ;, }, ), >, ,, ]).
• Marker Integrity: Precisely identifies markers at the start of trimmed lines and detaches any "tails" (residual text).
• Content Protection: Ensures that strings inside valid diff lines that happen to look like markers are not incorrectly split.

1. Verification Results

The fix has been verified using cargo nextest with a comprehensive suite of edge cases:

• [PASS] test_auto_repair_squashed_lines: Verifies classic ;+ and indented marker splitting.
• [PASS] test_auto_repair_parsing_integrity: Asserted that UpdateFileChunk content matches exactly after repair, ensuring no data loss.
• [PASS] test_parse_patch: Verified that valid, non-squashed patches are still handled correctly without interference.

What steps can reproduce the bug?

<img width="3766" height="854" alt="Image" src="https://github.com/user-attachments/assets/11e9bae5-f19d-4fb8-8996-4cb9b2eff5a1" />

this bug causes two critical operational issues:

• The "Search-Read Storm" (Performance Collapse): When apply_patch fails with an InvalidHunkError, the Agent often misinterprets this as a context gap rather than a

formatting bug. To "fix" it, the Agent triggers an explosion of redundant grep_search and read_file calls to re-verify the codebase. This results in massive token
consumption and extreme latency, while performing zero effective code modifications.

• Circular "Ghost" Edits: Failure to match hunks often forces the Agent into a degenerative "Delete-and-Re-add" loop. The Agent attempts to delete large blocks and re-add

them to bypass matching issues, but since the new output is also squashed, the process repeats indefinitely, often resulting in "0 edits" or corrupted file states.

What is the expected behavior?

solution here:
https://github.com/GTrunSec/codex/tree/fix/apply-patch-line-squashing

Additional information

_No response_