Der Zauber von Claude Code: Warum die Unix-Philosophie und der Dateisystemzugriff Claude Code besonders machen

• Claude Code hat sich über ein einfaches Coding-Tool hinaus zu einem Agenten-Betriebssystem entwickelt und unterstützt durch Dateisystemzugriff und die Integration von Unix-Befehlen vielfältige Workflows als innovatives System
• Besonders durch die Integration mit dem Obsidian-Notizsystem automatisiert es das Schreiben von Notizen, Recherche und die Strukturierung von Gedanken und realisiert per SSH-Verbindung sogar mobil ein vollständiges Betriebssystem für Notizen
• Die Funktion Dateisystemzugriff ist das zentrale Unterscheidungsmerkmal, da sie Speicher und Zustand über mehrere Unterhaltungen hinweg ermöglicht und damit die Beschränkung des Kontextfensters und die Speicherprobleme löst, die bei ChatGPT oder Claude im Browser eine gravierende Schwäche darstellen
• Die Unix-Philosophie (Einfachheit, Kombinierbarkeit, Verarbeitung von Textströmen) stimmt perfekt mit der Art überein, wie LLMs Werkzeuge verwenden, sodass 50 Jahre alte Designprinzipien als optimale Architektur für moderne KI-Systeme wiederentdeckt werden
• Anhand praktischer Anwendungsfälle wie der Automatisierung des E-Mail-Managements (Inbox Magic) und Open-Source-Tools (Claudesidian) wird betont, dass dateisystembasierte Agentensysteme die Grundlage für den Aufbau zuverlässiger und debuggbarer KI-Anwendungen sind – mehr als komplexe Multi-Agenten-Strukturen

---

Was Claude Code besonders macht

• Ich habe in letzter Zeit in Gesprächen über KI immer wieder begeistert über die erstaunlichen Fähigkeiten von Claude Code gesprochen und erklärt, dass sich dieses Tool von einer einfachen Coding-Hilfe zu einem vollständigen Agenten-Betriebssystem entwickelt hat
• Besonders die Integration mit der Notiz-App Obsidian ist der Schlüssel: Anders als Notion oder Evernote speichert Obsidian alle Dateien als normale Markdown-Dateien auf der lokalen Festplatte
  • Genau diese Eigenschaft machte es zu einem idealen Ziel für ein KI-Coding-Tool; anfangs begann ich mit Cursor, wechselte aber bald zu Claude Code
  • Ich wurde von diesem System so abhängig, dass ich schließlich zu Hause einen Server aufgesetzt habe und per SSH vom Smartphone darauf zugreife, um auch unterwegs Notizen zu schreiben, zu lesen und Gedanken zu ordnen
• Vor einigen Wochen war ich im AI & I Podcast von Dan Shipper zu Gast und habe dieses System ausführlich erklärt; in diesem Artikel teile ich zusätzliche Erkenntnisse, zu denen ich seitdem gekommen bin

Warum Claude Code Cursor überlegen ist

• Auf die Frage „Warum ist Claude Code besonders?“ fiel mir eine Antwort schwer, aber ich bin zu dem Schluss gekommen, dass es nicht in jeder Hinsicht besser als Cursor ist, sondern dass eine Kombination bestimmter Elemente außergewöhnlich gut funktioniert
• In letzter Zeit nutze ich es mehr, um etwas völlig Neues auf Basis der Funktionen von Claude Code aufzubauen, statt nur in bestehenden Codebasen zu arbeiten

• Perfekte Harmonie mit der Unix-Philosophie

  • Das Geheimnis von Claude Code liegt in seinem Werkzeugansatz: Als terminalbasierte Anwendung verzichtet es zwar auf Zugänglichkeit, bietet dafür aber die mächtige Funktion einer nativen Integration von Unix-Befehlen
  • Die Unix-Philosophie wurde 1978 von Doug McIlroy im Bell System Technical Journal dokumentiert und formuliert vier Kernprinzipien:
    • 1. Jedes Programm sollte eine Sache gut machen. Für neue Aufgaben sollte man lieber ein neues Programm bauen, als einem bestehenden weitere Funktionen hinzuzufügen
    • 2. Die Ausgabe jedes Programms sollte so gestaltet sein, dass sie als Eingabe für ein anderes, möglicherweise noch unbekanntes Programm dienen kann
    • 3. Software sollte so entworfen und gebaut werden, dass man sie früh – idealerweise innerhalb weniger Wochen – ausprobieren kann
    • 4. Zur Entlastung der Programmierarbeit sollte man Werkzeuge einsetzen statt ungelernter Arbeitskräfte
  • Peter H. Salus fasste das 1994 in „A Quarter-Century of Unix“ so zusammen:
    • Schreibe Programme, die eine Sache gut machen
    • Schreibe Programme, die zusammenarbeiten
    • Schreibe Programme, die Textströme verarbeiten (weil das eine universelle Schnittstelle ist)

