[FEATURE] LSP: pull diagnostics (textDocument/diagnostic) from servers that don't push them, such as TypeScript 7's native server

Status Open
Reported on v2.1.296
Maintainer reply None cached
Activity 0 comments · opened Oct 10, 2026

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet (closest: #40282, exposing diagnostics as an LSP tool operation)
  • [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's LSP client reads type errors only from textDocument/publishDiagnostics, and its initialize request doesn't advertise textDocument.diagnostic. TypeScript 7.0's native language server (tsc --lsp --stdio, generally available since July) serves per-file diagnostics only through textDocument/diagnostic. What it pushes on its own is limited to project-level (tsconfig) diagnostics. So with TypeScript 7 as the TypeScript LSP server, the type errors Claude normally sees after an Edit never arrive.

I measured this in five of my projects that type-check with TypeScript 7.0.2:

  • I used Claude Code 2.1.296's own client capabilities, copied from its bundle.
  • I appended export const probeTypeError: number = 'text'; with didChange and didSave.
  • TypeScript 7.0.2 sent no publishDiagnostics for the file within 30 s in any of the five projects.
  • typescript-language-server with TypeScript 6.0.3 pushed the error within 0.38–0.63 s.

That gap is the only thing keeping me on TypeScript 6's server, which these projects otherwise don't use for checking anymore. In one project, per session, TypeScript 7 compares like this:

| | TypeScript 7.0.2 (tsc --lsp --stdio) | typescript-language-server + TypeScript 6.0.3 |
| --- | --- | --- |
| First answer (definition) | 0.21 s | 6.7 s |
| CPU | 2.4 s | 12.2 s |
| Peak memory | 507 MB | 1,375 MB |

Definition, hover and references returned the same results from both servers in every project.

Proposed Solution

When a server's initialize result includes diagnosticProvider:

  • advertise textDocument.diagnostic in the client capabilities;
  • request textDocument/diagnostic for a document after didOpen, didChange and didSave, and again when the server sends workspace/diagnostic/refresh;
  • feed the result into the same path that publishDiagnostics feeds today.

Alternative Solutions

  • A relay between Claude Code and the server that turns pulled diagnostics into publishDiagnostics notifications. That's what I'm setting up locally in the meantime.
  • Staying on TypeScript 6's tsserver, which TypeScript 7 no longer ships (there is no tsserver.js).

Priority

High - Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

  1. A project type-checks with TypeScript 7, either as typescript@7 or as an alias beside the TypeScript 6 copy kept for typescript-eslint.
  2. An LSP plugin runs tsc --lsp --stdio from that project.
  3. Claude edits a file and introduces a type error. It should see the error after the edit, as it does with typescript-language-server today.

Additional Context

  • TypeScript 7's server pushes only program diagnostics, published for the tsconfig file (publishProgramDiagnostics in tsc/internal/project/session.go, microsoft/TypeScript). Per-file diagnostics are pull-only.
  • Claude Code 2.1.296 registers a handler for textDocument/publishDiagnostics only. Its client capabilities list synchronization, publishDiagnostics, hover, definition, references, documentSymbol and callHierarchy, with no diagnostic.
  • Windows 11, Claude Code 2.1.296.

View original on GitHub ↗