GeezerVison

PR Checklist

• The commit message follows our guidelines: Code of conduct
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)
• Does this PR introduce a breaking change?
• Include PR in release notes?

PR Type

• Bugfix

What is the current behavior?

Issue Number: #1129

ModifyCode's save_file_contents always writes with Python's default newline translation, discarding a file's original line-ending style. When a patchflow modifies one line in a file that uses CRLF (\r\n) endings, the whole file gets rewritten with LF (\n) endings, so the generated diff shows every line in the file as changed instead of just the actual edit — exactly as described in the issue.

What is the new behavior?

• replace_code_in_file now detects the file's original newline style (via the existing detect_newline() utility in patchwork/common/utils/utils.py) before editing, and save_file_contents now accepts and honors a newline parameter, writing the patched file back with its original line endings preserved.
• This mirrors the pattern already used by the agentic code-edit tools (patchwork/common/tools/code_edit_tools.py), which handle this correctly today — ModifyCode was the one write path that didn't.
• ModifyCode/README.md documents the new line-ending preservation behavior.
• Added a regression test in tests/steps/test_ModifyCode.py, verified to fail without the fix (CRLF flattened to LF) and pass with it.

Other information

Traced every file-write path in the codebase to confirm ModifyCode.save_file_contents was the only one missing this handling — code_edit_tools.py's agentic tool-edit path already does this correctly via the same detect_newline() utility, which this fix now reuses rather than reimplementing.