Claude Code IDE-Integration für Emacs

• Claude Code IDE for Emacs integriert die Claude Code CLI nativ in Emacs und bietet eine leistungsstarke KI-Coding-Assistenten-Umgebung
• Durch eine auf dem Model Context Protocol (MCP) basierende bidirektionale Brücke kann Claude auf verschiedene Emacs-Funktionen wie LSP, Projektverwaltung und Elisp-Funktionen zugreifen
• Unterstützte Emacs-spezifische Optimierungen wie automatische Projekterkennung, Mehrfachsitzungen, Diagnoseintegration (Fehler/Warnungen), erweitertes Diff, tab-bar sowie Auswahl-/Pufferverfolgung werden bereitgestellt
• Auf Basis der Emacs-Befehle und Erweiterbarkeit ist eine direkte Freigabe von Befehlen über einen MCP-Server und eine anpassbare Workflow-Integration möglich
• Durch die tiefe Verknüpfung zwischen Claude und dem gesamten Emacs-Ökosystem wird eine cloudbasierte KI-gestützte Entwicklungsumgebung aufgebaut

---

Überblick

Claude Code IDE for Emacs ist ein Open-Source-Projekt, das über die Integration mit der Claude Code CLI die Fähigkeiten von Claude AI in der Emacs-Umgebung maximal nutzt. Anders als ein einfacher Terminal-Wrapper stellt dieses Paket eine MCP- (Model Context Protocol-)basierte Bridge mit bidirektionaler Kommunikation bereit, sodass Claude die internen Emacs-Funktionen tatsächlich nutzen kann. So wird durch die Anbindung an das starke Emacs-Ökosystem mit LSP, Projektverwaltung und Elisp-Funktionen eine produktive und intelligente KI-gestützte Entwicklungsumgebung für Emacs-Nutzer umgesetzt.

Hauptmerkmale

• Automatische Projekterkennung und Sitzungsverwaltung

  • Nutzt das in Emacs integrierte project.el, erkennt Projekte automatisch und trennt Sitzungen
  • Stellt eine separate Claude Code-Instanz und eigene Puffer pro Projekt bereit

• Terminalintegration und Farbausgabe

  • Farbterminal-Unterstützung über vterm oder eat
  • Gespräch mit Claude direkt in Emacs möglich

• IDE-Integration über das MCP-Protokoll

  • Verschiedene Emacs-Befehle (Code-Navigation, Symbolsuche, AST-Analyse usw.) werden über den MCP-Server freigegeben
  • Claude kann Emacs-Befehle und benutzerdefinierte Funktionen ausführen

• Hochgradig erweiterbarer MCP-Tools-Server

  • Möglichkeit, personalisierte MCP-Tools hinzuzufügen/zu definieren (z. B. Projektsuche über das gesamte Projekt, globales Refactoring)

• Code-Diagnose und Diff

  • Bereitstellung von Code-Fehler-/Warnungsdiagnosen durch Flycheck- und Flymake-Integration
  • Erweiterte Diff-Ansicht und Zugriff auf Diagnosedaten über ediff

• Status- und Befehlsumschaltung

  • tab-bar, Auswahl- und Puffer-Tracking ermöglichen es Claude, den aktuellen Kontext des Benutzers zu verstehen

Emacs-Tool-Integration

Claude Code IDE macht über das MCP-Tool-System verschiedene Emacs-Befehle und Informationen direkt für Claude verfügbar

• LSP-Integration (xref)

  • Intelligente Navigation auf LSP-Basis wie Go-to-definition und symbol- sowie referenzweite Projekt-Suche

• Tree-sitter-Unterstützung

  • Bietet Syntaxbaum-Analyse und AST-(Abstract Syntax Tree)-basierte Code-Strukturerkennung

• Imenu- und Projektintegration

  • Automatische Bereitstellung von Symbollisten sowie Projektdatei- und Strukturinformationen

• Benutzerdefinierte Elisp-Funktionen

  • Direkte Freigabe als MCP-Tool, um individuelle Workflows und domänenspezifische Funktionen zu nutzen

Durch diese Integration kann Claude den Kontext des Emacs-Ökosystems nutzen und so präzise KI-Unterstützung auf Code-Ebene liefern

Verwendung

Grundbefehle

• M-x claude-code-ide-menu: Ruft ein visuelles Transient-Menü mit allen Befehlen auf
• Aktivierung von Claude Code im Projekt, Senden von Prompts, Fortsetzen früherer Gespräche sowie verschiedene Status-/Sitzungsverwaltung
• Mehrere Projekte können gleichzeitig verwaltet werden, wobei jedes Projekt über eine eigene Claude-Sitzung verfügt

