fix(tabufline): prevent invalid buffer ID error on BufAdd event

[StefanBartl]

Fix: Invalid buffer ID error in tabufline lazyload

Problem

nvim_buf_get_name() crashes with "Invalid buffer id" when using preview features in Neo-tree, FZF-lua, or Telescope.

Error:

Error executing lua callback: .../nvchad/tabufline/lazyload.lua:36: Invalid buffer id: 1

Reproduction:

1. Open Neo-tree preview (Tab key)
2. Open the file
3. Error occurs

Cause

Line 36 accesses bufs[1] without validating:

• Table has elements (#bufs > 0)
• Buffer is valid (nvim_buf_is_valid())

Preview buffers can cause bufs to be empty or contain invalid buffer IDs.

Solution

Add validation before accessing bufs[1]:

if args.event == "BufAdd" then
  if #bufs > 0 and api.nvim_buf_is_valid(bufs[1]) then
    if #api.nvim_buf_get_name(bufs[1]) == 0 and not get_opt("modified", { buf = bufs[1] }) then
      table.remove(bufs, 1)
    end
  end
end

[abelfubu]

Please let's merge this fix since the error is pretty annoying 🙏

[siduck]

do those preview features of those plugins not create listed buffers? if yes then they should be added in vim.t.bufs variable automatically

[abelfubu]

It does happen for me with mini.files

[StefanBartl]

@siduck:
From what I’ve observed, preview buffers created by plugins like Neo-tree, Telescope, FZF-lua, or mini are often short-lived and sometimes unlisted, but BufAdd can still fire before the buffer is fully stable. In that window, vim.t.bufs may contain entries that are already invalid by the time tabufline accesses them, which i think leads to the crash.

So even if preview buffers shouldn’t end up in vim.t.bufs, it still can happen because of timing and plugin behavior. The added nvim_buf_is_valid() check is meant as a defensive guard to prevent hard error when that occurs.

I’m not a tabufline maintainer, so you likely have a better view on what the correct long-term handling of preview/unlisted buffers should be. This fix just ensures tabufline doesn’t crash in the meantime when encountering an unexpected or invalid buffer state.

[siduck]

@siduck: From what I’ve observed, preview buffers created by plugins like Neo-tree, Telescope, FZF-lua, or mini are often short-lived and sometimes unlisted, but BufAdd can still fire before the buffer is fully stable. In that window, vim.t.bufs may contain entries that are already invalid by the time tabufline accesses them, which i think leads to the crash.

So even if preview buffers shouldn’t end up in vim.t.bufs, it still can happen because of timing and plugin behavior. The added nvim_buf_is_valid() check is meant as a defensive guard to prevent hard error when that occurs.

you're right. btw can you show a small video of this behavior? i tried the preview buffer feature of nvimtree and it doesnt cause this bug

[StefanBartl]

@siduck: At the moment I can’t reliably reproduce the crash on my current (main) system.

I added extensive logging around BufAdd / BufEnter / BufDelete and tested aggressively with preview-heavy plugins (neo-tree previews, telescope, lazygit, etc.). In all observed cases, vim.t.bufs[1] was valid at the time tabufline accessed it, so the crash didn’t trigger. In that sense, I can understand why you’re not able to reproduce it either.

I’m not 100% sure, but I believe I originally ran into this issue while working for a few days on a different machine — a significantly less powerful system, more comparable to a typical modern laptop than my main PC. I’ll be switching back to that system in the next few days and will continue observing and testing there, since these races seem to be highly environment- and timing-dependent. That might also be an interesting data point for this issue.

That said, even if the crash is not easily reproducible for me right now, it has occurred on other systems as well (@abelfubu), so i think its worthy to keep an eye on it.

I'll report back if I manage to reproduce it again.

[abelfubu]

I can share a recording:

Screen.Recording.2025-12-15.at.17.58.31.mov

[StefanBartl]

I can share a recording:

Screen.Recording.2025-12-15.at.17.58.31.mov

thx for sharing

[StefanBartl]

@siduck i can't reproduce the bug on the other system neither. so, for me the bug is fixed, but i don't know how. @abelfubu you still get the bug?

[abelfubu]

I just tested with a clean config and I don't have the error, so it looks like it's related to my config ...

[siduck]

I just tested with a clean config and I don't have the error, so it looks like it's related to my config ...

comment plugins one by one in your config