[BUG] Sending files, current buffer, or lines to claude doesn't work.

[alextricity25]

Bug Description

Sending files, current buffer, or lines to claude doesn't work.

To Reproduce

Steps to reproduce the behavior:

1. Send files to claude code
2. See error

[ClaudeCode] [queue] [ERROR] Connection timeout - clearing 1 queued @ mentions

Expected Behavior

I expect that files and code lines can be sent to claude. This worked for me a few days ago. I guess claude auto-updated and now it isn't working.

Environment

• Neovim version: v0.10.4
• Claude Code CLI version: 1.0.41
• OS: macOS 15.5
• Plugin version: latest

Error Messages

[ClaudeCode] [queue] [ERROR] Connection timeout - clearing 1 queued @ mentions

If applicable, add error messages or logs.

Paste any error messages here

Additional Context

Add any other context about the problem here.

[TheLazyLemur]

I cant seem to recreate this with my own dotfiles. I am using nvim 0.11, I wonder if that has something to do with it?

[teito-dev]

I'm facing the same issue too,
To recreate it

Open two neovim instances and then open claude code in both, the 2nd one will show this error if you try to send a snippet to claude code

I'm on neovim 0.11.2
claude code commit : 91357d8

[alex35mil]

I'm facing the same issue in one of the projects. I closed all the other instances, but it still fails to connect to IDE:

   Error  12:04:59 notify.error ClaudeCode Error [ClaudeCode] [queue] [ERROR] Connection timeout - clearing 1 queued @ mentions

At the same time, I can open multiple other projects and not have such an issue in either of them.

[agusdmb]

This is happening to me too, and funny thing, if i have claude code open on another terminal it would work but the Send would be caught by the other terminal, not the claude code running in neovim.

[LizardLiang]

I'm having the same issue as agusdmb.
I couldn't get Neovim to connect to the Claude code opened by this plugin
It only works when the Claude code is opened in another terminal.

I'm on Windows 10
with
NVIM v0.11.3
Build type: Release
LuaJIT 2.1.1741730670

[isomoes]

Issue: Claude Code (CC v2.0.42) Does Not Appear to Follow Documented IDE Protocol

We are attempting to integrate with or debug the Claude Code extension (v2.0.42) using the official IDE protocol specification , which states that communication between the IDE and the Claude backend should occur over WebSocket on localhost:61022.
However, our observations suggest that no network activity is occurring on this port, indicating a possible deviation from the documented protocol or a failure in the local server component.

🔍 Observations
Lock file exists The expected lock file is present, suggesting the IDE integration subsystem initialized:

$ ls .claude/ide/
61022.lock

This implies the extension intended to use port 61022. No listening or established sockets for the Claude process
We identified the PID of the Claude Code backend process (CC-PID) and checked for active network connections:

$ sudo ss -tnp | grep "pid=CC-PID"
# (no output)
 61022.lock

No TCP sockets (listening or connected) are associated with the process.
No traffic on loopback port 61022
We monitored the loopback interface for any packets on port 61022:

$ sudo tshark -i lo -f "port 61022" -n
# (no packets captured, even during IDE interaction)

Confirms no WebSocket or TCP traffic is being sent or received.
Log output also shows "no handshake" errors With log_level = "trace", the logs repeatedly report:

:messages                                                                                                                                    
[ClaudeCode] [server] [DEBUG] Starting WebSocket server with authentication enabled                                                          
[ClaudeCode] [server] [DEBUG] Auth token length: 36                                                                                          
[ClaudeCode] [terminal] [DEBUG] Focus toggle: creating new terminal                                                                          
[ClaudeCode] [queue] [DEBUG] Queued @ mention: /home/xxxx (queue size: 1)                           
[ClaudeCode] [ClaudeCodeSend] [DEBUG] Queued @ mention and launched Claude Code: /home/xxxx        
[ClaudeCode] [selection] [DEBUG] Visual selection sent as at-mention.                                                                        
[ClaudeCode] [queue] [DEBUG] Clearing 1 queued @ mentions    

