Claude Code an meine Dev-Umgebung lassen

devenvMCPAIDeveloper ExperienceProcess Management

Ich debugge mit Claude Code als Partner. Es liest Logs, formt eine Hypothese, schlägt einen Fix vor. Aber lange Zeit gab es eine unbequeme Naht in dieser Schleife: Ich war derjenige, der die Befehle ausführte. Claude sagte „schau dir den stderr des Workers an", ich kopierte die Ausgabe zurück, Claude las sie. Ein menschliches Relais zwischen einer KI und einem Process-Manager, die im Prinzip beide strukturierte Daten sprechen.

devenv 2.x schließt diese Naht. Es bringt einen eingebauten Model-Context-Protocol-Server mit — devenv mcp — und ihn in Claude Code einzubinden macht aus dem Assistenten statt eines Beraters etwas, das tatsächlich in die laufende Umgebung hineingreifen kann.

Was MCP kurz gesagt ist

Das Model Context Protocol ist ein offener Standard, der einem KI-Assistenten erlaubt, Tools aufzurufen und Resources aus einem externen Programm zu lesen. Der Transport ist JSON-RPC, meist über stdio: Der Client (Claude Code) startet den Server als Kindprozess und spricht mit ihm über stdin/stdout. Kein Netzwerk, kein Daemon, keine Ports.

Warum sollte ausgerechnet ein Dev-Environment-Tool so etwas mitbringen? Weil das Nix-Ökosystem riesig ist und Sprachmodelle Optionsnamen mit großer Überzeugung halluzinieren (services.postgresql vs. services.postgres, jedes Mal). Ein MCP-Server, der von deinem tatsächlichen Projekt gespeist wird, gibt dem Assistenten Ground Truth statt Vermutungen: die echten Optionen, deine konkrete Config, eine Live-Paketsuche — und, wie sich zeigt, Live-Kontrolle über deine Prozesse.

Einbinden

Ein einziger Befehl registriert ihn:

claude mcp add --scope project devenv -- devenv mcp

Zwei Details, die man auskosten sollte. Das -- ist der POSIX-Marker für „Ende der Optionen": Alles danach ist der Startbefehl des Servers (devenv mcp), unangetastet vom Parser von claude mcp add. Und --scope project schreibt eine .mcp.json ins Repo statt in deine persönliche Config:

{
  "mcpServers": {
    "devenv": {
      "type": "stdio",
      "command": "devenv",
      "args": ["mcp"],
      "env": {}
    }
  }
}

Commite diese Datei, und jeder Teamkollege — und jede Claude-Code-Session, die im Verzeichnis geöffnet wird — bekommt den Server automatisch angeboten. Das Introspektions-Werkzeug der Umgebung wird Teil des Repos, versioniert neben dem Code, den es beschreibt.

Die acht Tools, in zwei Klassen

Einmal verbunden, exponiert der Server acht Tools, die sauber in zwei Aufgaben zerfallen:

Knowledge — Fragen über die Umgebung beantworten:

  • search_options — durchsucht die echten Konfigurationsoptionen (gib ihm einen konkreten Begriff wie listen_addresses, keinen Wortsalat)
  • search_packages — Live-Suche in nixpkgs; ich habe nach pgcli gefragt und Version 4.4.0 zurückbekommen, fertig zum Eintragen in packages

Operations — auf die laufende Umgebung einwirken:

  • list_processes, get_process_status, get_process_logs
  • start_process, stop_process, restart_process

Die zweite Klasse ist die interessante. Der Assistent kann jetzt das tun, was ich früher von Hand weitergereicht habe: „der Worker ist in gave_up, hier ist sein stderr, starte ihn neu." Kein Copy-Paste, kein Mensch mitten in der Feedback-Schleife.

Drei Türen, ein Haus

Was es für mich klickbar gemacht hat: Die MCP-Tools sind kein separates System. list_processes ist devenv processes list. restart_process ist devenv processes restart. Das Ctrl-R der TUI ist dieselbe Aktion noch einmal. Alle drei — TUI, CLI, MCP — sind Türen in denselben Process-Manager, die über denselben .devenv/run/processes/native.sock sprechen.

Dieses Framing ist auch der Weg, über Fehler nachzudenken. Wenn der Socket stirbt — sagen wir, nachdem du die TUI verlassen hast, ohne die Prozesse zu stoppen —, verlieren alle drei Türen gleichzeitig den Zugriff, obwohl die Prozesse selbst als Waisen weiterlaufen. Der MCP-Server ist keine Magie; er ist ein weiterer Client eines Managers, der selbst abhandenkommen kann.

Ein ehrliches Limit

Tools sind nur so gut wie die Daten dahinter. In einer Session meldete get_process_status munter einen Worker als gave_up, während der Prozess tatsächlich quicklebendig war — die Buchführung des Managers war nach einem manuellen Restart veraltet. Der Assistent glaubte dem Tool; das Tool lag falsch.

Es gilt also dieselbe Regel, die menschliches Debugging regiert, auch für die KI-Variante: Das Dashboard ist eine Behauptung, kein Beweis. Ein MCP-Server, der Logs ziehen und Prozesse neu starten kann, ist ein echter Multiplikator für eine Debugging-Schleife — er entfernt das langsamste Glied, das menschliche Relais. Aber er entfernt nicht die Notwendigkeit zu verifizieren. Er macht das Verifizieren nur schnell genug, dass es keine Ausrede mehr gibt, es zu überspringen.

Als Nächstes: ein Bug, bei dem jedes Werkzeug im Kasten — diese eingeschlossen — in die falsche Richtung zeigte, und ihn zu fassen hieß zu vergleichen, was zwei von ihnen sagten.

Quellen

← Alle Artikel