[ThomasK33]

Why

The vertical and horizontal diff layouts must hand Claude back the exact text it proposed when the user accepts. A proposal without a final line break came back with one. "a" was accepted as "a\n", "a\nb" as "a\nb\n", and an empty proposal as "\n". Claude then wrote a file with a line break the user never saw in the diff.

What changed

_resolve_diff_as_saved in lua/claudecode/diff.lua saves the lines of the proposal buffer, joined with line breaks. It adds a final line break when the buffer's 'eol' option is on. A new Neovim buffer has 'eol' on, so every saved proposal ended with a line break.

The diff now sets 'eol' on the proposal buffer from the proposal text, right after it sets the buffer's lines in _setup_blocking_diff. The saved text then ends with a line break exactly when the proposal does. The saving code is the same. The user's edits in the buffer still reach Claude and keep the proposal's ending.

lua/claudecode/README.md gets one new bullet that states this. It sits after the bullet about writing the proposed buffer, so it does not touch the line that the unified fix (F11) edits.

Scope

• The vertical and horizontal layouts share one code path, so one change fixes both.
• The unified layout is unchanged. Its no-final-line-break cases are controls in the new spec and pass before and after.
• A proposal that ends in blank lines, one final line break, or no text before the first line break gave the right text before and still does. The new spec covers them in the split layouts as controls.
• The blank-line-ending defect of the unified layout belongs to F11 (fix(diff): keep every trailing blank line in an accepted unified diff #535), not to this PR.
• A pre-existing defect stays out of this PR. In the split layouts, a user who empties the proposal buffer after a proposal that ended in "\n" gets the answer "\n", while Neovim writes an empty file for an empty buffer. It exists on main, and it is not changed here. The follow-up F16 fixes it.

Blast Radius

• User-visible: accepting a split-layout diff of a proposal without a final line break now sends that proposal as it is. A proposal with a final line break sends the same text as before.
• With the default 'diffopt' and 'fixeol', diff mode shows the same highlights, and the proposal buffer is modified as before. I probed both in a real Neovim. With set nofixeol and diffopt-=internal, one case highlights differently, which is a real difference between the endings.
• covered.lock: the change touches _setup_blocking_diff, a covered block. check.sh printed STALE for the diff.lua file hash and the setup_blocking block hash only. It printed no changed call site, and all 21 code facts stay TRUE. The change adds one nvim_buf_set_option call on a buffer that the same function created a few lines before. It sits next to the other buffer option calls and runs in the same pcall. It does not change when the diff registers, when it answers, or how it resolves or closes. So I did not change the model (model/DiffLifecycle.tla). The model passed (main: 89205 distinct states, live-DisconnectedCallsAnswered: 5269). check.sh --record wrote the new lock and check.sh --hash-only reports that it matches.

How this PR merges with F11 and F12

• F12 (fix/server-auth-log-and-cwd-lookup) merges with this branch without a conflict. I checked it with git merge-tree --write-tree.

Merge rule for F11 (#535) and F14

F11 and F14 merge without a text conflict, but each leaves a test that the other makes stale. F11's spec lists 2 vertical cases as pending, because main still adds a final line break there. F14's spec skips 9 unified cases that end in blank lines, because main still drops one of those line breaks.

Whichever of the two PRs lands second must do this in its own merge-from-main commit:

1. Apply the first diff below to F11's tests/integration/diff_accept_trailing_newlines_spec.lua. It replaces the 7-line local case = it pending clause with one it( line, so the 2 vertical no-final-line-break cases run.
2. Apply the second diff below to F14's tests/integration/diff_accept_missing_final_newline_spec.lua. It removes the blank_end skip (the if not (layout == "unified" and proposal.blank_end) then line and its end, the 3 blank_end = true fields and their comment), so the 9 unified blank-line cases run.
3. Show both specs green on the merged tree before its push.

On a trial merge of the two branches with both diffs applied, F11's spec gives 28 successes, 0 failures and 0 pending. F14's spec gives 94 successes, 0 failures and 0 pending.

The two diffs

diff --git a/tests/integration/diff_accept_trailing_newlines_spec.lua b/tests/integration/diff_accept_trailing_newlines_spec.lua
index e619a02e..53a1c735 100644
--- a/tests/integration/diff_accept_trailing_newlines_spec.lua
+++ b/tests/integration/diff_accept_trailing_newlines_spec.lua
@@ -78,13 +78,7 @@ describe("the text a proposed diff accepts", function()
     describe("in the " .. layout .. " layout", function()
       for _, old_file in ipairs(old_files) do
         for _, proposal in ipairs(proposals) do
-          -- The vertical layout writes a final line break after a proposal that has none. That is not what the
-          -- unified fix changes, so this case stays pending there.
-          local case = it
-          if layout == "vertical" and proposal.text:sub(-1) ~= "\n" then
-            case = pending
-          end
-          case(("keeps %s of a proposal against %s"):format(proposal.name, old_file.name), function()
+          it(("keeps %s of a proposal against %s"):format(proposal.name, old_file.name), function()
             local state = open_diff(layout, old_file.text, proposal.text)
 
             vim.api.nvim_set_current_win(state.new_window)

diff --git a/tests/integration/diff_accept_missing_final_newline_spec.lua b/tests/integration/diff_accept_missing_final_newline_spec.lua
index dc501c6a..d579a8f5 100644
--- a/tests/integration/diff_accept_missing_final_newline_spec.lua
+++ b/tests/integration/diff_accept_missing_final_newline_spec.lua
@@ -71,8 +71,6 @@ describe("the text a proposed diff accepts, by how the proposal ends", function(
     end)
   end
 
-  -- `blank_end` marks a proposal that ends in a blank line. On main the unified layout drops one of those (F11 fixes
-  -- that), so this file runs them in the split layouts only.
   local proposals = {
     { name = "a final line without a line break", text = "a" },
     { name = "two lines and no final line break", text = "a\nb" },
@@ -81,9 +79,9 @@ describe("the text a proposed diff accepts, by how the proposal ends", function(
     { name = "one final line break", text = "a\n" },
     { name = "two lines and a final line break", text = "a\nb\n" },
     { name = "a blank line only", text = "\n" },
-    { name = "one blank line after the last line", text = "a\n\n", blank_end = true },
-    { name = "two blank lines after the last line", text = "a\n\n\n", blank_end = true },
-    { name = "two blank lines only", text = "\n\n", blank_end = true },
+    { name = "one blank line after the last line", text = "a\n\n" },
+    { name = "two blank lines after the last line", text = "a\n\n\n" },
+    { name = "two blank lines only", text = "\n\n" },
   }
   local old_files = {
     { name = "a file with other text", text = "old\n" },
@@ -95,13 +93,11 @@ describe("the text a proposed diff accepts, by how the proposal ends", function(
     describe("in the " .. layout .. " layout", function()
       for _, old_file in ipairs(old_files) do
         for _, proposal in ipairs(proposals) do
-          if not (layout == "unified" and proposal.blank_end) then
-            it(("accepts %s as it is, against %s"):format(proposal.name, old_file.name), function()
-              local state = open_diff(layout, old_file.text, proposal.text)
+          it(("accepts %s as it is, against %s"):format(proposal.name, old_file.name), function()
+            local state = open_diff(layout, old_file.text, proposal.text)
 
-              assert.equal(vim.inspect(proposal.text), vim.inspect(accept(state)))
-            end)
-          end
+            assert.equal(vim.inspect(proposal.text), vim.inspect(accept(state)))
+          end)
         end
       end
     end)

Verification

Red before the fix, green after (same spec, only lua/claudecode/diff.lua swapped):

Spec	origin/main	with the fix
tests/integration/diff_accept_missing_final_newline_spec.lua (85 cases, real Neovim, :write)	59 successes, 26 failures	85 successes, 0 failures

The spec runs ten proposals against three old files (other text, no final line break, and no file yet) in the vertical and horizontal layouts. The proposals end in no line break ("a", "a\nb", an empty proposal, "a\n\nb"), in one line break ("a\n", "a\nb\n", "\n") or in blank lines ("a\n\n", "a\n\n\n", "\n\n"). Each case compares the answer to the proposal byte for byte. The 26 red cases are the 24 no-line-break cases of the two split layouts and the 2 edit cases. The unified layout runs the 7 proposals that do not end in blank lines against the same three old files (21 cases, all green before and after). Four more cases append a line to the buffer after it opens, in both split layouts. They show that edits still reach Claude and keep the ending.

Gates on the final commit, which merges origin/main (036427a) into the branch (private XDG folders):

• mise run all: native exit 0. luacheck: 0 warnings / 0 errors in 179 files. busted: 1682 successes / 0 failures / 0 errors / 25 pending. treefmt: 0 files changed.
• mise run format-check: native exit 0 (356 files, 0 changed).
• Diff specs (tests/unit/diff*_spec.lua, opendiff_blocking_spec, new_file_reject_then_reopen_spec, and the open_diff_mcp, close_tab and close_all_diff_tabs specs): 222 successes, 0 failures.
• scripts/run_integration_tests_individually.sh: 416 successes, 0 failed, 0 errors. The new spec gives 85 successes.
• .agents/skills/verify-diff-lifecycle/check.sh --hash-only: covered.lock matches the code.

Two independent verifiers (Opus and GPT) checked the code commit before the later spec-comment commit and the merge with origin/main. Both found no introduced defect. Their minor findings are in the branch (the spec comment and a case name) and in this body.

---

Generated with xum • Model: anthropic:claude-sonnet-5-5 • Thinking: xhigh

[ThomasK33]

@codex review

[ThomasK33]

@codex security review

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-12T04:00:48.090929Z	062aa8d	Manual request
🔒 Security Review	✅ Completed 2026-11-12T04:01:12.610311Z	062aa8d	Manual request

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep it up!

Reviewed commit: 062aa8de57

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

🛡️ Codex Security Review

Security review completed. No security issues were found in this pull request.

Reviewed commit: 062aa8de57

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.