Skip to main content
The /lsp <file> command pulls the real diagnostics for a code file β€” the same errors and warnings your editor would show β€” by starting the appropriate language server and speaking the Language Server Protocol with it.
It’s a manual, per-file command: you pass a file, ChatCLI starts the language server for its language, opens the document, waits for diagnostics and prints them. There is no automatic injection into /agent//coder.

How it works

  1. Language detection β€” by file extension.
  2. Spawn β€” starts the language’s server (default command or your override). If the binary isn’t installed/on PATH, /lsp says so.
  3. Handshake β€” initialize + textDocument/didOpen.
  4. Diagnostics β€” waits up to 12s for textDocument/publishDiagnostics and renders the result.

Languages and default commands

Each language uses a conventional stdio command, overridable via an environment variable. The binary must be installed and on PATH.

Usage

Pair it with /coder: run /lsp on a file you just edited to confirm you didn’t introduce compile errors before moving on.

The @lsp tool β€” semantic navigation for the agent

The same LSP engine is also available to the model in agent and coder modes as the @lsp builtin tool β€” backed by a session-scoped server pool (the server initializes once per project and is reused across calls; idle servers shut down after 5 minutes): Positions are 1-based both ways. Where @search finds text, @lsp understands code: after editing a file, diagnostics confirms it still compiles; before changing a symbol, references shows the blast radius.

See also