• Die perfekte Passung von LLMs und Unix-Befehlen

  • Diese 50 Jahre alten Prinzipien stimmen exakt mit der Art überein, wie LLMs Werkzeuge nutzen
  • Modelle „pipen“ ihre Ausgaben fortlaufend in Eingaben weiter (mit einer gewissen eigenen Unschärfe dazwischen) und verbinden damit wie beim Unix-Befehl | die Ausgabe eines Befehls mit der Eingabe des nächsten
  • Wenn Modelle Werkzeuge nicht effektiv kombinieren können, liegt das fast immer daran, dass die Werkzeuge zu komplex sind
  • Der erste Grund, warum Claude Code so erstaunlich ist: Die Befehle, die Unix antreiben, sind perfekt für die Nutzung durch LLMs geeignet
    • Die Befehle sind nicht nur einfach, sondern auch hervorragend dokumentiert, sodass reichlich Quellenmaterial für das Training der Modelle vorhanden war

• Die Revolution des Dateisystemzugriffs

  • Ein weiterer Faktor ist die Fähigkeit von Claude Code, Code zu schreiben und inzwischen auch Prosa zu verfassen
  • Beim Lesen des Artikels Pragmatic Engineer: Eine tiefgehende Analyse des Aufbaus von Claude Code habe ich die Antwort gefunden: Dateisystemzugriff
  • Das Dateisystem verändert alles
    • Zwei fatale Schwächen von ChatGPT und Claude im Browser: fehlender Speicher zwischen Gesprächen und ein enges Kontextfenster
    • Das Dateisystem löst beides: Claude Code kann sich selbst Notizen schreiben, Wissen ansammeln und laufende Zusammenstellungen pflegen
    • Es verfügt über Zustand und Speicher und kann über ein einzelnes Gespräch hinaus denken

KI-Overhang (AI Overhang)

• Als ich 2022 erstmals die GPT-3-API nutzte, sagte ich voraus, dass es 10 Jahre dauern würde, passende Anwendungsfälle zu entdecken – selbst wenn die Modelle ab diesem Moment nicht besser würden
• Die Modelle wurden tatsächlich besser (insbesondere machten Reasoning-Modelle Tool-Calls zuverlässig), und die Entdeckung des Dateisystems bestätigt diese These
• Im Pragmatic Engineer-Interview erklärt Boris Cherney, der frühe Versionen von Claude Code gebaut hat, dies mit dem Konzept des „product overhang“:
  • Product overhang bedeutet, dass ein Modell eine bestimmte Aufgabe bereits ausführen kann, das Produkt, in dem die KI läuft, aber nicht so gebaut ist, dass es diese Fähigkeit einfängt
  • Das Modell konnte das Dateisystem also schon erkunden, nur gab es noch kein Produkt, das genau um diese Fähigkeit herum gebaut war
• Der Autor argumentiert zwar für die Kombination aus Dateisystem und Unix-Befehlen, aber im Kern geht es darum, dass die Fähigkeiten der Modelle bereits vorhanden waren und nur darauf warteten, geweckt zu werden
• Claude Code dient als Blaupause dafür, wie sich verlässliche Agentensysteme bauen lassen, weil es die Fähigkeiten des Modells einfängt, statt sie durch überdesignte Interfaces zu begrenzen

Jenseits von Code

Das Open-Source-Projekt Claudesidian

• Ich habe über mein Claude-Code-plus-Obsidian-Setup gesprochen und bin sogar noch einen Schritt weitergegangen, indem ich „Claudesidian” als Open Source veröffentlicht habe
  • Es enthält viele der Tools und Befehle, die ich in meinem Claude-Code-plus-Obsidian-Setup verwende
  • Ich habe es als Experimentierfeld genutzt und insbesondere ein frühes Upgrade-Tool gebaut
  • Wenn zentral Änderungen auftreten, kann ich sie in mein Claudesidian übernehmen, und die KI prüft, ob es Konflikte mit den lokal geänderten Dateien gibt, und versucht diese dann intelligent mit den neuen Updates zusammenzuführen
