[ThomasK33]

diff_failed_setup_guards_spec.lua ended Neovim 0.8.0 early with exit 0 and no plenary summary in a few of 100 runs. The cause is a LuaJIT bug in Neovim 0.8.0 that a user can hit too. This PR works around it in diff.lua and adds a case that fails without the workaround.

Root cause

1. The child Neovim of the spec does not exit 0. It dies of SIGABRT (exit 134) with LuaJIT ASSERT lj_api.c:40: index2adr: bad stack slot -1. The same scenario can also end in SIGSEGV (exit 139): 16 of 125 failed runs of my eager-JIT loop did, and an independent verifier saw 4 of 4 on main with a stand-in terminal layout. I took no backtrace of a SIGSEGV. I assume it is the same bug, because it needs the same scenario and the workaround removes it. plenary's harness only checks code ~= 0 of the child, not signal, so the outer Neovim exits 0 and the runner prints FAILED: ... no plenary summary (nvim exit 0).
2. CI run 43124619585 (job integration-tests (v0.8.0)) prints LuaJIT ASSERT lj_api.c:40: index2adr: bad stack slot -1 right before the FAILED line. Run 43131434527 shows only the FAILED line. My local runs also lose that line in some aborts, because Neovim's buffered output dies with the process. The Neovim 0.8.0 release commit builds its LuaJIT with CFLAGS+=-DLUA_USE_APICHECK (cmake.deps/cmake/BuildLuajit.cmake), so a bad API call aborts. A LuaJIT without that flag takes the same path but, by the source of lib_aux.c and lj_err.c, prints PANIC: unprotected error in call to Lua API and exits 1. I did not run such a build.
3. A C backtrace of the abort (SIGABRT handler through LD_PRELOAD, addresses resolved with addr2line) reads: lua_error called from the Lua VM, then err_unwind finds no protecting frame, then panic calls lua_tostring(L, -1) on an empty stack, which trips the assert.
4. The trigger is LuaJIT issue #1066, fixed upstream by commit e86990f7f (21 September 2023, "Restore cur_L for specific Lua/C API use case"). Neovim 0.8.0 bundles LuaJIT 633f265f (10 August 2022). A Neovim API function runs the user's autocmd callbacks on the main Lua thread. If one callback raises, the API function raises too. When that happens inside a coroutine, LuaJIT leaves G->cur_L pointing at the main thread. The next JIT trace exit then restores a snapshot into the wrong stack, and a later nested call trips over it. I did not step through LuaJIT to watch each of these steps. The controls below and the upstream fix support them.
5. tools.handle_invoke runs openDiff in a coroutine (requires_coroutine). So the product hits the bug in production too, not only the spec under plenary. A user whose WinLeave, BufLeave or BufWinEnter handler raises can lose Neovim on Neovim 0.8.0. Neovim 0.12.3 (LuaJIT 2.1.1774638290) is not affected.

Evidence

Controls on the minimal repro below (Neovim 0.8.0): JIT off survives, no coroutine survives, a callback that does not raise survives, no trace exit survives, one API call that returns between the raise and the trace exit survives. That last control is the workaround.

Run	Neovim 0.8.0	Neovim 0.12.3
minimal repro luajit1066b.lua	aborts in most runs: 10 of 10 in my run, 27 of 30 in a rerun by a verifier	0 abort in 10 runs
all 24 integration specs but selection_held_spec.lua, eager JIT, 3 runs each	only diff_failed_setup_guards_spec.lua aborts	not run

Minimal repro: nvim --headless -u NONE -i NONE -c "luafile luajit1066b.lua"

-- LuaJIT #1066 through Neovim: after the stale cur_L, a trace exit corrupts the main thread's stack,
-- which a later nested callback (autocmd) then trips over.
jit.opt.start("hotloop=1")
local function onesnap_f(var)
  if var then return 1 else return 0 end
end
local N = tonumber(vim.env.N or "3")
vim.cmd("tabnew")
local other = vim.api.nvim_list_tabpages()[1]
local mine = vim.api.nvim_get_current_tabpage()
local raise = true
vim.api.nvim_create_autocmd({ "WinLeave", "BufLeave" }, { callback = function() if raise then error("an autocmd callback of the user raised") end end })

coroutine.wrap(function()
  for i = 1, N do
    onesnap_f(true); onesnap_f(true)
    local ok = pcall(vim.api.nvim_set_current_tabpage, other)
    onesnap_f(false)
    ok = pcall(vim.api.nvim_set_current_tabpage, mine)
    onesnap_f(false)
  end
  io.stderr:write("SURVIVED\n")
  vim.cmd("0cq")
end)()

