oleks/claude-plugin-nvim-agentic
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

neovim vim_* tools fail to register when Claude Code launches before the bridge upstream is ready #2

New Issue
Closed
opened 2026-05-21 14:40:54 +03:00 by oleks · 1 comment
oleks commented 2026-05-21 14:40:54 +03:00
Owner
Copy Link
Copy Source

Claude Code attaches MCP servers once, at launch, and does not retry a failed handshake. The plugin's neovim MCP server points at the mcp-session-pool, which can only answer initialize after it has pinned its upstream session to nvim-mcp-bridge.

If Claude Code launches in the few-second window after a nvim restart but before nvim-mcp-bridge.service reaches active, the pool returns 502 for the handshake and the vim_* tools never register for that session. Only a full Claude Code restart recovers it.

Observed timeline (one occurrence): nvim restart 14:33:02 → Claude Code session launch 14:33:05 → nvim-mcp-bridge.service active 14:33:09. The session attached MCP ~4s before the upstream finished coming up.

Proposed fix (lands in mcp-session-pool, the servers/emmett repo, not this plugin's code): on a client initialize, the pool should bounded-retry establishing its upstream session (~20s) before giving up, instead of failing fast — so a launch a few seconds ahead of the bridge still registers cleanly. Other request types keep failing fast (so a genuinely-down nvim does not reintroduce hung tool calls).

Claude Code attaches MCP servers **once, at launch**, and does not retry a failed handshake. The plugin's `neovim` MCP server points at the `mcp-session-pool`, which can only answer `initialize` after it has pinned its upstream session to `nvim-mcp-bridge`. If Claude Code launches in the few-second window after a nvim restart but before `nvim-mcp-bridge.service` reaches `active`, the pool returns 502 for the handshake and the `vim_*` tools **never register** for that session. Only a full Claude Code restart recovers it. Observed timeline (one occurrence): nvim restart 14:33:02 → Claude Code session launch 14:33:05 → `nvim-mcp-bridge.service` active 14:33:09. The session attached MCP ~4s before the upstream finished coming up. Proposed fix (lands in `mcp-session-pool`, the `servers/emmett` repo, not this plugin's code): on a client `initialize`, the pool should bounded-retry establishing its upstream session (~20s) before giving up, instead of failing fast — so a launch a few seconds ahead of the bridge still registers cleanly. Other request types keep failing fast (so a genuinely-down nvim does not reintroduce hung tool calls).
oleks commented 2026-05-21 14:49:59 +03:00
Author
Owner
Copy Link
Copy Source

Fixed in mcp-session-pool (servers/emmett repo) — deployed 2026-05-21.

A client initialize now blocks-with-retry up to PROXY_INIT_PIN_TIMEOUT (default 20s) waiting for the upstream session to become establishable, instead of failing fast with a 502. A Claude Code launch a few seconds ahead of the nvim-mcp-bridge upstream now still registers the vim_* tools cleanly. All other request types still fail fast, so a genuinely-down nvim does not reintroduce hung tool calls.

Implementation: _ensure_pinned_blocking() in mcp_session_pool.py, used on the is_init path of do_POST.

Fixed in `mcp-session-pool` (servers/emmett repo) — deployed 2026-05-21. A client `initialize` now blocks-with-retry up to `PROXY_INIT_PIN_TIMEOUT` (default 20s) waiting for the upstream session to become establishable, instead of failing fast with a 502. A Claude Code launch a few seconds ahead of the `nvim-mcp-bridge` upstream now still registers the `vim_*` tools cleanly. All other request types still fail fast, so a genuinely-down nvim does not reintroduce hung tool calls. Implementation: `_ensure_pinned_blocking()` in `mcp_session_pool.py`, used on the `is_init` path of `do_POST`.
oleks closed this issue 2026-05-21 14:50:02 +03:00
oleks added the kind/bugarea/mcp-tooling labels 2026-06-03 13:03:49 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/mcp-tooling
area/wiring
kind/bug
No labels area/mcp-tooling kind/bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
oleks
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: oleks/claude-plugin-nvim-agentic#2
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?