• Beide Projekte folgen denselben Prinzipien der Unix-Philosophie: einfach, kombinierbar, Werkzeuge, die eine Sache gut machen und zusammenarbeiten

Inbox Magic – ein System zur E-Mail-Automatisierung

• Ich arbeite derzeit an einem Projekt namens „Inbox Magic“ (ein besserer Name ist noch geplant), das noch nicht bereit für die Veröffentlichung ist, aber bald vorgestellt werden soll
• Es handelt sich um ein Claude-Code-Repository mit Zugriff auf ein Gmail-Toolset, das über viele Prompts und Befehle wie ein E-Mail-Assistent arbeitet
• Die aktuellen Funktionen sind recht einfach:
  • Es kann Suchen ausführen oder alternativ E-Mails versenden
  • Es kann ein vollständiges Training durchführen, um E-Mails zu klassifizieren und den Stil beim Schreiben von E-Mails zu lernen
  • Sowohl Claude Code als auch ChatGPT können auf E-Mails zugreifen, holen aber meist nur ein oder zwei gleichzeitig ab
  • Dieses System kann in Dateien schreiben und verschiedene Tricks einsetzen, um Aufgaben auszuführen wie: „Finde alle reisebezogenen E-Mails im Posteingang, erstelle daraus ein Profil meiner Reisegewohnheiten und nutze dieses als Prompt, damit ChatGPT/Claude Recherchen zu Reisen anhand meiner tatsächlichen Vorlieben durchführen kann“
• Wer es testen möchte, kann mir seinen GitHub-Benutzernamen schicken; ich teile es, sobald es testbereit ist

Die zentrale Lehre

• Normalerweise vermeide ich Schlussfolgerungen, aber hier gibt es einige Punkte, die es wert sind, noch einmal betont zu werden:
• 1. Das Dateisystem ist ein hervorragendes Werkzeug, um den Mangel an Speicher und Zustand bei LLMs zu lösen, und sollte häufiger genutzt werden
• 2. Wer Tool-Calls zum Laufen bringen will, sollte sich darauf konzentrieren, der Unix-Philosophie zu folgen
• 3. Claude Code stellt eine Blaupause für zukünftige Agentensysteme dar
  • Dateisystem + Unix-Philosophie sollten die Vorlage sein, um zuverlässige und debuggable KI-Agenten zu bauen – statt der heute kursierenden komplexen Multi-Agenten-Systeme
  • Taktisch gesehen ist es entscheidend, Tool-Calls im eigenen Projekt einfach zu halten und dem Haupt-Thread des Modells zu erlauben, sie zu „pipen“
  • Das große Problem, das bei allen Agenten/Chatbots gelöst werden muss: die Fähigkeit, Dinge weiterzuleiten, ohne durch das Kontextfenster zu müssen
• 4. Wer keine Anwendungsfälle für LLMs findet, bemüht sich nicht genug

[GN⁺]

Hacker-News-Meinung

• Mir gefällt an Claude Code wirklich, dass es auf Unix-Art funktioniert: Man kann leicht andere Unix-artige Tools bauen, und Claude kann sie ohne zusätzliche Integrationsarbeit sofort verwenden. Wenn man ihm nur die Manpage eines Tools gibt, nutzt Claude es souverän. Das geht ganz ohne MCP oder komplexe Tool-Definitionen. Es funktioniert auch problemlos mit einem selbst gebauten Tool für den Browser-Zugriff.

  • Kürzlich habe ich angesichts des LLM-Zeitalters ein Tool aktualisiert, das Manpages besser durchsuchbar macht: Mansnip. Ich denke, es wäre auch eine gute Idee, das als STDIO MCP zu verpacken. Man könnte diesem Code einfach noch eine API geben und den Server bei pip bereitstellen. So schwierig dürfte das nicht sein.

  • Ich frage mich, wie Claude Code in meinen Skripten oder Tools den Browser verwendet. Ich würde gern bestehende Safari-Sitzungsfenster direkt steuern, aber meistens wird nur mit Chrome oder einer separaten neuen Instanz gearbeitet.

  • Es gab einen Moment, in dem mir klar wurde, dass es viel effizienter ist, Claude die Nutzung eines Linters beizubringen, als ihn direkt nach Fehlern suchen zu lassen. Ich musste ihm nicht einmal sagen, welchen Linter er verwenden soll: Ich habe einfach eine Liste genannt und ihn installieren lassen, und er hat sie sofort genutzt. Als ich mit ChatGPT Coding ausprobiert habe, brauchte es viel zu viel Aufwand, um nützliche Ergebnisse zu bekommen, deshalb hatte ich keine großen Erwartungen — aber mit Claude Code ist es wirklich eine erstaunliche Erfahrung.