Fenster- und Sitzungsverwaltung

• Wenn bereits eine neue Sitzung läuft, wird nur die Fensterumschaltung/Anzeigefunktion ausgeführt
• Auch wenn das Emacs-Standardkommando (C-x 0) das Fenster schließt, wird Claude selbst nicht beendet

Konfiguration

• Feingranulare Anpassung von Claude Code CLI, Terminal-Backend, Diagnose-Backend, Fensterposition/-größe und Debug-Optionen
• Erweiterte Optionen wie das Hinzufügen von Flags, das Festlegen eines System-Prompts oder Funktionen für die Puffernamensvergabe
• Aktivierung von MCP-Servern sowie Angabe von zu verwendenden Tools/Ports möglich

Terminal-Backend-Konfiguration

• Standard ist vterm, bei Bedarf kann auf eat umgestellt werden
• eat ist ein reines Elisp-basiertes Terminal und besonders nützlich, wenn vterm Build-Probleme verursacht
• Eigene Keybindings werden bereitgestellt (M-RET: Zeilenumbruch in der Eingabe, C-<escape>: Beenden/Abbrechen usw.)

Diagnose-/Debugging-Optionen

• Flycheck und Flymake können automatisch erkannt/verknüpft oder explizit gesetzt werden
• Integrierte temporäre Option zur Umgehung des Claude-Terminal-Reflow-Bugs (#1422)
• Detaillierte Debug-Logs auf Emacs- und CLI-Ebene (u. a. für WebSocket-, JSON-RPC-Nachrichten)

Advanced: mehrere Worktree, Sitzungsbetrieb

• Mit git worktree können in demselben Projekt mehrere unabhängige Sitzungen je Branch betrieben werden
• Jede Arbeitsgruppe behält einen eigenen Puffer und Kontext, was parallele Entwicklungs-Workflows unterstützt

Emacs MCP-Tools im Detail

Beispiele für integrierte MCP-Tools

• xref-find-references: Vollständige Projektsuche aller Verweise auf ein bestimmtes Symbol
• xref-find-apropos: Musterbasierte Suche über Symbole/Code im gesamten Projekt
• treesit-info: Bereitstellung von AST-Analyse-Daten auf Basis von tree-sitter
• imenu-list-symbols: Ausgabe aller Funktionen und Variablen in einer Datei
• project-info: Bereitstellung von Metadaten und Dateiübersicht des aktuellen Projekts

Benutzerdefinierte Tools hinzufügen

• Benutzer können eigene Emacs-Funktionen im MCP-Tool-Format hinzufügen
• Als Beispiel lassen sich ein auf ripgrep basierendes Code-Suchtool oder domänenspezifische Befehle definieren, die direkt von Claude aufgerufen werden können

Lizenz und verwandte Projekte

• Verfügbar unter GNU GPL v3.0 oder höher
• Als verwandte Projekte werden Integrationen für VS Code, Neovim (claudecode.nvim) und weitere Plugins vorgestellt

Bedeutung und Vorteile

Claude Code IDE for Emacs bietet eine leistungsstarke KI-IDE-Umgebung, die im Gegensatz zu bestehenden LLM/AI-Integrationswerkzeugen den einzigartigen Arbeitskontext und die Ökosysteminformationen von Emacs aktiv nutzen kann
Auch wenn es sich noch in einem frühen Stadium befindet, vereint es zahlreiche integrierte Funktionen, hohe Anpassbarkeit und Unterstützung für mehrere Projekte, wodurch es für Emacs-Nutzer und Open-Source-Entwickler eine sehr starke Option darstellt

[GN⁺]

Hacker News Kommentar

• Ähnlich wie LSP und tree-sitter sind KI-Coding-Tools wie Claude Code oder Aider für Emacs- oder Vim-Anwender wahre Glücksboten, weil man nicht mehr wie früher versucht, IDE-Funktionen selbst aufzubauen, sondern solche Werkzeuge einfach anbinden kann und sich auf die eigenen, editorspezifischen Unterschiede fokussieren darf. Genau diese Anpassbarkeit und die flexible Integration machen die Konkurrenzfähigkeit dieser Editoren deutlich stärker.
  • Ich frage mich, ob es einen Standard wie LSP gibt, der es ermöglicht, agentenbasierte Coding-Tools einfach in Editoren zu integrieren.
  • Das denke ich schon immer: Emacs und Vim hatten schon immer fortschrittliche IDE-Funktionen. Durch LSP und tree-sitter ist die Standardisierung zwischen Editor und Programmiersprache heute wesentlich leichter geworden.
  • Ich stimme nicht zu, dass Emacs und Vim als Nischen-Editoren gelten; sie sind bereits repräsentative Editoren.
• Ich habe Emacs schon immer als den besten Editor für KI-Agenten gesehen. Der Agent kann den gesamten Editor-Zustand einsehen und sogar mit Elisp bis ins Verhalten hinein alles ändern. Vim- und Emacs-Ebenen der Anpassbarkeit dürften künftig große Vorteile haben.
  • Tatsächlich hatten Vim und Emacs schon immer enorme Stärken. Jeder bewertet sie anders, aber für mich ist die geschlossene Erweiterbarkeit von VSCode oder IntelliJ ein großer Nachteil. Mit „geschlossen“ meine ich eingeschränkte Plugin-APIs, Sandbox-Ausführungsumgebungen, Unternehmensfreigaben und Intransparenz der internen Logik. Früher musste man oft zu einem anderen IDE wechseln, um neue Funktionen zu bekommen, aber heute erreicht man mein Ziel oft besser, wenn man nur Emacs lernt. Bei der Problemlösung mit Emacs ist es deutlich befriedigender als mit einem IDE.
  • Die Stärke von Emacs liegt im Lisp-Interpreter-Kern: Ein KI-Agent kann zur Laufzeit mit demselben Auswertungsmechanismus wie der Nutzer den gesamten Editor-Status direkt einsehen und verändern. Bei den meisten Editoren ist die Plugin-API dagegen starr fixiert.
• Ich nutze das claude-code.el-Plugin derzeit zufriedenstellend. Es ist zwar ein reiner Terminal-Wrapper, bietet aber ein starkes Transient-Menü. Allein in Emacs läuft der Workflow schon deutlich effizienter, und ich konnte eine wesentlich stärker angepasste Arbeitsweise aufbauen als in der alten iTerm-Umgebung. Ich werde kommende Pakete ebenfalls genau im Blick behalten, und ich erwarte mir auch viel von eca-emacs. Bei Tools, denen man produktivitätskritische Funktionen anvertraut, bin ich eher vorsichtig: Große Projekte durchlaufen häufig eine lange „Big-Bang“-Phase mit viel Nacharbeit.
  • Ich habe es kurz ausprobiert und bin am Ende doch wieder dazu zurückgekehrt, Claude Code einfach nur im Terminal zu nutzen. In Emacs fühlte es sich etwas hakelig an, und es gibt keinen Grund, kein separates Terminalfenster zu verwenden. Schade, dass die Integration mit dem mcp.el-Paket fehlt. In meiner praktischen Arbeit hat Claude Code mir noch nicht die gewünschte Code-Qualität geliefert. Auch mcp.el lohnt sich, einen Blick darauf zu werfen.
• Es ist nett, dass Emacs gerade LSP, tree-sitter und neue Tools wie Claude Code integriert, aber es wirkt so, als ob die Einrichtung deutlich schwieriger geworden ist. Ich bin seit 20 Jahren Emacs-Nutzer, und trotzdem ist das Setup heute nicht trivial. Vor der IDE-Integration von Claude Code war es für mich am einfachsten: es lief einfach, und dank automatischer Buffer-Synchronisierung musste man kaum etwas tun. Auf meinem neuen macOS ließ sich typescript-ls gerade noch starten, aber gopls lässt sich noch nicht herunterladen. Ich könnte es vielleicht in ein oder zwei Stunden beheben, aber herauszufinden, wo es klemmt, ist mühsam. Ich möchte das teilen, weil ich wissen möchte, wie andere Emacs-Nutzer:innen das heute lösen.
  • Ich nutze derzeit Zed und habe dabei Spaß am Coden, auch wenn es mir schwerfällt, die 20 Jahre gewachsene Emacs-Beharrlichkeit aufzugeben. Emacs bleibt durch kleine Konfigurationsdateien, Unterstützung großer Projekte und extreme Anpassbarkeit weiterhin sehr attraktiv. Ich frage mich, ob Neovim in dieser Hinsicht besser ist.
  • Ich frage mich, ob ich Elisp-Debugging besser lernen sollte, um besser zu verstehen, wie meine Befehle in der Umgebung wirken.
  • Da ich Emacs-Keybindings (sogar bis Dvorak!) schon so lange verwende, mache ich mir Sorgen, dass meine Neovim-Erfahrung dann ganz anders ausfallen könnte.
  • Ich empfehle Elisp-Debugging unbedingt. Obwohl viele Menschen seit Jahrzehnten Emacs nutzen, kennen sie nicht alle Werkzeuge wie den eingebauten Profiler, edebug, apropos, Makroexpansion, Advising-System oder indirekte Buffer. Wenn man Emacs mit dem Auto vergleicht, kann man es während der Fahrt umbauen – sogar bis zu einem Tauchboot – und genau deshalb braucht man auch die Haltung, grundlegende Fehlerbehebung und unvorhergesehene Situationen selbstverständlich zu akzeptieren. Problemstellen lassen sich oft direkt im gptel-Buffer finden, und man kann passend zu Hook- oder advise-Funktionen sofort eigenes Elisp schreiben und testen; dieses Gefühl der Befreiung muss man einfach erlebt haben. Ich achte heute nicht mehr so sehr auf eine „saubere“ Konfiguration – eine gute Modularisierung reicht, und bei Bedarf ergänze ich einfach Elisp. Die meisten Brüche entstehen durch Paket-Updates oder externe Ursachen; ich finde die Ursache meist in Minuten und habe meist innerhalb kurzer Zeit einen Ersatz.
  • Für das Management von Umgebungsproblemen lasse ich Emacs in Docker laufen – siehe auch emacs-native-dockerfiles.
  • Neue Sprachökosysteme in Emacs zu integrieren bleibt aufwendig, weil Auswahl von Paketen und externen Tools (u. a. LSP-Servern) selbst bei kleinen Projekten oft neu abgewogen werden muss. Für Downloads/Installationen externer Tools nutze ich Nix (devenv.sh) und direnv, damit Emacs selbst nichts herunterlädt, sondern nur Pfade gesetzt werden. Die zugehörigen Konfigurationsdateien speichere ich ebenfalls in devenv, sodass Teammitglieder dieselbe Umgebung nutzen können.
  • Ich bin seit acht Jahren Emacs-Nutzer, aber seit zwei Monaten komplett auf nvim umgestiegen und habe Emacs einen ganzen Monat lang überhaupt nicht gestartet. Ich habe lazy.vim installiert und nutze KI-Plugins im Wechsel. Die nvim-Community und das Ökosystem sind aktuell sogar aktiver; einen Blick wert ist auch ThePrimeagen.
  • Die Neovim-Erfahrung hat sich ebenfalls stark verbessert: Man kann alles vom Barebone-Setup bis zu Voll-I­de-Funktionen anpassen. Es gibt bereits viele vorkonfigurierte Distributionen – z. B. LazyVim –, und für KI-Plugins lohnt sich ein Blick auf awesome-neovim #ai.
• Mir ist eine noch stärkere org-mode-Integration oder allgemein bessere KI-Funktionen für Notizen wichtiger. GitHub Copilot löscht Gespräche nach 30 Tagen, und ich habe selbst erlebt, wie stark das den Aufbau einer Wissensbasis mit KI behindert. Deshalb braucht es, ähnlich wie Googles notebookllm, einen Ansatz, bei dem Forschung und Dokumentation lokal verwaltet werden können.
  • Ich empfehle, gptel-mode auszuprobieren: Gespräche werden im org-Buffer gespeichert, und Sitzungen lassen sich einfach speichern und wiederherstellen. Es lässt sich auch gut mit mcp.el kombinieren.
  • Auch ob-aider ist einen Blick wert.
• Ich bin extrem zufrieden mit der Möglichkeit, im MCP-Server frei Werkzeuge hinzufügen zu können – das passt ganz zu Emacs. Ich schreibe nach wie vor Elisp, inzwischen aber immer häufiger selbst, und auch die Elisp-Unterstützung von Claude ist inzwischen ziemlich gut, sodass ich es öfter nutze (manchmal muss ich die Klammer-Einrückung selbst korrigieren, insgesamt aber ist es brauchbar). Ich werde unbedingt efrit von Steve Yegge testen, weil die Fähigkeit eines Agenten, beliebige Elisp-Ausdrücke zu verwenden und auszuführen, die Grenzen von Emacs weiter nach oben schiebt.
  • Ich bin langjähriger Yegge-Fan und -Follower; ich halte es zwar noch für die Vibe-Coding-Honeymoon-Phase, aber die Emacs-Kompetenz ist dort wohl herausragend. Seit ein bis zwei Jahren ist mir klar geworden, dass große LLMs in Elisp seltsamerweise sehr stark sind – das war der Startschuss für ein hypermodernes Projekt. Ich halte efrit für sehr vielversprechend (obwohl ich es nicht perfekt eingerichtet habe).
    • efrit
• Gleichzeitig tauchen mehr als fünf Emacs-/Claude-Code-Integrationspakete auf, und zwei bis drei treten auf Reddit mit harter Konkurrenz gegeneinander an. Interessant ist, dass wirklich gute Plugins oft still existieren und kaum erwähnt werden. yuya373/claude-code-emacs bildet praktisch alle Funktionen der Konkurrenten bereits ab.
  • Ob es populär ist, weiß ich nicht, aber es scheint am einfachsten zu installieren zu sein; siehe melpa claude-code.
  • Dieses Paket scheint keine /ide-Integration von claude-code-ide zu haben.
• Ich empfehle ebenfalls dringend eca, weil es sich auf das beste KI-Pair-Programming-Tool für Emacs fokussiert.
• Ich habe in der Emacs-Community gespürt, dass die Diskussion über diese KI-Integration selbst kritisiert wird, aber ehrlich gesagt sehe ich da eher mehr Nachteile als Vorteile. Auch wenn sich KI anders entwickelt als frühere Generationen, bleibt Emacs’ Herkunft im MIT AI Lab bestehen; in einem Tool, das aus einer AI-Arbeitsgruppe dort entstanden ist, AI-Integration pauschal zu verweigern, finde ich merkwürdig.
  • Die Stärke von Emacs ist die nutzerzentrierte Kontrolle: Auf der Elisp-Ebene kann man alles anpassen, und genau deshalb entstehen solche Pakete ständig. VS Code ist strukturell eher auf Fragmentierung angelegt; Microsoft nutzt eine dedizierte proprietäre API für eigene Kernwerkzeuge und stellt nach außen nur eine deutlich eingeschränkte Erweiterungs-API bereit. So entstehen viele VS Code-Forks. In Emacs kann ein einziger engagierter und fähiger Elisp-Entwickler alles neu gestalten, und neue AI/LLM-Integrationsmodule können jederzeit entstehen. Der Ton in der Emacs-Community wirkt meiner Meinung nach etwas überzogen. Es kommen ja kontinuierlich AI/LLM-Plugins mit guter Resonanz – ein Beispiel ist gptel.
  • Der Grund für diese Stimmung liegt bei Richard Stallman: Er vertritt, dass man nicht-freie Software als Alternative in noch nicht vorbereiteten Freie-Software-Projekte integrieren sollte. Dieses Vorgehen verzögerte Entscheidungen bei GCC-Erweiterungen, LLVM-Debugger, tree-sitter, git/bzr, CI-Buildfarmen und anderen Bereichen; dadurch wurden Ersatzlösungen für Kernprojekte wie Emacs langsamer übernommen. Im Ergebnis kam die Community oft später dazu, und manchmal wirkt es wie der Wunsch, die Stellung der FSF zu sichern.
  • Die Emacs-Community ist sehr vielfältig. Kritik gibt es überall, aber man muss sie nicht ernst nehmen: Über Third-Party-Module kann man jederzeit gewünschte Funktionen ergänzen, und es gibt keinen Weg für Kern-Maintainer, das zu verhindern.
  • Dass das MIT AI Lab mit dem aktuellen KI-Boom verbunden ist, habe ich gerade neu erfahren – spannend.
• Solche Tools machen mich sehr optimistisch. Ich mag es, Emacs und KI in den Coding-Flow einzubinden, aber vor allem möchte ich das auf eigener Hardware für unter 2000 Dollar lokal ausführen. Ich frage mich, ob das heute oder in naher Zukunft möglich ist und ob jemand bereits einen Coding-Agenten mit lokalem Modell nutzt.
  • Bei speichereffizienter Inferenz und Open-Source-Modellen, die auf Code spezialisiert sind, gibt es gerade enorme Fortschritte. Aktuell wird die Qwen3-Coder-Modellfamilie stark beachtet (Qwen3-Coder). Für den lokalen Einsatz gibt es Tools wie Ollama und LM Studio. Je nach Modellgröße und Quantisierung kann man mit einem Budget von 2000 sogar sehr viele Modelle betreiben; M-Serie-Macs sind dabei ein gutes Preis-Leistungs-Verhältnis. Für lokale LLM-Anwendungen gibt es viele Infos im Subreddit LocalLlamas. Die Möglichkeiten reichen nicht an große KI-Forschungsgruppen heran, aber für alle, die vollständig lokale Setups bevorzugen, ist das eine spannende und lohnenswerte Spielwiese.
  • gptel unterstützt viele Modelle, inklusive lokaler Modelle.
  • Als Option kommen auch Mac mini oder frame.work desktop, oder Nvidia DGX Spark infrage (Minimum 3k).