[BUG] ClaudeCodeSend misclassifies regular buffers as tree buffers when file path contains "neo-tree" or "NvimTree"

[gogongxt]

Bug Description

ClaudeCodeSend misclassifies a regular file buffer as a "tree buffer" when the file path (not filetype) contains the substring neo-tree, NvimTree, or minifiles://. This causes visual selection sends to fail with:

ClaudeCode Error [ClaudeCode] [command] [ERROR] ClaudeCodeSend_visual->TreeAdd: Not in visual mode (current mode: n)

The root cause is in lua/claudecode/init.lua, where is_tree_buffer is determined by both filetype and substring matching against the buffer name:

local is_tree_buffer = current_ft == "NvimTree"
  or current_ft == "neo-tree"
  or current_ft == "oil"
  or current_ft == "minifiles"
  or current_ft == "netrw"
  or string.match(current_bufname, "neo%-tree")    -- ← false positive
  or string.match(current_bufname, "NvimTree")     -- ← false positive
  or string.match(current_bufname, "minifiles://")

When a user opens a file whose path contains one of those substrings (for example a Neovim config file named _neo-tree.lua, or anything under a directory called nvim-tree-config/), is_tree_buffer evaluates to true even though filetype is something like lua. The visual handler then tries to use tree-specific extraction via get_files_from_visual_selection, but:

1. capture_visual_selection_data() returns nil because get_tree_state() correctly returns nil for a non-tree buffer.
2. ESC has already been fed to exit visual mode.
3. get_files_from_visual_selection(nil) calls validate_visual_mode(), which fails because we're now in normal mode → error logged.

This also affects the handle_send_normal path at lines 732-740 with the same string.match checks.

To Reproduce

Steps to reproduce:

1. Create a file whose path contains the substring neo-tree, e.g. ~/.config/nvim/lua/plugins/_neo-tree_.lua.
2. Open it in Neovim: nvim ~/.config/nvim/lua/plugins/_neo-tree_.lua.
3. Start Claude Code: :ClaudeCodeStart (or whichever command you use).
4. In the lua buffer, visually select a few lines and run :'<,'>ClaudeCodeSend (or the user's <leader>as mapping which calls ClaudeCodeSend).

Expected: the visual selection is sent to Claude.
Actual: error notification ClaudeCodeSend_visual->TreeAdd: Not in visual mode (current mode: n), nothing is sent.

Files whose paths do not contain neo-tree / NvimTree / minifiles:// work fine — which is why this bug appears intermittent (some files send, some don't).

Expected Behavior

is_tree_buffer should be determined by filetype only. The string.match(current_bufname, ...) checks are false positives — a regular file whose path happens to contain those substrings is not a tree buffer.

Environment

• Neovim version: NVIM v0.12.2
• Claude Code CLI version: 2.1.153
• OS: macOS 15
• Plugin version: 0.3.0 (commit e6c9dd4d4f144910b0066489100ad94b7133821f)

Suggested Fix

Remove the string.match(current_bufname, ...) lines from both handle_send_normal (around line 738-740) and handle_send_visual (around line 793-795). The filetype checks above them are sufficient and correct.

     local is_tree_buffer = current_ft == "NvimTree"
       or current_ft == "neo-tree"
       or current_ft == "oil"
       or current_ft == "minifiles"
       or current_ft == "netrw"
-      or string.match(current_bufname, "neo%-tree")
-      or string.match(current_bufname, "NvimTree")
-      or string.match(current_bufname, "minifiles://")

The minifiles:// check may still be needed if minifiles uses a virtual buffer name without setting filetype = "minifiles" — worth confirming with the minifiles integration. But the neo-tree and NvimTree substring checks appear redundant with the filetype checks and should be safe to remove.

Additional Context

Workaround for affected users: rename files so their paths don't contain neo-tree / NvimTree, or map the send key to a custom wrapper that calls send_at_mention_for_visual_selection directly instead of ClaudeCodeSend.

[ThomasK33]

Note

This triage report is AI-generated using Claude Code

Summary — confirmed bug

The reported behaviour was reproduced and confirmed, and the root-cause analysis in the original report is accurate. ClaudeCodeSend classifies the current buffer as a file-explorer ("tree") buffer using a substring match against the buffer name (which is the file's absolute path) in addition to the filetype. As a result, any ordinary filetype=lua file whose path merely contains neo-tree or NvimTree is misclassified, and the visual/range send is routed into tree-extraction and fails.

How it was reproduced

Two independent reproductions were produced.

• Live, by driving a real Neovim (Neovim 0.13-dev — the logic under test is filetype/bufname based and is version-independent) with the README-default mapping { "<leader>as", "<cmd>ClaudeCodeSend<cr>", mode = "v" } on a plain filetype=lua file named _neo-tree_.lua. The exact reported error is produced (notification title ClaudeCode Error):

  [ClaudeCode] [command] [ERROR] ClaudeCodeSend_visual->TreeAdd: Not in visual mode (current mode: n)
  

• Headless / deterministic, via a script that drives the real :ClaudeCodeSend command and exits non-zero while the bug is present (exit 1 on current code, 0 once fixed).

The buffer's classification state was captured directly on the affected file:

{ "filetype": "lua", "matches_filetype": false, "matches_bufname": true, "is_tree_buffer": true }

filetype is lua and is correctly not a tree filetype, yet is_tree_buffer becomes true purely from the path substring.

Behaviour matrix — the two files below differ only in their path:

File (filetype=lua)	is_tree_buffer	<leader>as (visual)	:'<,'>ClaudeCodeSend (range)
_neo-tree_.lua	true (bug)	ClaudeCodeSend_visual->TreeAdd: Not in visual mode (current mode: n)	ClaudeCodeSend->TreeAdd: Not in a supported tree buffer (current filetype: lua)
regular_plugin.lua	false	sends correctly, no error	sends correctly, no error

Root cause

In lua/claudecode/init.lua, both handle_send_normal (~L732‑740) and handle_send_visual (~L788‑795) OR the filetype check with a substring match on the buffer name:

or string.match(current_bufname, "neo%-tree")    -- matches any path containing "neo-tree"
or string.match(current_bufname, "NvimTree")     -- matches any path containing "NvimTree"
or string.match(current_bufname, "minifiles://")

Importantly, the two downstream extractors — integrations.get_selected_files_from_tree() and visual_commands.get_tree_state() — classify by filetype only. A buffer matched as a tree purely via its name therefore cannot extract anything: it is guaranteed to hit the TreeAdd error path. These substring checks can only ever divert a normal text selection into a failing branch; they can never enable a successful tree extraction.

Why the checks exist (history)

A review of the git history indicates the buffer-name substring checks were introduced speculatively and were never backed by real plugin behaviour:

• The neo%-tree and NvimTree substring checks were added in the first tree-integration change (PR feat: add nvim-tree and neotree integration #22, "Fixes [FEATURE] Add nvim-tree integration to add file in explorer to mention file name in claude code #14"). In that same change, the extractors were already filetype-only, so a name-only match could not have succeeded.
• The minifiles:// check was added together with mini.files support (PR feat: add mini.files support #89), alongside a current_ft == "minifiles" check that already covers the case.
• Later filetype additions (oil/netrw in PR feat: support netrw file selection #62, snacks in PR feat(integrations): support ClaudeCodeTreeAdd in snacks.nvim pickers (#192) #269) each added only a filetype branch and no corresponding buffer-name branch, which indicates the substring pattern was not a deliberately maintained mechanism.

Suggested fix

Classification by filetype only is recommended — this matches what the extractors and the explorers themselves already rely on:

   local function handle_send_normal(opts)
     local current_ft = (vim.bo and vim.bo.filetype) or ""
-    local current_bufname = (vim.api and vim.api.nvim_buf_get_name and vim.api.nvim_buf_get_name(0)) or ""

     local is_tree_buffer = current_ft == "NvimTree"
       or current_ft == "neo-tree"
       or current_ft == "oil"
       or current_ft == "minifiles"
       or current_ft == "netrw"
       or current_ft == "snacks_picker_list"
-      or string.match(current_bufname, "neo%-tree")
-      or string.match(current_bufname, "NvimTree")
-      or string.match(current_bufname, "minifiles://")

   local function handle_send_visual(visual_data, opts)
     -- Check if we're in a tree buffer first
     local current_ft = (vim.bo and vim.bo.filetype) or ""
-    local current_bufname = (vim.api and vim.api.nvim_buf_get_name and vim.api.nvim_buf_get_name(0)) or ""

     local is_tree_buffer = current_ft == "NvimTree"
       or current_ft == "neo-tree"
       or current_ft == "oil"
       or current_ft == "minifiles"
       or current_ft == "netrw"
-      or string.match(current_bufname, "neo%-tree")
-      or string.match(current_bufname, "NvimTree")
-      or string.match(current_bufname, "minifiles://")

       -- For mini.files, try to get the range from visual marks for accuracy
-      if current_ft == "minifiles" or string.match(current_bufname, "minifiles://") then
+      if current_ft == "minifiles" then

Removing the minifiles:// check is safe: real mini.files buffers set filetype = "minifiles" (verified against the pinned mini.files source used by this repo's fixture), so the filetype branch fully covers them. It is also worth noting that minifiles:// was never a cause of this issue — a real filesystem path cannot contain ://, so only the neo-tree / NvimTree substrings produce the false positives. (If buffer-name matching is ever wanted for symmetry, an anchored URI prefix such as ^minifiles:// / ^oil:// should be used rather than an unanchored substring; no upstream explorer relies on an unanchored match.)

Two related observations (out of scope for this issue)

• snacks_picker_list asymmetry: the snacks_picker_list filetype is present in handle_send_normal but absent from handle_send_visual, and there is no snacks branch in get_tree_state / get_files_from_visual_selection. A visual-mode send from a snacks picker is therefore currently unsupported (not merely misrouted), so a correct fix would need end-to-end support. This is best tracked separately.
• Structural: tree-buffer classification is duplicated across four sites (the two predicates above plus the two extractors), which is why they have drifted apart. A single shared helper would prevent recurrence.

Test gap

The existing tests/unit/tree_send_visual_spec.lua mocks the visual-commands wrapper, so the real is_tree_buffer predicate is never exercised — which is why this was not caught. A fix should add a spec that drives the real predicate (a filetype=lua buffer whose path contains neo-tree must not be routed into tree extraction).

Workaround (until a fix lands)

Affected files can be renamed so their path does not contain neo-tree / NvimTree, or the send key can be mapped to a small wrapper that calls require("claudecode.selection").send_at_mention_for_visual_selection() directly instead of :ClaudeCodeSend.

---

scripts/repro_issue_289.lua — headless reproduction (exit 1 = bug present, 0 = fixed)

-- Reproduction / verification for issue #289:
--   "[BUG] ClaudeCodeSend misclassifies regular buffers as tree buffers when
--    file path contains 'neo-tree' or 'NvimTree'"
--   https://github.com/coder/claudecode.nvim/issues/289
--
-- The bug: handle_send_normal and handle_send_visual (lua/claudecode/init.lua)
-- decide whether the current buffer is a file-explorer ("tree") buffer using
-- BOTH the filetype AND a substring match against the buffer NAME:
--
--     local is_tree_buffer = current_ft == "NvimTree"
--       or current_ft == "neo-tree" or current_ft == "oil"
--       or current_ft == "minifiles" or current_ft == "netrw"
--       or string.match(current_bufname, "neo%-tree")    -- false positive
--       or string.match(current_bufname, "NvimTree")     -- false positive
--       or string.match(current_bufname, "minifiles://")
--
-- So an ordinary `lua` file whose PATH merely contains "neo-tree" / "NvimTree"
-- (e.g. a plugin spec named `_neo-tree_.lua`) is treated as a tree buffer, and
-- a visual send is routed into tree-extraction instead of the normal selection
-- path. Result, depending on how the command is invoked:
--   * `:'<,'>ClaudeCodeSend`        -> ClaudeCodeSend->TreeAdd: Not in a
--                                       supported tree buffer (current filetype: lua)
--   * <leader>as (`<cmd>...<cr>`)   -> ClaudeCodeSend_visual->TreeAdd: Not in
--                                       visual mode (current mode: n)
-- ...and nothing is sent to Claude.
--
-- This script drives the REAL `:ClaudeCodeSend` user command (registered by
-- claudecode.setup) against both an affected buffer and a control buffer, with
-- no WebSocket / Claude CLI needed. It reproduces the bug on unfixed code and
-- will verify a fix.
--
-- Run from the repo root:
--   nvim --headless -u NONE -l scripts/repro_issue_289.lua
--
-- Exit code: 1 if the misclassification is observed (#289 reproduced), 0 if the
-- affected buffer behaves like the control (fixed). A detailed verdict is
-- printed either way.

vim.g.mapleader = " " -- must be set before the <leader> mapping is created
vim.g.maplocalleader = "\\"

local script_path = debug.getinfo(1, "S").source:sub(2)
local repo_root = vim.fn.fnamemodify(script_path, ":h:h")
vim.opt.rtp:prepend(repo_root)

local function out(msg)
  io.stdout:write(msg .. "\n")
end

-- Capture (and swallow) ClaudeCode notifications so we can assert on the error
-- text without it cluttering the output.
local captured = {}
vim.notify = function(msg, level, opts)
  table.insert(captured, { message = tostring(msg), level = level, title = opts and opts.title or nil })
end
-- The logger wraps notify in vim.schedule; nvim_echo is used for lower levels.
local orig_echo = vim.api.nvim_echo
vim.api.nvim_echo = function() end

local cc = require("claudecode")
cc.setup({
  auto_start = false,
  log_level = "info",
  terminal = { provider = "none" },
})
-- A server object only matters for the *downstream* send; the misclassification
-- happens before that. Provide a stub so the "correct" path can complete.
cc.state.server = cc.state.server or {
  broadcast = function()
    return true
  end,
}

-- Spy on the two mutually-exclusive downstream paths.
local selection = require("claudecode.selection")
local sent = { count = 0, args = nil }
selection.send_at_mention_for_visual_selection = function(l1, l2)
  sent.count = sent.count + 1
  sent.args = { l1, l2 }
  return true
end

local integrations = require("claudecode.integrations")
local tree = { count = 0 }
integrations.get_selected_files_from_tree = function()
  tree.count = tree.count + 1
  -- Mirror the real error text for a non-tree filetype.
  return {}, "Not in a supported tree buffer (current filetype: lua)"
end

-- README-default visual mapping (the reporter's mapping). `<cmd>...<cr>` keeps
-- visual mode, which routes into handle_send_visual.
vim.keymap.set("v", "<leader>as", "<cmd>ClaudeCodeSend<cr>")

local LUA_LINES = {
  "return {",
  '  "nvim-neo-tree/neo-tree.nvim",',
  "  branch = 'v3.x',",
  "  config = function() end,",
  "}",
}

local function open_buffer(path)
  vim.cmd("enew!")
  local buf = vim.api.nvim_get_current_buf()
  vim.api.nvim_buf_set_name(buf, path)
  vim.api.nvim_buf_set_lines(buf, 0, -1, false, LUA_LINES)
  vim.bo[buf].filetype = "lua"
  vim.api.nvim_win_set_cursor(0, { 1, 0 })
  return buf
end

local function first_treeadd_error()
  for _, n in ipairs(captured) do
    if n.message:match("TreeAdd") then
      return n.message
    end
  end
  return nil
end

-- Exercise both invocation styles against one buffer.
---@return table result {range_sent, range_tree, range_err, visual_err}
local function exercise(path)
  open_buffer(path)

  -- (1) Range path: `:1,3ClaudeCodeSend` (mode is normal -> handle_send_normal)
  captured, sent.count, tree.count = {}, 0, 0
  pcall(function()
    vim.cmd("1,3ClaudeCodeSend")
  end)
  vim.wait(60)
  local range_sent = sent.count
  local range_tree = tree.count
  local range_err = first_treeadd_error()

  -- (2) Visual path: real visual selection + <leader>as (-> handle_send_visual)
  captured, sent.count, tree.count = {}, 0, 0
  vim.api.nvim_win_set_cursor(0, { 1, 0 })
  local keys = vim.api.nvim_replace_termcodes("Vjj as", true, false, true)
  pcall(function()
    vim.api.nvim_feedkeys(keys, "x", false)
  end)
  vim.wait(120)
  local visual_err = first_treeadd_error()
  local visual_sent = sent.count

  return {
    range_sent = range_sent,
    range_tree = range_tree,
    range_err = range_err,
    visual_err = visual_err,
    visual_sent = visual_sent,
  }
end

out("== issue #289 reproduction (path-substring tree misclassification) ==")
out(("Neovim: %s"):format(tostring(vim.version())))

local AFFECTED = vim.fn.tempname() .. "/lua/plugins/_neo-tree_.lua"
local CONTROL = vim.fn.tempname() .. "/lua/plugins/regular_plugin.lua"

local affected = exercise(AFFECTED)
local control = exercise(CONTROL)

local function report(label, path, r)
  out(("\n[%s]  %s"):format(label, path))
  out(
    ("  range  : sent=%d tree_extract=%d  %s"):format(
      r.range_sent,
      r.range_tree,
      r.range_err and ("ERROR: " .. r.range_err:gsub("%s+", " ")) or "(no TreeAdd error)"
    )
  )
  out(
    ("  visual : sent=%d  %s"):format(
      r.visual_sent,
      r.visual_err and ("ERROR: " .. r.visual_err:gsub("%s+", " ")) or "(no TreeAdd error)"
    )
  )
end

report("AFFECTED", AFFECTED, affected)
report("CONTROL ", CONTROL, control)

-- Verdict.
-- Bug present iff the AFFECTED buffer is misrouted into tree extraction on the
-- (deterministic) range path while the CONTROL buffer is sent correctly.
local affected_misrouted = (affected.range_sent == 0 and affected.range_tree > 0)
local affected_visual_err = (affected.visual_err ~= nil)
local control_ok = (control.range_sent == 1 and control.range_tree == 0 and control.range_err == nil)

out("\n== verdict ==")
out(("  control behaves correctly      : %s"):format(tostring(control_ok)))
out(("  affected misrouted (range)     : %s"):format(tostring(affected_misrouted)))
out(("  affected errored (visual path) : %s"):format(tostring(affected_visual_err)))

if affected_misrouted and control_ok then
  out("\nRESULT: #289 REPRODUCED -- a `lua` buffer whose path contains 'neo-tree'")
  out("        is misclassified as a tree buffer and the send fails.")
  vim.cmd("cquit 1")
else
  out("\nRESULT: not reproduced -- affected buffer behaves like the control (fixed).")
  vim.cmd("cquit 0")
end

fixtures/issue-289/init.lua — fixture config + :ReproState / :ReproDump helpers

-- Repro fixture for issue #289:
--   "[BUG] ClaudeCodeSend misclassifies regular buffers as tree buffers when
--    file path contains 'neo-tree' or 'NvimTree'"
--
-- Root cause (lua/claudecode/init.lua, handle_send_normal + handle_send_visual):
-- a buffer is classified as a file-explorer ("tree") buffer not only by its
-- FILETYPE but also by a substring match against its BUFFER NAME:
--
--     local is_tree_buffer = current_ft == "NvimTree"
--       or current_ft == "neo-tree"
--       or ...
--       or string.match(current_bufname, "neo%-tree")    -- false positive
--       or string.match(current_bufname, "NvimTree")     -- false positive
--       or string.match(current_bufname, "minifiles://")
--
-- So a perfectly ordinary file whose PATH happens to contain one of those
-- substrings (e.g. a Neovim plugin spec at lua/plugins/_neo-tree_.lua, or any
-- file under a directory called nvim-tree-config/) is mistaken for a tree.
--
-- Symptom, visual path (the README-default `<leader>as` keymap uses
-- `<cmd>ClaudeCodeSend<cr>`, which KEEPS the buffer in visual mode):
--   1. wrapper sees mode == "v" -> exit_visual_and_schedule(visual_handler)
--   2. capture_visual_selection_data() returns nil (get_tree_state() is nil for
--      a real `lua` buffer) and <Esc> is fed, dropping us into normal mode
--   3. handle_send_visual: is_tree_buffer == true (bufname match) -> takes the
--      tree branch -> get_files_from_visual_selection(nil) -> validate_visual_mode()
--      now fails because the mode is "n" -> logs:
--        ClaudeCodeSend_visual->TreeAdd: Not in visual mode (current mode: n)
--   ...and nothing is ever sent to Claude.
--
-- Symptom, normal/range path (`:'<,'>ClaudeCodeSend`): mode is "n", so
-- handle_send_normal runs; is_tree_buffer is still true, so it calls
-- integrations.get_selected_files_from_tree(), which fails with:
--   ClaudeCodeSend->TreeAdd: Not in a supported tree buffer (current filetype: lua)
--
-- A control file whose path has NONE of those substrings works correctly.
--
-- Usage (from repo root):
--   source fixtures/nvim-aliases.sh
--   vv issue-289 'lua/plugins/_neo-tree_.lua'   # AFFECTED (path has 'neo-tree')
--   vv issue-289 'lua/regular_plugin.lua'       # CONTROL (no substring)
-- or directly:
--   NVIM_APPNAME=issue-289 XDG_CONFIG_HOME=fixtures \
--     nvim fixtures/issue-289/lua/plugins/_neo-tree_.lua
--
-- Commands provided for automation:
--   :ReproDump [path]   write captured ClaudeCode notifications as JSON to `path`
--                       (defaults to stdpath('cache')/issue289_notifications.json)
--   :ReproClear         clear the captured-notification buffer

local config_dir = vim.fn.stdpath("config")
local repo_root = vim.fn.fnamemodify(config_dir, ":h:h")
vim.opt.rtp:prepend(repo_root)

vim.g.mapleader = " "
vim.g.maplocalleader = "\\"

-- A little extra command height keeps long error notifications from triggering
-- the blocking hit-enter prompt while driving Neovim with agent-tty.
vim.o.cmdheight = 3
vim.o.more = false

-- Capture every ClaudeCode notification so automation can assert on it without
-- scraping the screen. We still forward to the original handler so the error is
-- also visible in a screenshot.
_G._repro_notifications = {}
local original_notify = vim.notify
vim.notify = function(msg, level, opts)
  table.insert(_G._repro_notifications, {
    message = tostring(msg),
    level = level,
    title = opts and opts.title or nil,
  })
  return original_notify(msg, level, opts)
end

local ok, claudecode = pcall(require, "claudecode")
assert(ok, "Failed to load claudecode.nvim from repo root: " .. tostring(claudecode))

claudecode.setup({
  auto_start = false,
  -- ERROR notifications fire regardless of log_level; "info" keeps the rest quiet.
  log_level = "info",
  -- No in-editor terminal needed to reproduce the misclassification.
  terminal = {
    provider = "none",
  },
})

-- Best-effort: start the server so the CONTROL path can actually queue an
-- at-mention. The bug itself does NOT require a running server or a connected
-- client -- the misclassification happens before any server interaction.
pcall(function()
  claudecode.start(false)
end)

-- README-default visual keymap: this is the exact mapping the docs recommend
-- and the one the reporter uses. `<cmd>...<cr>` PRESERVES visual mode, which is
-- what routes the request into the (buggy) visual tree-extraction path.
vim.keymap.set("v", "<leader>as", "<cmd>ClaudeCodeSend<cr>", { desc = "Send to Claude" })

vim.api.nvim_create_user_command("ReproDump", function(opts)
  local path = opts.args ~= "" and opts.args or (vim.fn.stdpath("cache") .. "/issue289_notifications.json")
  vim.fn.writefile({ vim.json.encode(_G._repro_notifications) }, path)
  original_notify("ReproDump -> " .. path .. " (" .. #_G._repro_notifications .. " notifications)", vim.log.levels.INFO)
end, { nargs = "?", desc = "Write captured ClaudeCode notifications as JSON" })

vim.api.nvim_create_user_command("ReproClear", function()
  _G._repro_notifications = {}
end, { desc = "Clear captured ClaudeCode notifications" })

-- Diagnostic snapshot: records how the CURRENT buffer would be classified so
-- automation can assert on the misclassification directly (no screen-scraping).
vim.api.nvim_create_user_command("ReproState", function(opts)
  local path = opts.args ~= "" and opts.args or (vim.fn.stdpath("cache") .. "/issue289_state.json")
  local buf = 0
  local ft = vim.bo[buf].filetype
  local bufname = vim.api.nvim_buf_get_name(buf)
  -- Mirror the exact classification predicate from init.lua handle_send_*.
  local matches_filetype = ft == "NvimTree" or ft == "neo-tree" or ft == "oil" or ft == "minifiles" or ft == "netrw"
  local matches_bufname = (string.match(bufname, "neo%-tree") ~= nil)
    or (string.match(bufname, "NvimTree") ~= nil)
    or (string.match(bufname, "minifiles://") ~= nil)
  local state = {
    filetype = ft,
    bufname = bufname,
    matches_filetype = matches_filetype,
    matches_bufname = matches_bufname,
    -- The plugin's effective decision is the OR of the two; the bug is that
    -- matches_bufname alone (with a non-tree filetype) flips this to true.
    is_tree_buffer = matches_filetype or matches_bufname,
    has_send_command = vim.fn.exists(":ClaudeCodeSend") == 2,
    server_running = (function()
      local ok_cc, cc = pcall(require, "claudecode")
      return ok_cc and cc.state and cc.state.server ~= nil or false
    end)(),
  }
  vim.fn.writefile({ vim.json.encode(state) }, path)
  original_notify("ReproState -> " .. path, vim.log.levels.INFO)
end, { nargs = "?", desc = "Write current-buffer tree-classification state as JSON" })

fixtures/issue-289/lua/… — affected + control sample files (all filetype=lua)

lua/plugins/_neo-tree_.lua — affected (path contains neo-tree):

-- AFFECTED FILE for issue #289.
--
-- This is an utterly ordinary Lua file. Its FILETYPE is `lua`. The ONLY reason
-- ClaudeCodeSend misbehaves here is that its PATH contains the substring
-- "neo-tree" (this file is named `_neo-tree_.lua`), which trips the
-- `string.match(current_bufname, "neo%-tree")` false positive.
--
-- Visually select a few of these lines and press <leader>as (or run
-- :'<,'>ClaudeCodeSend) -> you get a TreeAdd error and nothing is sent.

return {
  "nvim-neo-tree/neo-tree.nvim",
  branch = "v3.x",
  dependencies = {
    "nvim-lua/plenary.nvim",
    "nvim-tree/nvim-web-devicons",
    "MunifTanjim/nui.nvim",
  },
  config = function()
    require("neo-tree").setup({
      close_if_last_window = true,
      filesystem = {
        follow_current_file = { enabled = true },
      },
    })
  end,
}

lua/NvimTree_settings.lua — affected (path contains NvimTree):

-- AFFECTED FILE (NvimTree variant) for issue #289.
--
-- Same bug as `_neo-tree_.lua`, but triggered by the
-- `string.match(current_bufname, "NvimTree")` substring check. Filetype is
-- still `lua`; only the path contains "NvimTree".

local M = {}

M.opts = {
  sort = { sorter = "case_sensitive" },
  view = { width = 30 },
  renderer = { group_empty = true },
  filters = { dotfiles = true },
}

return M

lua/regular_plugin.lua — control (no magic substring):

-- CONTROL FILE for issue #289.
--
-- Identical in spirit to `_neo-tree_.lua`, but its path contains NONE of the
-- magic substrings (no "neo-tree", "NvimTree", or "minifiles://"). Visually
-- selecting lines here and pressing <leader>as works correctly: the selection
-- is sent (or queued) with no TreeAdd error.

return {
  "some-author/some-plugin.nvim",
  dependencies = {
    "nvim-lua/plenary.nvim",
  },
  config = function()
    require("some-plugin").setup({
      enabled = true,
      option_one = "value",
      option_two = 42,
    })
  end,
}

fixtures/issue-289/README.md — fixture documentation

# Fixture: issue #289 — path-substring tree misclassification

Reproduces [#289](https://github.com/coder/claudecode.nvim/issues/289):

> `ClaudeCodeSend` misclassifies a regular file buffer as a "tree buffer" when
> the **file path** (not filetype) contains the substring `neo-tree`,
> `NvimTree`, or `minifiles://`.

## Root cause

`handle_send_normal` and `handle_send_visual` in `lua/claudecode/init.lua`
decide whether the current buffer is a file-explorer ("tree") buffer using both
the filetype **and** a substring match against the buffer **name**:

```lua
local is_tree_buffer = current_ft == "NvimTree"
  or current_ft == "neo-tree"
  or current_ft == "oil"
  or current_ft == "minifiles"
  or current_ft == "netrw"
  or current_ft == "snacks_picker_list"   -- (normal handler only)
  or string.match(current_bufname, "neo%-tree")    -- ← false positive
  or string.match(current_bufname, "NvimTree")     -- ← false positive
  or string.match(current_bufname, "minifiles://")
```

A perfectly ordinary `lua` file whose **path** merely contains one of those
substrings (e.g. a plugin spec named `_neo-tree_.lua`, or anything under a
`nvim-tree-config/` directory) is therefore treated as a tree buffer.

## Files

| File | Path contains | Classified as tree? |
|------|---------------|---------------------|
| `lua/plugins/_neo-tree_.lua` | `neo-tree` | **yes (bug)** |
| `lua/NvimTree_settings.lua`  | `NvimTree` | **yes (bug)** |
| `lua/regular_plugin.lua`     | *(none)*   | no (control)        |

All three are plain `filetype=lua` files. Only the path differs.

## Reproduce manually

```bash
source fixtures/nvim-aliases.sh
vv issue-289 'lua/plugins/_neo-tree_.lua'   # AFFECTED
# (or) vv issue-289 'lua/regular_plugin.lua' # CONTROL
```

or directly:

```bash
NVIM_APPNAME=issue-289 XDG_CONFIG_HOME=fixtures \
  nvim fixtures/issue-289/lua/plugins/_neo-tree_.lua
```

Then, in the buffer:

1. **Visual path** (the README-default `<leader>as`, which maps to
   `<cmd>ClaudeCodeSend<cr>` and keeps visual mode): visually select a few lines
   (`Vjj`) and press `<leader>as`.
   → `ClaudeCode Error [ClaudeCode] [command] [ERROR] ClaudeCodeSend_visual->TreeAdd: Not in visual mode (current mode: n)`
2. **Range path**: visually select a few lines, then `:'<,'>ClaudeCodeSend`.
   → `ClaudeCode Error [ClaudeCode] [command] [ERROR] ClaudeCodeSend->TreeAdd: Not in a supported tree buffer (current filetype: lua)`

Doing the same in `regular_plugin.lua` sends the selection with no error.

## Helper commands (provided by this fixture's `init.lua`)

- `:ReproState [path]` — write the current buffer's tree-classification state
  (`filetype`, `bufname`, `matches_filetype`, `matches_bufname`,
  `is_tree_buffer`, …) as JSON. On the affected files you will see
  `matches_filetype=false` but `is_tree_buffer=true`.
- `:ReproDump [path]` — write all captured ClaudeCode notifications as JSON.
- `:ReproClear` — clear the captured-notification buffer.

## Headless / automated reproduction

For a deterministic, CI-style check that drives the real `:ClaudeCodeSend`
command and exits non-zero when the bug is present:

```bash
nvim --headless -u NONE -l scripts/repro_issue_289.lua; echo "exit=$?"
```

`exit=1` ⇒ reproduced (a `lua` buffer whose path contains `neo-tree` is
misrouted into tree extraction while the control buffer sends correctly).
`exit=0` ⇒ fixed.