LSP Integration

What LSP gives the agent

The Language Server Protocol is the standard your editor uses to talk to language tooling — gopls for Go, rust-analyzer for Rust, and a server for most other languages. A language server analyzes your project and reports diagnostics: compile errors, type mismatches, unused imports, lint warnings, and so on.

BharatCode starts the configured language server for your project and keeps it running in the background. As the agent edits files, the server re-analyzes them and BharatCode collects the results. The agent reads those results through the diagnostics tool — so after a change it can see exactly what broke (or that everything is clean) without running a full build.

Configure a server per language

Language servers are configured under an lsp key in your config, keyed by language. Each entry names the command BharatCode runs to launch the server; BharatCode then speaks LSP to it over its standard input and output. The lsp block lives in the same config files as everything else — your global ~/.config/bharatcode/config.json or a per-project .bharatcode.json, merged the same way.

{  // Language servers BharatCode launches, keyed by language. Each entry is a  // subprocess the client talks to over the Language Server Protocol (stdio).  "lsp": {    "go": {      "command": "gopls"               // resolved on your PATH    },    "rust": {      "command": "rust-analyzer"    }  }}

The command is resolved on your PATH, so install the server the usual way and BharatCode will find it. The keys (go, rust) name the language the server handles; add an entry per language you want analyzed.

Passing arguments

If a server needs extra arguments to launch, add an args array alongside command. The arguments are passed straight through when the subprocess starts:

{  "lsp": {    "go": {      "command": "gopls",      "args": ["serve"]                // extra arguments passed to the server    }  }}

Reading diagnostics

Once a server is configured, diagnostics are available to the agent automatically — there is nothing extra to invoke. The agent calls the diagnostics tool whenever it needs to confirm the workspace is healthy, typically right after an edit:

> add a retry to the HTTP client and make sure it still builds   • edit         client.go   (awaiting approval)  • diagnostics  client.go      ✗ client.go:42  undefined: backoff  (gopls)  • edit         client.go   (awaiting approval)  • diagnostics  client.go      ✓ no problems

Because diagnostics is a read-only tool it runs without prompting you — see the Built-in Tools page for where it sits among the rest. If no language server is configured for the project's language, the agent simply has no diagnostics to read and falls back to building or testing through bash.

Works with real language servers

A correct LSP client cannot only send requests and read responses. Mature servers like gopls and rust-analyzer are themselves active over the connection: they send server-initiated requests back to the client — asking for configuration, registering capabilities, reporting work-in-progress, and more. A client that ignores those messages leaves the server waiting and the session stalls.

BharatCode's LSP client handles these server-initiated requests correctly, replying to them as the protocol expects. That is what lets it drive the real gopls and rust-analyzer binaries — the same servers your editor uses — rather than a cut-down stand-in. You get the diagnostics those servers actually produce.