[Bug] First write after an LSP server cold-start returns no diagnostics (silent false clean)

[Bearmancer]

The first write that touches a freshly started LSP server returns no <diagnostics> block at all ΓÇö even for a file that definitely has errors. The same file, or a sibling written next, then reports normally. This is a silent false-negative: the tool result reads as "clean".

Mechanism (source)

packages/opencode/src/lsp/client.ts:

const DIAGNOSTICS_FRESHNESS_TIMEOUT_MS = 3_000;
// ...
async diagnostics(filePath, signal) {
  const absPath = this.resolveWorkspacePath(filePath);
  await this.openFile(absPath);
  const deadlineAt = Date.now() + this.diagnosticsFreshnessTimeoutMs;
  for (;;) {
    const snapshot = this.documents.captureDiagnosticSnapshot(absPath);
    if (!snapshot) return this.freshnessTimeout(absPath);   // <- returns a transientError, caller renders nothing
    const push = this.documents.resolvePushDiagnostics(snapshot);
    if (push.status === "ready") return { items: [...push.diagnostics] };
    ...

and the server is spawned lazily per (root, serverID) in lsp.ts (schedule() ΓåÆ server.spawn() ΓåÆ LSPClient.create() ΓåÆ initialize handshake with INITIALIZE_TIMEOUT_MS).

On a cold server the document is opened while the server is still initializing, so no push diagnostics ever arrive and the pull request yields nothing within the freshness window ΓåÆ the client returns a transient/freshness result, the write tool result carries no diagnostics section, and the user sees an apparently clean file. shouldSeedDiagnosticsOnFirstPush (client.ts) only special-cases serverID === "typescript", so every other server is exposed.

Repro (bare dir, no repo markers, "lsp": true)

1. Create an empty directory.
2. In a single batch, write one broken file per extension: probe.py (def f(:), probe.cs (int y = ;), probe.sh (echo "unclosed), and warm files probe.js / probe.ts.
3. Read the write results.

Expected: every broken file reports its error.
Actual: only the extensions whose server happened to be warm report. Verbatim from the first batch:

LSP errors detected in other files:
<diagnostics file="...\probe.ts"> ERROR [1:19] Expected an expression ... </diagnostics>
<diagnostics file="...\probe.js"> ERROR [1:11] Expected an expression ... </diagnostics>
→ nothing for probe.py, probe.cs, probe.sh, probe.json, probe.jsonc

Second batch, new file names (same directory, servers now warm):

<diagnostics file="...\probe2.py">
ERROR [1:6] "(" was not closed
ERROR [1:7] Expected parameter name
...
</diagnostics>
<diagnostics file="...\probe2.cs"> ERROR [1:37] Invalid expression term ';' </diagnostics>

And a third observable: a file written earlier (__lsp_t.json) resurfaced later only as an "other files" entry ΓÇö i.e. the diagnostics existed, they just arrived after the tool result was rendered.

Counter-scenarios tried

• Second write to the same server (warm) ΓåÆ diagnostics appear ΓçÆ not a parser problem.
• Fresh file name in the same directory (no re-open of the same path) ΓåÆ appears once warm ΓçÆ not a path/caching artifact.
• Different extension, identical bytes (.json vs .jsonc) ΓåÆ .json fires on a warm server, .jsonc never ΓçÆ confirms cold-start is orthogonal to the LANGUAGE_EXTENSIONS issue.
• Independent tool path (plugin lsp_diagnostics) on the same cold file ΓåÆ returns the error immediately ΓçÆ the server can answer; only the write-time path misses it.

Expected vs actual

Expected: if diagnostics cannot be obtained within the freshness window, the tool result says so (or retries/reports freshness_timeout ΓÇö the error kind already exists in LspDiagnosticsDetails).
Actual: the write result is indistinguishable from a clean file.

Suggested fix

Surface the existing transient result on the write path (e.g. append a note like no diagnostics received within 3000 ms (server initializing)), or wait for the server's initialized notification before the first diagnostics request, or extend the per-server first-request window.

---

Environment (software)

item	value
OS	Microsoft Windows 10 Pro — 10.0.19045 (Build 19045), 64-bit
Shell	PowerShell 7.6.6 (+ Windows Terminal)
opencode	1.18.30
plugins	oh-my-openagent 4.19.4 · @cortexkit/opencode-antigravity-auth 2.2.1
runtimes	Node v24.19.0 · npm 11.17.0 · Bun 1.4.2
LSP binaries	biome 2.5.13 · basedpyright 1.40.1 · roslyn-language-server 5.12.0-1.26426.8 · bash-language-server 5.6.0 · shellcheck 0.11.0 · vscode-langservers-extracted 4.10.0 · PowerShellEditorServices 4.7.0 · PSScriptAnalyzer 1.25.0
logs	~/.local/share/opencode/log/opencode.log · ~/.omo/agent/OmO-debug.log · ~/.omo/agent/logs/config-reload.log

OS facts collected with:

Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,BuildNumber,OSArchitecture

No hardware, hostname, username, or credentials included.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• LSP diagnostics waits hardcoded at 5s/10s: slow servers return no diagnostics, indistinguishable from a clean file #41218: Describes the same symptom — LSP diagnostics returning no results (indistinguishable from a clean file) when the server is slow/unready, due to hardcoded timeouts in client.ts. That issue also proposes making the wait configurable per-server.
• [BUG] Experimental LSP tool returns empty results instead of initialization errors for nested Rust workspace #40413: LSP tool returning empty results instead of explicit errors when the language server fails to initialize, making failures look like valid empty answers.

The core problem described here (cold-start window causing silent false-negatives on the write path) overlaps significantly with #41218, which covers the same client.ts timeout constants and the same "no diagnostics ≡ clean file" ambiguity.

[Bearmancer]

Checked both — related, but neither is the same bug, so keeping this open.

#41218 is a parse-duration problem. A slow server (clangd, ~20s on a huge TU) exceeds the hardcoded 5s document / 10s full waits (client.ts), so the client gives up first. Its fix is configurable per-server timeouts.

This issue is an initialization race. Even an instant server (biome, parses in milliseconds) reports nothing on the FIRST write after cold start, then reports everything — including the first file under "other files" — on the next write seconds later (verbatim outputs in the body). Waiting longer cannot fix it, because the write path has already returned; the configurable timeouts proposed in #41218 change nothing here. What is needed is on the write path: surface the transient state (e.g. "server still starting") instead of rendering an empty result that reads as clean.

#40413 is an initialization failure (rust-analyzer never loads the nested workspace) surfaced as empty results — a server that never starts, versus a server that started but whose first request resolved before any diagnostics existed.

Three distinct failure points, three distinct fixes:

• LSP diagnostics waits hardcoded at 5s/10s: slow servers return no diagnostics, indistinguishable from a clean file #41218 → configurable waits (slow parse)
• [BUG] Experimental LSP tool returns empty results instead of initialization errors for nested Rust workspace #40413 → surface init errors instead of [] (never started)
• this issue → surface first-request transience on the write path (cold start)