env

• NVIM v0.11.4 Build type: RelWithDebInfo LuaJIT 2.1.1760617492
• https://github.com/coder/claudecode.nvim branch main commit 1552086
• 2.0.42 (Claude Code)
• OS Arch linux

[leelhn2345]

i had this issue and i managed to pinpoint it to being a proxy issue.

the operations that the issue author mentioned, requires a socket connection at a particular port.

adding this to my terminal environment has fixed the issue.

export no_proxy=localhost,127.0.0.1,::1

[ThomasK33]

Note

This triage report is AI-generated using Claude Code

Summary

This was investigated as a bug report. "Sending doesn't work" turns out to be a symptom with a single underlying mechanism, which was reproduced against the current code (claude 2.1.168, Neovim 0.13, macOS).

The one mechanism behind the error

:ClaudeCodeSend (and the file / buffer / tree senders) route through send_at_mention. When Claude is not connected, the at-mention is queued and a connection_timeout timer (default 10s, lua/claudecode/init.lua) is armed. If the launched Claude has not opened a WebSocket back to the plugin's server by the deadline, the queue is cleared and the error is emitted:

[ClaudeCode] [queue] [ERROR] Connection timeout - clearing N queued @ mentions

So the failure is consistently "the Claude CLI that the plugin launched never connected back to the plugin's WebSocket server." Several distinct causes described in this thread all surface as that one error.

What was reproduced

The real claude CLI was driven inside a PTY against the real plugin server, and a small headless probe reported whether Claude actually completed a WebSocket handshake.

Environment	Result
CLAUDE_CODE_SSE_PORT set, no proxy (baseline)	connects, at-mention delivered
http_proxy / all_proxy set, no no_proxy	never connects; /ide reports "Failed to connect to Neovim"; the timeout error is shown
same proxy + no_proxy=localhost,127.0.0.1,::1	connects again

An automated harness that runs all three scenarios passes end-to-end (A_baseline=connect, B_proxy=noconnect, C_no_proxy=connect). The exact end-to-end error was also reproduced in the real plugin: Claude is launched inside a Neovim split, stays disconnected, and the timeout error is emitted after ~10s.