Fix

_setup_blocking_diff makes one vim.api.nvim_get_current_tabpage() call before it rethrows "Diff setup failed". An API call that returns normally sets cur_L back to the running coroutine. One call before the rethrow was enough in every flow I measured. A call after the setup pcall alone was not (see the placement table below). I did not change any other pcall.

Counts

Run (Neovim 0.8.0 unless noted)	Result
Before: loop-spec.sh style loop of the spec on main ed1e0873, 6 parallel loops of 20	7 bad of 120 (no plenary summary, exit 0)
Before: the child Neovim run directly (exit status recorded), 6 parallel loops	3 bad of 120 and 4 bad of 150, every one exit 134
After: this branch, 6 parallel loops of 34	204 ok, 0 bad
After: this branch on Neovim 0.12.3, 5 parallel loops of 20	100 ok, 0 bad
Mutation check: this branch with the 7 added lines of diff.lua removed, 4 parallel loops of 12	37 bad of 48
Production-shaped repro (tools.handle_invoke from the main thread, no plenary, default JIT, 40 failed setups per run), 6 runs	origin/main: 6 abort. This branch: 6 ok

The new case (keeps Neovim running when handlers raise on repeated failed setups under an eager JIT) sets jit.opt.start("hotloop=1", "hotexit=1", "tryside=1"), runs the three raising-handler cases twice (6 passes) and restores LuaJIT's defaults. An eager JIT raises the abort rate from a few in 100 to most runs when the workaround is missing. It does not catch every missing workaround: 11 of 48 runs survived in the mutation measurement above.

Placement of the call, measured on the original spec under an eager JIT (2 passes, 4 parallel loops of 8; bad = no summary):

Where the call is	Bad
nowhere (main)	23 of 32
after the setup pcall only	27 of 32
before the rethrow only	0 of 32
after the tabclose and the last set_current_tabpage	0 of 32

Gates

• luacheck lua/ tests/ --no-unused-args --no-max-line-length: 0 warnings, 0 errors. stylua --check lua tests: clean.
• Unit suite without coverage (busted --shuffle --seed=7777, all *_spec.lua and *_test.lua): 1693 successes, 0 failures, 0 errors, 25 pending.
• scripts/run_integration_tests_individually.sh: Neovim 0.12.3 Total Success 417, Failed 0, Errors 0. Neovim 0.8.0 (the CI binary, v0.8.0-1210-gd367ed9b2) Total Success 309, Failed 0, Errors 0.
• .agents/skills/verify-diff-lifecycle/check.sh: all facts TRUE and the model passes (main 89205 distinct states, live-DisconnectedCallsAnswered 5269). The change adds one API read before an error that already ends the setup, so no guard changes. covered.lock is re-recorded with --record, and --hash-only matches after merging origin/main (de309ae, with fix(terminal): keep the native start going when an autocmd closes its split #527). The numbers in this section are from head 3492410.

Limits

• The workaround covers the failed setup, the path of openDiff that ends in a rethrow from the coroutine. The accept and reject cleanup does not run in that coroutine: _resolve_diff_as_saved and _resolve_diff_as_rejected run from autocmds and commands on the main thread, and close_tab runs under pcall in tools.handle_invoke, also without a coroutine. The other code that runs in the openDiff coroutine is the replace cleanup, the ClaudeCodeDiffOpened event and the float hide. I did not run those paths. An independent verifier ran them under an eager JIT on Neovim 0.8.0, and they survive on this head. Its replace scenario aborted 4 of 4 runs on main. The real fix is a LuaJIT from September 2023 or later.
• The new case makes the spec take about 6 s per run at a host load of 12 to 15, on both Neovim versions. It took about 1.6 s on main. The runner allows 40 s per file.

---

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-12T05:05:35.820238Z	3492410	Manual request
🔒 Security Review	✅ Completed 2026-11-12T05:03:26.132891Z	3492410	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 them coming!

Reviewed commit: 2bc1d222b0

ℹ️ 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: 2bc1d222b0

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.

[ThomasK33]

@codex review

[ThomasK33]

@codex security review

[chatgpt-codex-connector]

🛡️ Codex Security Review

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

Reviewed commit: 3492410ec6

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.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Nice work!

Reviewed commit: 3492410ec6

ℹ️ 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".