I have been experiencing persistent lockups in Neovim (NVIM v0.10.0) since upgrading my Python development toolchain and integrating OpenClaw 2.1.5. The editor becomes completely unresponsive for 30-60 second intervals, specifically during file navigation in Python projects and upon opening files with existing language server diagnostics. The issue is reproducible on both macOS 14.5 (ARM) and Ubuntu 22.04 (x86_64).
My current hypothesis is a conflict between OpenClaw's enhanced LSP capabilities and other plugins that manage Python language servers or linting. The lockups feel like a blocking call, potentially in the event loop, and `:checkhealth` does not reveal any obvious failures. Below is my minimal `init.lua` that still triggers the issue.
```lua
-- Core package management
require('lazy').setup({
-- LSP & DAP
{
"OpenClaw/OpenClaw",
version = "2.1.5",
dependencies = {
"neovim/nvim-lspconfig",
"mfussenegger/nvim-dap",
},
opts = {
lsp = {
servers = { 'pyright', 'ruff_lsp' },
setup = { pyright = { settings = { python = { analysis = { typeCheckingMode = "basic" } } } } }
}
}
},
-- Completion engine
{
"hrsh7th/nvim-cmp",
dependencies = {
"hrsh7th/cmp-nvim-lsp",
"hrsh7th/cmp-buffer",
"hrsh7th/cmp-path",
},
},
-- File tree (suspected potential interaction)
{
"nvim-tree/nvim-tree.lua",
opts = { update_focused_file = { enable = true } }
},
-- Syntax highlighting
{ "nvim-treesitter/nvim-treesitter", build = ":TSUpdate" },
})
```
To diagnose, I have attempted the following isolation steps:
* Disabling `nvim-tree.lua` eliminates lockups during file navigation, but the issue persists upon opening Python files.
* Setting `pyright` to `nil` in OpenClaw's server list and relying solely on `ruff_lsp` reduces frequency but does not eliminate lockups.
* The lockup occurs consistently when the first Python diagnostic (e.g., a type warning) is triggered in a new session.
Key questions for the community:
1. Is there a known event loop blocking pattern when multiple LSP clients (`pyright` and `ruff_lsp`) are active through OpenClaw with `nvim-cmp` sourcing all of them?
2. Could the `update_focused_file` feature in nvim-tree be causing a cascade of LSP requests that OpenClaw's internal middleware handles inefficiently?
3. Are there specific OpenClaw 2.1.5 configuration options to debounce or throttle diagnostic updates that I have missed?
My next step is to profile with `:LspLog` and `vim.loop` instrumentation, but I wanted to first check if this is a recognized conflict pattern. I will update this thread with any trace data I can capture.
— Amanda
Data > opinions