OpenCode LSP: Funktion, Aktivierung und Fehler bei deaktivierten Servern

LSP steht für Language Server Protocol. Ein Sprachserver läuft neben dem Projekt und liefert Diagnosen, Symbole, Definitionen, Referenzen und Hover-Informationen. OpenCode kann diese Daten in der Sitzung nutzen, statt jede Datei als isolierten Text zu behandeln.

Der praktische Nutzen ist besserer Kontext. Versteht ein TypeScript-Server einen Import, hat der Agent beim Erklären eines Typfehlers oder beim Umbenennen mehr Belege. Trotzdem garantiert LSP keine richtige Antwort: Der Server kann fehlen, das Projekt kann nicht laden oder das Paket benötigt eigene Einstellungen. LSP ergänzt den Workflow, ersetzt aber keine Tests oder Diff-Prüfung.

Ein LSP-Eintrag braucht ein ausführbares Kommando und eine klare Zuordnung zu Dateiendungen. Das Kommando startet den Server, die Extension-Liste beschreibt die betroffenen Dateien. Ausführbare Datei, Argumente und Installation kommen aus der Server-Dokumentation; errate kein Paket.

Beginne mit einer Sprache in einem kleinen Repository. Öffne eine passende Datei, prüfe den Prozessstart und stelle dann eine reine Leseanfrage. Bei einer falschen Endung kann ein funktionierender Server defekt wirken, weil OpenCode ihn nicht an die Datei bindet.

Gemeinsame LSP-Entscheidungen gehören in eine geprüfte Projektkonfiguration. Persönliche Experimente bleiben zunächst global, bis Kommando, Endungen und Projekt-Root klar sind. Die JSONC-Anleitung behandelt Scope und Schema; diese Seite bleibt beim Sprachserver.

Ein kleiner Eintrag ist leichter zu debuggen als ein großes Verzeichnis. Nutze einen verständlichen Namen, ein explizites Kommando-Array und nur unterstützte Endungen. Initialisierung kommt erst nach einem funktionierenden Basisprozess. Valides JSON bedeutet nicht, dass Programm oder Workspace stimmen.

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": {
    "typescript": {
      "command": ["typescript-language-server", "--stdio"],
      "extensions": [".ts", ".tsx"]
    }
  }
}

Die aktuelle offizielle Dokumentation sagt: Fehlt lsp, sind alle LSP-Server deaktiviert. Nach einer aktivierenden Konfiguration kannst du mit lsp: false alle Server abschalten; für einen einzelnen Server gilt disabled: true. Das hilft bei langsamen, lauten oder inkompatiblen Servern.

Eigene Server decken weitere Sprachen und Endungen ab. Definiere zuerst Kommando und Endungen, ergänze Initialisierung nur laut Dokumentation und ändere pro Test genau eine Sache. Bewahre die letzte funktionierende Konfiguration für den Rollback auf.

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": false
}

{
  "$schema": "https://opencode.ai/config.json",
  "lsp": {
    "custom-lsp": {
      "command": ["custom-lsp-server", "--stdio"],
      "extensions": [".custom"],
      "initialization": { "preferences": { "mode": "strict" } }
    }
  }
}

Beginne nicht mit dem Umschreiben eines großen Moduls. Nutze ein sauberes Repository, öffne eine bekannte Datei und stelle eine Leseanfrage: Symbol, Definition oder Diagnose. Vergleiche das Ergebnis mit Editor, Compiler oder dem vertrauenswürdigen Server.

Wenn das funktioniert, ändere eine kleine Stelle, die leicht zurückzunehmen ist, und prüfe den Diff. Notiere System, Kommando, Endungen, Root und Prompt. Damit wird der Test reproduzierbar und die nächste Störung leichter zuzuordnen.

1. SauberMit bekanntem Branch und Arbeitsbaum starten.
2. ZuordnenDatei mit konfigurierter Endung öffnen.
3. LesenSymbol, Definition, Referenz oder Diagnose anfragen.
4. ÄndernKleine reversible Änderung machen und Diff prüfen.
5. NotierenKommando, Modell, Server und Rollback speichern.

Wenn OpenCode meldet, dass LSP deaktiviert ist, prüfe zuerst die Konfigurationspriorität. Eine andere Datei kann lsp: false setzen, das Projekt kann den Servernamen nicht enthalten oder ein Eintrag kann disabled aktivieren. Vergleiche Projektordner und tatsächlich gewinnende Konfiguration.

Ist der Server aktiv, fehlen aber Diagnosen, prüfe Kommando und Endung. Starte ihn möglichst in derselben Shell, kontrolliere Runtime und PATH und kläre Lockfile, Compilerkonfiguration und Workspace-Root. Ein langsames erstes Ergebnis kann vom Indexieren stammen.

Halte Berechtigungen eng. LSP benötigt Prozess und Projektkontext, aber nicht automatisch eine breite Shell, mehr MCP-Tools oder Auto-Approval. Nutze die Berechtigungs- und MCP-Anleitung, sobald das Problem die Ebene wechselt.

LSP liefert Sprachintelligenz im Repository. MCP verbindet externe Tools und Daten. Formatter ändern Stil und Tests liefern ausführbare Belege. VS Code kann eigene Diagnosen anzeigen; das beweist nicht, dass OpenCode denselben Server oder dieselbe Root nutzt.

Verlinke je nach Symptom die passende Anleitung: MCP für lokale und entfernte Tool-Server, VS Code für Editor- und Terminalkontext, Permissions für Freigaben. So bleibt LSP in OpenCode eine fokussierte Seite.