• Alle GUI-Apps sind jeweils anders und existieren wie Burgen mit ihren eigenen Mauern, fast wie isolierte Lehen innerhalb des OS. Die CLI dagegen ist ein gemeinsamer Marktplatz, auf dem sich alle treffen, ein Informationsmarkt, auf dem Daten und Signale ausgetauscht werden. Man muss nicht einmal irgendein Zugehörigkeitsgefühl mitbringen, um diesen Platz zu betreten. Das Nächstliegende auf der GUI-Seite wäre Smalltalk, aber selbst dort kommt man nur hinein, wenn man vorher Treue schwört.

  • Tatsächlich gibt es auch in der GUI-Welt Systeme mit ziemlich hoher Interoperabilität und Kombinierbarkeit, etwa NextSTEP oder dbus. Wenn man will, kann man auch GUIs auf Basis offener APIs bauen und nur eine grafische Ebene darüberlegen. Das ist selten, aber technisch möglich.

  • Selbst wenn sie wie in das OS eingeschlossene Festungen wirken, bevorzugen normale Nutzer GUI-Apps deutlich gegenüber CLI-Apps. Wenn es nur die CLI gegeben hätte, hätte sich der Computer wohl viel langsamer verbreitet.

• Nur weil ein neu aufgekommenes Tool im Terminal läuft, ist das nicht automatisch eine „echte Umsetzung der UNIX-Philosophie“. Schon dieser Vergleich ergibt keinen Sinn. Ich bin damit wohl selbst auf einen typischen Hacker-News-Köder hereingefallen.

  • Mit UNIX-Philosophie ist hier nicht einfach nur eine Terminal-App gemeint, sondern entscheidend ist, dass moderne LLMs Shell-Befehle direkt ausführen können. Dadurch sind LLMs an einem Punkt, an dem sie fast alles tun können, was auch ein Mensch in der Shell tun kann.

  • Betrachtet man den Kern der UNIX-Philosophie, dann sind das 1) kleine Programme, die genau eine Sache tun, 2) diese lassen sich kombinieren, um komplexere Aufgaben zu lösen, und 3) Textströme als universelle Schnittstelle. Das passt extrem gut zu LLMs. Dank einer einheitlichen Textschnittstelle wie exec() arbeiten alle Tools auf Dateien und können per Text ein- und ausgeben, sodass LLMs sie sofort nutzen können. Diese Softwarestruktur ist keineswegs zwingend, aber so wie sie aufgebaut wurde, passt sie perfekt zu LLMs.

  • Sogar die Top-3-Kommentare wirken, als hätte ein LLM sie zum Eigenmarketing schreiben lassen.

• Früher hat man oft gehört, die CLI sei tot, aber in letzter Zeit ist die CLI dank Tools wie Claude Code eher zur überlegenen Schnittstelle geworden. Ich will daraus natürlich keinen Gegensatz konstruieren, aber dieser Wandel ist interessant.

  • Tatsächlich hat man aus Sicht von Entwicklern und anderen fortgeschrittenen Nutzern nie wirklich gehört, dass „CLI is dead“ sei. Für normale Nutzer mag es nach dem Aufkommen von GUIs so wirken, als sei die CLI verschwunden, in Wirklichkeit war sie aber immer im Hintergrund da. Mit OS X bekam man eine echte Unix-Shell, Windows hat PowerShell, und Linux dominiert den Servermarkt ohnehin.

  • Ich baue auch selbst maßgeschneiderte GUI-Oberflächen. Ich erschaffe mir praktisch eine komplette Desktop-Umgebung nach meinem eigenen Geschmack. Früher habe ich oft das Terminal benutzt, weil die gängigen GUI-Tools unbequem waren, aber inzwischen wird meine eigene UI-Umgebung immer besser.