The baseline connects even when several other ~/.claude/ide/*.lock files are present, so CLAUDE_CODE_SSE_PORT reliably disambiguates — the proxy is the only variable that changes the outcome. This matches the no_proxy=localhost,127.0.0.1,::1 workaround already reported in this thread.

Root cause (proxy case): Claude's WebSocket client honours the lowercase http_proxy / all_proxy variables (proxy-from-env semantics) and, with no localhost exclusion, tunnels even the ws://127.0.0.1:<port> IDE connection through the proxy, which cannot reach a loopback server. The plugin injects ENABLE_IDE_INTEGRATION / FORCE_CODE_TERMINAL / CLAUDE_CODE_SSE_PORT into the Claude terminal environment, but not a localhost NO_PROXY.

Secondary cause (multi-instance / discovery)

Several reports — the second instance failing, the send being caught by the other terminal, or it only working when Claude is opened in a separate terminal — map to the discovery fallback that is used when CLAUDE_CODE_SSE_PORT does not reach Claude (external-terminal provider, shell / tmux wrappers that reset the environment, or older CLI versions). Behaviour observed with the current CLI:

• With the env var absent, Claude scans ~/.claude/ide/*.lock and filters by workspace (/ide prints "Found N other running IDE(s). However, their workspace/project directories do not match the current cwd.").
• With exactly one workspace-matching lock file, auto-connect succeeds; with two (two Neovim instances in the same project, or a stale lock file) it connects to neither — reproducing the timeout.

A Claude-side change to the discovery / auto-connect heuristic is a plausible (and unverified) explanation for the "it worked, then a Claude update broke it" and "lock file exists but no socket" reports. These discovery paths touch global ~/.claude/ide state shared with other live sessions, so they were characterised but not automated.

Workarounds today (no code change)

• Export a localhost exclusion in the environment Neovim is launched from: export no_proxy=localhost,127.0.0.1,::1 (and NO_PROXY=...).
• Avoid running two Neovim instances in the same project directory; remove stale ~/.claude/ide/*.lock files.
• Ensure CLAUDE_CODE_SSE_PORT actually reaches Claude (avoid terminal wrappers that strip the environment).

Suggested direction for a fix

• A localhost no_proxy / NO_PROXY could be injected into the environment table passed to the Claude terminal (get_claude_command_and_env in lua/claudecode/terminal.lua), so the loopback IDE socket is never proxied — taking care not to overwrite a user-provided value.
• The Connection timeout message is generic; surfacing why (a proxy is set / no handshake was received / multiple matching lock files) would make this class of report self-diagnosing.

Reproduction artifacts

The files below were created during triage (a fixtures/issue-70/README.md with the full write-up is included alongside them). They have been screened for secrets and personal information before posting.

scripts/repro_issue_70.sh — automated proxy reproduction (scenarios A / B / C)

#!/usr/bin/env bash
#
# Reproduce issue #70: "[BUG] Sending files, current buffer, or lines to claude
# doesn't work." -> [ClaudeCode] [queue] [ERROR] Connection timeout - clearing N
# queued @ mentions.
#
# https://github.com/coder/claudecode.nvim/issues/70
#
# The symptom is always the same single fact: the Claude CLI never opens a
# WebSocket connection back to the plugin's server, so queued @ mentions expire.
# This harness isolates ONE currently-live, plugin-relevant root cause -- an
# HTTP(S)/ALL proxy in the environment that has no localhost exclusion, which
# Claude honors for its `ws://127.0.0.1:<port>` IDE connection (matching the
# `no_proxy=localhost,127.0.0.1,::1` workaround reported on the issue).
#
# It starts the REAL plugin server (scripts/repro_issue_70_probe.lua), launches
# the REAL Claude CLI against it under three environments via agent-tty, and
# asserts whether Claude actually connected:
#
#   A  baseline (no proxy)                         -> EXPECT connect
#   B  proxy set, no localhost exclusion           -> EXPECT no-connect  (the bug)
#   C  proxy set + no_proxy=localhost,127.0.0.1,::1 -> EXPECT connect    (the fix)
#
# Requirements: nvim, the `claude` CLI (logged in), `agent-tty`, and `jq`.
# This harness only ever sets env vars + points CLAUDE_CODE_SSE_PORT at its own
# throwaway server; it never touches other ~/.claude/ide lock files.

set -uo pipefail

REPO_ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
PROBE_LUA="$REPO_ROOT/scripts/repro_issue_70_probe.lua"
WORK="$(mktemp -d "${TMPDIR:-/tmp}/issue70.XXXXXX")"
AGENT_HOME="$WORK/att-home"
DEAD_PROXY="http://127.0.0.1:1" # closed port -> any proxied connection fails fast
WAIT_CONNECT_S=14

mkdir -p "$AGENT_HOME"

for bin in nvim claude agent-tty jq; do
  command -v "$bin" >/dev/null 2>&1 || {
    echo "MISSING dependency: $bin" >&2
    exit 3
  }
done

PROBE_PIDS=()
# shellcheck disable=SC2329  # invoked indirectly via `trap cleanup EXIT`
cleanup() {
  for s in $(agent-tty --home "$AGENT_HOME" list --json 2>/dev/null | jq -r '.result.sessions[]?.sessionId // empty' 2>/dev/null); do
    agent-tty --home "$AGENT_HOME" destroy "$s" --json >/dev/null 2>&1
  done
  for p in "${PROBE_PIDS[@]:-}"; do [ -n "$p" ] && kill "$p" 2>/dev/null; done
  pkill -f "repro_issue_70_probe.lua $REPO_ROOT" 2>/dev/null
  rm -rf "$WORK"
}
trap cleanup EXIT

# start_probe <status_file> <stop_file> -> echoes the port
start_probe() {
  local status="$1" stop="$2"
  rm -f "$status" "$stop"
  nvim --headless -u NONE -l "$PROBE_LUA" "$REPO_ROOT" "$status" "$stop" 120000 >/dev/null 2>&1 &
  PROBE_PIDS+=("$!")
  local port=""
  for _ in $(seq 1 50); do
    [ -f "$status" ] && port="$(jq -r '.port // empty' "$status" 2>/dev/null)" && [ -n "$port" ] && break
    sleep 0.2
  done
  echo "$port"
}

# run_scenario <name> <expect:connect|noconnect> <env-setup-shell>
run_scenario() {
  local name="$1" expect="$2" envsetup="$3"
  local status="$WORK/$name.json" stop="$WORK/$name.stop"
  local port
  port="$(start_probe "$status" "$stop")"
  if [ -z "$port" ]; then
    echo "  [$name] FAIL: probe did not start"
    touch "$stop"
    return 1
  fi

  local sid
  sid="$(agent-tty --home "$AGENT_HOME" create --json --cols 200 --rows 50 -- /bin/bash | jq -r '.result.sessionId')"
  agent-tty --home "$AGENT_HOME" run "$sid" "cd '$REPO_ROOT'; unset http_proxy https_proxy all_proxy HTTP_PROXY HTTPS_PROXY ALL_PROXY no_proxy NO_PROXY; export ENABLE_IDE_INTEGRATION=true CLAUDE_CODE_SSE_PORT=$port; $envsetup; echo SCN_READY" --json >/dev/null 2>&1
  agent-tty --home "$AGENT_HOME" wait "$sid" --text 'SCN_READY' --timeout-ms 5000 --json >/dev/null 2>&1
  agent-tty --home "$AGENT_HOME" run "$sid" 'claude' --no-wait --json >/dev/null 2>&1
  # best-effort: dismiss a first-run trust prompt if one appears
  sleep 1
  agent-tty --home "$AGENT_HOME" send-keys "$sid" Enter --json >/dev/null 2>&1

  local connected="false"
  for _ in $(seq 1 "$WAIT_CONNECT_S"); do
    connected="$(jq -r '.connected // false' "$status" 2>/dev/null)"
    [ "$connected" = "true" ] && break
    sleep 1
  done

  # tear down this scenario's claude + server before reporting
  agent-tty --home "$AGENT_HOME" type "$sid" '/quit' --json >/dev/null 2>&1
  agent-tty --home "$AGENT_HOME" send-keys "$sid" Enter --json >/dev/null 2>&1
  touch "$stop"
  agent-tty --home "$AGENT_HOME" destroy "$sid" --json >/dev/null 2>&1

  local got="noconnect"
  [ "$connected" = "true" ] && got="connect"
  if [ "$got" = "$expect" ]; then
    echo "  [$name] PASS  (port $port: expected=$expect, got=$got)"
    return 0
  else
    echo "  [$name] FAIL  (port $port: expected=$expect, got=$got)"
    return 1
  fi
}

echo "issue #70 connection repro  (claude: $(claude --version 2>/dev/null | head -1))"
echo "repo: $REPO_ROOT"
echo

fails=0
run_scenario "A_baseline" "connect" ":" || fails=$((fails + 1))
run_scenario "B_proxy" "noconnect" "export http_proxy=$DEAD_PROXY https_proxy=$DEAD_PROXY all_proxy=$DEAD_PROXY" || fails=$((fails + 1))
run_scenario "C_no_proxy" "connect" "export http_proxy=$DEAD_PROXY https_proxy=$DEAD_PROXY all_proxy=$DEAD_PROXY no_proxy=localhost,127.0.0.1,::1 NO_PROXY=localhost,127.0.0.1,::1" || fails=$((fails + 1))

echo
if [ "$fails" -eq 0 ]; then
  echo "PASS issue #70 reproduced: a proxy with no localhost exclusion blocks Claude's"
  echo "     IDE WebSocket (B), while baseline (A) and the no_proxy fix (C) connect."
  exit 0
else
  echo "INCONCLUSIVE: $fails scenario(s) did not match expectation (see above)."
  echo "  Most often this means the local 'claude' is not logged in / cannot reach"
  echo "  the IDE socket for an unrelated reason. Re-run after 'claude' works manually."
  exit 1
fi

scripts/repro_issue_70_probe.lua — headless server probe (reports whether Claude handshakes)

-- Issue #70 connection probe.
--
-- Starts the REAL claudecode WebSocket server (terminal provider "none", so this
-- process never launches Claude itself) and keeps it listening for the full
-- window, continuously writing its connection state to <status_file> as JSON.
-- Stops early if <stop_file> appears.
--
-- A separate harness (scripts/repro_issue_70.sh) launches the real Claude CLI
-- against the port reported here, under different environments, and reads the
-- status file to decide whether Claude actually connected. This isolates the bug
-- in issue #70 to a single observable fact: did Claude open a WebSocket back to
-- the plugin's server, or not?
--
-- Run: nvim --headless -u NONE -l scripts/repro_issue_70_probe.lua \
--          <repo_root> <status_file> <stop_file> <wait_ms>

local repo = arg[1]
local status_file = arg[2]
local stop_file = arg[3]
local wait_ms = tonumber(arg[4] or "120000")

package.path = repo .. "/lua/?.lua;" .. repo .. "/lua/?/init.lua;" .. package.path

local function write_status(tbl)
  local f = assert(io.open(status_file, "w"))
  f:write(vim.json.encode(tbl))
  f:close()
end

local function file_exists(p)
  local fd = io.open(p, "r")
  if fd then
    fd:close()
    return true
  end
  return false
end

local claudecode = require("claudecode")
claudecode.setup({ auto_start = true, terminal = { provider = "none" }, log_level = "debug" })

local port = claudecode.state and claudecode.state.port
if not port then
  write_status({ phase = "error", error = "server did not start / no port" })
  os.exit(1)
end

local config_dir = os.getenv("CLAUDE_CONFIG_DIR")
local lock_dir = (config_dir and config_dir ~= "" and (config_dir .. "/ide")) or (os.getenv("HOME") .. "/.claude/ide")
local lock_path = lock_dir .. "/" .. port .. ".lock"

io.stderr:write(
  ("PROBE listening port=%d lock=%s exists=%s\n"):format(port, lock_path, tostring(file_exists(lock_path)))
)
write_status({ phase = "listening", port = port, lock_path = lock_path, lock_exists = file_exists(lock_path) })

local server_module = require("claudecode.server.init")
local start = vim.loop.now()
local connected_ever = false
while (vim.loop.now() - start) < wait_ms do
  vim.wait(500, function()
    return false
  end) -- pump the libuv loop for ~500ms
  local st = server_module.get_status()
  local conn = claudecode.is_claude_connected()
  if conn then
    connected_ever = true
  end
  write_status({
    phase = conn and "connected" or "listening",
    port = port,
    lock_path = lock_path,
    lock_exists = file_exists(lock_path),
    connected = conn,
    connected_ever = connected_ever,
    client_count = st.client_count,
  })
  if file_exists(stop_file) then
    break
  end
end

io.stderr:write("PROBE done connected_ever=" .. tostring(connected_ever) .. "\n")
claudecode.stop() -- removes the lock file
os.exit(connected_ever and 0 or 2)

fixtures/issue-70/init.lua — interactive fixture (real plugin, native terminal)

-- Fixture for issue #70:
--   "[BUG] Sending files, current buffer, or lines to claude doesn't work."
--   symptom: [ClaudeCode] [queue] [ERROR] Connection timeout - clearing N queued @ mentions
--   https://github.com/coder/claudecode.nvim/issues/70
--
-- The symptom is downstream of ONE thing: the Claude CLI that the plugin launches
-- never opens a WebSocket connection back to the plugin's server, so every queued
-- @ mention sits in the queue until `connection_timeout` (default 10s) elapses and
-- the queue is cleared with the error above.
--
-- This fixture launches the REAL plugin with the native terminal provider so the
-- Claude CLI runs inside Neovim. Run it with a proxy set in the environment but no
-- `no_proxy` exclusion for localhost to reproduce the dominant, currently-live root
-- cause (see fixtures/issue-70/README.md):
--
--   export http_proxy=http://127.0.0.1:1 all_proxy=http://127.0.0.1:1
--   unset no_proxy NO_PROXY
--   ISSUE70_LOG=/tmp/issue70.log \
--     NVIM_APPNAME=issue-70 XDG_CONFIG_HOME="$PWD/fixtures" \
--     nvim fixtures/issue-70/sample.txt
--   :Issue70Send        " launches Claude (cannot connect through the dead proxy)
--   " ...wait ~10s...    -> the Connection timeout ERROR notification appears
--
-- With NO proxy (or with `no_proxy=localhost,127.0.0.1,::1`) the same steps connect
-- cleanly and the @ mention is delivered -- that contrast is the whole bug.

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 = "\\"
vim.o.laststatus = 2

-- Tee every vim.notify (the plugin logs through it) to ISSUE70_LOG so the
-- "Connection timeout" ERROR can be asserted deterministically from a script,
-- not just scraped off the TUI.
local log_path = vim.env.ISSUE70_LOG
if log_path and log_path ~= "" then
  local orig_notify = vim.notify
  vim.notify = function(msg, level, opts) -- luacheck: ignore
    pcall(function()
      local fh = io.open(log_path, "a")
      if fh then
        fh:write(("[notify lvl=%s] %s\n"):format(tostring(level), tostring(msg)))
        fh:close()
      end
    end)
    return orig_notify(msg, level, opts)
  end
end

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

claudecode.setup({
  auto_start = true, -- start the WebSocket server immediately
  log_level = "debug",
  terminal = {
    provider = "native", -- run Claude inside Neovim so one PTY drives everything
    auto_close = false,
  },
  -- defaults: connection_timeout = 10000, queue_timeout = 5000
})

local banner = {
  "claudecode.nvim -- issue #70 reproduction fixture",
  "",
  "Symptom: [ClaudeCode] [queue] [ERROR] Connection timeout - clearing N queued @ mentions",
  "",
  "Run :Issue70Send (or <leader>s) to launch Claude and queue this file as an",
  "@ mention. If the launched Claude cannot connect back to the plugin's server",
  "(e.g. a proxy is set with no localhost exclusion), the queue clears after",
  "~10s with the Connection timeout ERROR.",
  "",
  "Server port: (see :ClaudeCodeStatus)",
}
vim.api.nvim_buf_set_lines(0, 0, -1, false, banner)
vim.bo.modifiable = false
vim.bo.modified = false

-- Queue THIS fixture's sample file as an @ mention via the real public API.
local function issue70_send()
  local sample = repo_root .. "/fixtures/issue-70/sample.txt"
  if vim.fn.filereadable(sample) == 0 then
    sample = vim.fn.expand("%:p")
  end
  local okk, err = require("claudecode").send_at_mention(sample, nil, nil, "issue70")
  vim.api.nvim_echo({
    {
      ("Issue70Send: queued %s (ok=%s%s)"):format(
        vim.fn.fnamemodify(sample, ":t"),
        tostring(okk),
        err and (" err=" .. err) or ""
      ),
      "MoreMsg",
    },
  }, false, {})
end

vim.api.nvim_create_user_command("Issue70Send", issue70_send, { desc = "Repro #70: queue sample.txt as @ mention" })
vim.keymap.set("n", "<leader>s", issue70_send, { desc = "Repro #70 send" })

fixtures/issue-70/sample.txt — file queued by :Issue70Send

sample file for issue #70 reproduction

These lines are what the fixture sends to Claude as an @ mention via
:Issue70Send. When the launched Claude cannot connect back to the plugin's
WebSocket server, this mention is queued and then cleared after ~10s with:

  [ClaudeCode] [queue] [ERROR] Connection timeout - clearing 1 queued @ mentions