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.
/lsp <file> is the 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. Separately, the @coder engine now automatically checks the files it just edited — see Automatic post-edit diagnostics below.

​
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.

​
Automatic post-edit diagnostics

You no longer have to run /lsp by hand to catch a broken edit. In /agent and /coder, after a successful @coder write, patch or multipatch, the engine runs the language server over the files it just touched and appends any findings to the tool result as a compact [DIAGNOSTICS] block:
The model sees the problem immediately — the same turn as the edit — instead of turns later when a test fails. This is the single cheapest way to keep an agent’s edits compiling. Behavior and guardrails:
  • On by default, toggled with CHATCLI_CODER_AUTODIAG (off/false/no to disable).
  • Silent on clean files — a file with no diagnostics appends nothing, so the happy path costs zero tokens.
  • Bounded — at most 5 files per edit, a 3000-character budget for the block, and a wall-clock budget for the whole pass; overflow and skipped files are elided with an explicit note.
  • Never blocks on a cold server — if the session pool hasn’t started a server for that language yet, the check reports nothing now, warms the server in the background, and the next edit gets real findings. Your write’s result renders immediately either way.
  • Degrades to a no-op when no language server is available for the file’s language (or when running on a surface without the session LSP pool). It reuses the same session-scoped server pool as the @lsp tool below, so there’s no extra startup cost.
Keep it on: it turns “the build broke three steps ago” into “fix this line now”, with no prompting discipline required from the model.

​
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 15 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