• Die Kombination aus Claude und Obsidian ergibt einen wirklich guten Workflow. Wiederkehrende Aufgaben bei der Notizverwaltung überlasse ich komplett der KI. Ich sammle tägliche Notizen als eine Art Stream of Consciousness und extrahiere daraus neue Ideen, Projekte und Materialien. Gemini funktioniert ebenfalls gut genug.

• Bei der LLM-Integration mit Obsidian möchte ich unbedingt das Plugin-Thema erwähnen. Obsidian-Plugins lassen sich leicht anpassen, und JavaScript-Skripte können in lokalen Ordnern ausgeführt werden. Claude Code ist hervorragend darin, solche Plugins zu schreiben und zu ändern. Ich habe zum Beispiel ein eigenes Programm gebaut, das Obsidian-Dateien anhand eines Publish-Flags automatisch mit einem Github-Repo synchronisiert. Dadurch wird meine Website auf Netlify sofort aktualisiert, sobald ich meine Notizen ändere.

• Für den Autor wäre vielleicht eher ein Dienst wie omnara.com passend, bei dem man direkt vom Smartphone aus zugreifen kann, ohne SSH. Ich nutze eine ähnliche Umgebung, in der Obsidian und Claude Code headless dauerhaft laufen und ich direkt über eine Smartphone-App darauf zugreife.

• Ich würde Claude Code gern nutzen, weiß aber nicht genau, wie viele lokale Daten und Dateien tatsächlich über das Netzwerk übertragen werden. In manchen Situationen ist die Einführung deshalb schwierig.

• Ich habe über MCP selbst folgende Funktion implementiert:
  { "name": "unshare_exec", "description": "Binärdatei mit unshare in einem Linux-Namespace ausführen", "inputSchema": { "type": "object", "properties": { "binary": {"type": "string"}, "args": {"type": "array", "items": {"type": "string"}} }, "required": ["binary"], "additionalProperties": false } }
  Anfangs habe ich nur unshare verwendet und unterwegs einiges an yak shaving betrieben, aber am Ende konnte ich lokal gemma3 ausführen und Debian-basierte Utilities frei laufen lassen, was zu erstaunlichen Ergebnissen geführt hat.

  • Könntest du vielleicht das Fell dieses Yaks teilen, also die vorbereiteten Materialien? Meine bisherigen Erfahrungen mit lokalen LLMs waren nicht besonders zufriedenstellend.

• Ich wünsche mir eine vollständig lokale Umgebung mit Obsidian, einem lokalen LLM und allem als Open Source. Auf so eine Zukunft hoffe ich.

  • Durch LLMs steigen Nutzwert und Bedeutung von Open-Source-Programmen noch weiter. Früher war selbst bei Open Source das Verständnis der Codestruktur so aufwendig, dass man Programme nicht leicht selbst anpassen konnte. Jetzt lassen sich mit LLMs kleine Patches oder neue Features viel einfacher umsetzen. Das heißt: Ein Programm muss Open Source sein, damit ich es nach meinen Bedürfnissen ändern kann, und das ist wichtiger denn je.

  • Open Weights allein reichen nicht aus; man muss auch Datensätze und Trainings-Pipeline selbst handhaben können, damit es wirklich Bedeutung hat. Natürlich fehlt normalen Nutzern meist die Infrastruktur, um eine Trainings-Pipeline selbst zu betreiben, aber man muss transparent nachvollziehen können, wie Daten verwendet werden und wie das Modell trainiert wurde, damit echte Kontrolle und eine Bewertung von Bias möglich sind.

  • Eine lokale Org mode-Umgebung, ein lokales LLM, alles durch Emacs orchestriert und vollständig mit freier Software betrieben — das wäre großartig. Wenn ich im Ruhestand einmal viel Zeit habe, würde ich das unbedingt ausprobieren.

  • Falls es dich interessiert, empfehle ich diesen Artikel: https://laurentcazanove.com/blog/obsidian-rag-api

  • Ist es in der Praxis nicht eigentlich unmöglich, ein Modell in wirklich brauchbarer Größe lokal laufen zu lassen? Besonders auf einer Entwickler-Maschine mit 64 GB RAM und einem Single-GPU-Setup dürfte das schwer sein.