A language server is the only plugin-configured mechanism whose native role is to analyze the resulting code state and contradict the model unprompted.
Other channels do reach the model unasked — a post-tool handler can inject feedback or replace a tool’s output, a monitor streams notifications — but that is something an author builds. A language server does it as its job: it reads the workspace as it now stands, analyzes it, and reports what is wrong after the edit has already landed [1][2].
That last clause is the whole dispatch. Diagnostics arrive on a push, not a pull: the model does not request the finding and cannot prevent its injection into context. Whether it acts on the finding is a separate question. And the entire behavior is governed by one boolean.
One dial, two products
The plugin reference documents the diagnostics field as defaulting to on, and describes setting it off as a way to keep code navigation while suppressing automatic diagnostic injection into context [1].
Read that as a product boundary rather than a configuration detail. On one side of the dial is a navigation service the model consults when it chooses — go to definition, find references, hover for type information [1][2]. That is a capability, and a substantial one: it lets the model establish what a symbol actually is by asking the language rather than by searching the repository for plausible matches. On the other side is an unrequested contradiction delivered after every edit. That is a verification surface.
The same binary separates the model may look up ground truth when it decides to from the harness tells the model it was wrong whether or not it asked. One of those is a convenience. The other is the closest thing the plugin system offers to an independent analyzer over the workspace, and it is available to any plugin author who omits a single field. How rigorous that analysis is depends on the server: implementations range from full type checkers to little more than syntax and symbol indexing.
What the posture is for
Two benefits, and they are worth stating on their own terms before the limitations arrive.
Correction moves in-loop. Because the finding lands in context immediately after the edit [1], the model sees its own error while it is still working on the change that caused it. The alternative is a human discovering the same error later, further from the reasoning that produced it, with the surrounding work already built on top. Shortening that distance is the operational case for the posture, independent of any governance reading.
The evidence is external by default. This is the corpus payoff. A diagnostic describes the resulting workspace state, produced by a process outside the reasoning it checks, according to the analyzer’s own implemented language rules and delivered through a standardized protocol — which means a reviewer can re-run it and get the same answer, given the analyzer, its version, its configuration, its environment, and that state. The anchor dispatch located assurance at the write path because that is where intent is captured or lost [4]. This posture is the one place the write path produces a finding about itself that does not depend on its own good faith. Nothing else a plugin configures generates evidence of that character.
Why the finding outranks a handler’s verdict
The parent dispatch settled this and the recap is two sentences. An interception handler can reach a long way — an agent handler reads files and searches the workspace before it decides — but by default it produces no record that stands apart from its own decision; it can be architected to invoke and preserve an independent analysis, and that independence is added rather than native. A language server’s analysis is external without anyone building it, which is the whole of the difference: not depth, not reach, but whether the record depends on the layer that produced it.
What the parent left for here is the practical consequence. A handler that spawns an agent to verify conditions before deciding [1] runs inside the harness, under the same caps and timeouts as any handler, and a reviewer re-deriving its conclusion has to re-create the handler. Re-deriving a language server’s finding needs the workspace, the analyzer, its version, its configuration, and its environment — a longer list than it first appears, and the subject of the rest of this dispatch.
The guarantee is conditional by construction
Here is the structural problem the posture ships with, and it is not a bug in anything.
A plugin that configures a language server does not include the language server. The reference is explicit: the plugin configures how Claude Code connects to the binary, and a missing binary surfaces as an executable-not-found error in the plugin errors tab [1]. The official marketplace plugins for Python, TypeScript, and Rust each name a separate installation step for the server itself [1].
So the diagnosis posture is a verification surface whose existence depends on a dependency the plugin cannot guarantee. An architect who reasons this plugin gives Claude type-checking over our codebase has stated something contingent on a machine-level install that no manifest enforces. The plugin is a wiring diagram. The oracle is somebody else’s package manager.
Three degradations, not three silences
The tempting framing is that this posture fails quietly in three ways. It does fail quietly, but the three failures are not versions of one thing — they are three different assurance failures, and conflating them hides the worst of them.
Diagnostic injection is a boolean, on by default. Turning it off suppresses the automatic push while code navigation keeps answering on demand [1]. This is the only degradation that leaves the rest of the posture working: the server runs, the analyzer is present, definitions and type queries resolve. What stops is the volunteering. A verification surface becomes a library, and the only place that decision is visible is the configuration file itself.
A server whose configuration is invalid is skipped while every other configured server still starts, with the reason in debug output [1]. A crashed server with restart declined stays stopped [1]. A missing binary surfaces as an executable-not-found error in the errors tab [1]. In each case the analyzer is gone, and with it both diagnostics and navigation — the same integration supplies both, so there is no partial survival here. That makes absence the most honest of the three: the capability visibly stops, even if the reason takes some looking to find.
When more than one enabled server declares the same extension, from one plugin or from two, the first registered handles those files and the others never start, with a warning in the plugin interface [1]. Findings keep arriving. They arrive from an analyzer other than the one the reviewed manifest names, with different configuration, different version, and potentially different implemented rules. Task execution continues normally even though the runtime analyzer no longer matches the manifest under review.
Substitution is the one to worry about, and it is the one that reads as benign. Take it together with the reproducibility recipe: an LSP finding is re-runnable given the workspace, the analyzer, its version, its configuration, and its environment. Substitution changes the analyzer without changing the manifest that documents it. So the record handed to a reviewer describes an analysis that did not happen — not because anyone falsified it, but because the label and the runtime diverged and the session had no reason to mention it.
The reference documents a version-gated correction narrowing this: a skipped server no longer claims its extensions, so it no longer blocks a valid server for the same files [1]. That closes one path into substitution. It does not close the general case of two working servers competing for the same language.
The manifest states claims. Runtime status and the plugin interface reveal which claim won. Those are different documents, and only one of them is checked into the repository.
The record that tells them apart
Suppression, absence, and substitution are only distinguishable if something wrote down what actually ran. Nothing in the plugin system does that on its own, which makes it the one artifact an architect has to build.
Call it a diagnostic provenance record: a small, boring object emitted alongside the findings, answering what analyzed this workspace and under what conditions. Nine fields cover it.
- Declared server — what the manifest under review names.
- Server actually started — what won arbitration and is serving these extensions.
- Binary path and version — the analyzer itself, identified rather than assumed.
- Configuration and environment digest — a hash over the environment, initialization options, settings, and workspace root the manifest supplied [1].
- Workspace or commit identity — what state was analyzed.
- Diagnostics enabled or disabled — whether the posture was volunteering or merely available.
- Extension owner — which server holds each language, and whether any warning was raised [1].
- Startup and arbitration warnings — the events that ordinary task behavior does not surface.
- Diagnostic timestamp and result — the finding, and when.
Read the three degradations against that list and each becomes legible from the record alone. Suppression shows as diagnostics disabled with the server running. Absence shows as no server started, with a startup or binary error attached. Substitution shows as declared and actual diverging — the single comparison that is invisible in the findings themselves.
The list is also the reproducibility recipe, written down. A finding is re-runnable given the workspace, the analyzer, its version, its configuration, and its environment; those are the first five fields. Which is the argument’s own test turned on the argument: a witness worth calling is one whose testimony carries the conditions under which it can be checked.
Nothing here requires a feature Anthropic has not shipped. It requires deciding that the record is part of the deliverable.
What follows for an architect
Three consequences, stated plainly.
Configuration is an assurance artifact. The dial that separates a witness from a silent library is a field in a file that ships with the plugin, and a reviewer who reads only the plugin’s description learns nothing about which side of it the team is on.
Binary provisioning belongs in the deployment contract, not the plugin. If the guarantee matters, the install belongs where installs are enforced.
Extension ownership belongs in the plugin inventory. Across a set of plugins the question is not which servers are configured but which one actually started for each language — the declared-versus-actual comparison the provenance record exists to make routine.
The diagnosis posture is the only plugin posture whose native operating model is external analysis of resulting workspace state, and it holds no power to act on what it finds. It cannot refuse a write. Its existence depends on an external binary the manifest does not itself provision or enforce. And it degrades three different ways: suppression leaves the analyzer running and stops it volunteering, absence takes diagnostics and navigation together, and substitution keeps findings arriving from an analyzer other than the one the reviewed manifest names.
Which makes the honest description of a configured language server a witness, not a control — and a witness worth calling. Its testimony is external to the reasoning it checks, re-runnable by anyone holding the analyzer, its version, its configuration, and the workspace state, and it arrives soon enough to change the work rather than only to grade it. Two errors follow, and the second is the quiet one. The first is reading its testimony as authority it was never given. The second is filing the testimony without recording which analyzer produced it [3][4].
