44-2.de

Understanding technology by building it

Kategorie: KI-gestützte Entwicklung

  • Claude Code in a Box – Vom Programmierer zum Architekten mit einem Docker-Container

    Claude Code in a Box – Vom Programmierer zum Architekten mit einem Docker-Container

    Etwas hat sich in meiner Art zu programmieren verändert. Nicht nur bei den Tools, die ich nutze – sondern auch in meiner Einstellung zur Arbeit selbst.

    Es ist nicht wirklich ein Agent. Aber es fühlt sich so an.

    Ich habe kürzlich darüber geschrieben, warum Kontext die fehlende Ebene in KI-gesteuerter Arbeit ist – die Idee, dass die Abfolge Daten → Analyse → Kontext → Aktion lautet und dass ohne Kontext selbst intelligente Systeme begrenzt bleiben. Du kannst diesen Beitrag hier lesen.

    Claude Code ist ein gutes Beispiel dafür in der Praxis. Es ist kein wirklich autonomer Agent. Es plant keine mehrstufigen Strategien von selbst. Es verfügt standardmäßig nicht über ein sitzungsübergreifendes Gedächtnis. Aber wenn man ihm den richtigen Kontext gibt – die Codebasis, die Anforderungen, die Fehlerprotokolle, die Hardware-Spezifikationen – passiert etwas Interessantes. Es fängt an zu handeln, anstatt nur zu antworten. Es schreibt, führt aus, liest die Ausgabe, passt sich an und iteriert. Diese Rückkopplungsschleife – Code, Ausführen, Beobachten, Korrigieren – ist es, was es wie einen Agenten wirken lässt, auch wenn es technisch gesehen keiner ist.

    Die Intelligenz war schon immer im Modell vorhanden. Was sie freisetzt, ist der Kontext. Und darum geht es in diesem Beitrag: darum, den richtigen Rahmen für diesen Kontext zu schaffen – im wörtlichen wie im übertragenen Sinne.

    Die alte Methode war frustrierend

    Ich habe schon früh angefangen, mit Claude Code zu experimentieren. Das Konzept ist großartig: Gib einer KI eine Aufgabe, lass sie Code schreiben, ihn ausführen, schau, was kaputtgeht, behebe es, wiederhole. Vollständig autonom.

    Aber die Standarderfahrung war nervig. Ständige Bestätigungsaufforderungen. „Soll ich fortfahren?“ – ja. „Bist du sicher?“ – ja, mach es einfach. Das zerstört jegliches Gefühl von Flow.

    Dann hörte ich von --dangerouslySkipPermissions. Das entfernt alle Sicherheitsbarrieren. Claude führt einfach aus. Was großartig klingt – bis dir klar wird, dass du einen autonomen KI-Agenten mit vollem Zugriff auf deinen eigentlichen PC laufen lässt. Dein Home-Verzeichnis. Deine SSH-Schlüssel. Alles.

    Ich habe auch versucht, Claude auf einem isolierten Rechner zu laufen – einem alten Raspberry Pi –, was zwar funktionierte, aber umständlich war und keine richtige Entwicklungsumgebung bot. Keine langfristige Lösung.

    Ein Schweizer auf YouTube hatte die richtige Idee

    Ich bin zufällig auf dieses Video gestoßen. Andreas Spiess – seltsamer Akzent, tolle Ideen –, der Claude Code einfach in einer virtuellen Maschine installiert und dort mit vollen Berechtigungen ausgeführt hat. Saubere Isolation. Kein Risiko für den Host.

    Die Richtung war richtig. Aber eine vollständige VM ist schwerfällig. Ich wollte etwas Leichteres, das schneller hochfährt und entwicklerfreundlicher ist.

    Nach ein bisschen Recherche fand ich VS Code Dev Containers – und sie erwiesen sich als perfekte Lösung.

    Was ist ein Dev Container?

    Ein Dev Container ist einfach ein Docker-Container – aber mit einem speziellen .devcontainer/ Konfigurationsordner in deinem Projekt. Wenn du das Projekt in VS Code öffnest, erkennt es diese Konfiguration und fragt: „Im Container erneut öffnen?“

    Du klickst auf „Ja“. VS Code öffnet sich erneut. Derselbe Editor. Dieselben Erweiterungen. Dasselbe Terminal. Aber jetzt läuft alles innerhalb von Docker. Der Container ist von deinem Host isoliert. Dein eigentliches Dateisystem, dein Home-Verzeichnis, deine anderen Projekte – unsichtbar und von innen nicht erreichbar.

    Du merkst gar nicht, dass du dich in einem Container befindest. Genau darum geht es.

    Das ist genau die Sandbox, die Claude Code benötigt, um sicher mit vollen Berechtigungen zu laufen.

    Die Vorlage, die ich erstellt habe

    Ich habe auf GitHub eine wiederverwendbare Vorlage erstellt – eine einsatzbereite Dev-Container-Konfiguration für Claude Code mit einem klaren Sicherheitsmodell und einer praktischen Projektstruktur.

    Sicherheitsmodell – was geschützt ist:

    • Host-Dateisystem: Nur der ./project Ordner wird eingebunden – nichts anderes auf deinem PC ist innerhalb des Containers sichtbar
    • Kein privileged -Modus: Der Container kann nicht in den Host-Kernel entkommen
    • SSH-Schlüssel: werden nie kopiert – der SSH-Agent-Socket des Hosts wird weitergeleitet, die Schlüssel bleiben auf deinem Rechner
    • GitHub-Token: wird als Umgebungsvariable übergeben, niemals im Container gespeichert
    • USB-Zugriff: Hot-Plug-Unterstützung für ESP32 und Arduino über device_cgroup_rules – kein vollständiger /dev Zugriff erforderlich

    Es gibt außerdem eine optionale Outbound-Firewall, die Claude auf Domains der Whitelist beschränkt (Anthropic API, GitHub, npm, VS Code). Ich lasse sie normalerweise deaktiviert und beobachte einfach, was Claude macht – aber sie ist da, falls du sie nutzen möchtest.

    Die Projektstruktur – Der Kontext ist alles

    Der Container bietet Claude einen sauberen, isolierten Arbeitsbereich. Aber der eigentliche Einblick liegt darin, was sich im project/ Ordner. Hier befindet sich der Kontext – und der Kontext ist es, der Claude Code von einer beeindruckenden Demo zu einem echten Werkzeug macht.

    project/
  CLAUDE.md          ← session bootstrap: tells Claude what to read at startup
  requirements.md    ← what you're building — written by you, for Claude
  memory.md          ← live session memory — Claude writes here
  skills/            ← working conventions, loaded every session
  knowledge/         ← confirmed config and integration notes
  external-docs/     ← raw reference material (API docs, specs)
  src/               ← the actual source code

    Bei jeder Sitzung liest Claude CLAUDE.md zuerst. Diese Datei weist ihn an, requirements.md, alle Skill-Dateien und alle Wissensdateien zu laden, bevor er irgendetwas anderes tut. Claude kennt den vollständigen Projektkontext, bevor er auch nur eine einzige Zeile Code schreibt.

    requirements.md ist die Schlüsseldatei – und sie zu schreiben ist jetzt deine Hauptaufgabe. Du schreibst keinen Code mehr. Du schreibst, was du willst. Du beschreibst die Funktion. Du denkst die Architektur durch. Du definierst Einschränkungen. Du legst das Verhalten fest. Claude liest es und setzt es um.

    Das ist die Veränderung, die ich am Anfang erwähnt habe. Du wechselst vom Programmierer zum Architekten. Die Arbeit ändert sich – es geht nicht mehr um Syntax, sondern um klare Gedanken. Wenn du genau beschreiben kannst, was du willst, kann Claude es umsetzen. Wenn deine Anforderungen vage sind, wird auch das Ergebnis vage sein. Gutes Denken führt zu gutem Code.

    Skills sind wiederverwendbarer Kontext. Eine Skill-Datei kann definieren, wie Code für ein bestimmtes Hardware-Board strukturiert werden soll, welche GPIO-Pins verfügbar sind, welche Bibliotheken verwendet werden sollen und welche Fallstricke zu vermeiden sind. Du schreibst den Skill einmal – und fügst ihn in jedes Projekt ein, das dieses Board verwendet. Claude arbeitet sofort effizienter, weil es die Umgebung bereits kennt, bevor du beginnst.

    Wissensdateien sammeln Wissen. Wenn Claude eine knifflige Integration herausfindet – eine funktionierende Konfiguration für eine Bibliothek, eine bestätigte Pin-Zuordnung, ein getestetes Setup – schreibt es das in knowledge/. Bei der nächsten Sitzung startet es mit diesen bereits geladenen Informationen. Kein erneutes Herausfinden.

    Ein neues Projekt starten: Drei Schritte

    Die Vorlage ist so konzipiert, dass sie pro Projekt kopiert wird. Ein Neuanfang geht schnell:

    1. Kopiere den Vorlagenordner und benenne ihn nach deinem Projekt
    2. Bearbeite .env: Setze COMPOSE_PROJECT_NAME auf einen eindeutigen Namen
    3. Öffne den Ordner in VS Code → „Reopen in Container“ → gib den API-Schlüssel ein → starte Claude mit --dangerouslySkipPermissions

    Jedes Projekt erhält einen eigenen isolierten Container, ein eigenes Claude-Konfigurationsvolume und einen eigenen Shell-Verlauf. Keine gegenseitige Beeinflussung zwischen den Projekten.

    Die ESP32-Rückkopplungsschleife – Hardware wird spannend

    Der USB-Passthrough ist das, was Hardware-Projekte wirklich spannend macht.

    Claude Code schreibt nicht nur Firmware – er flasht sie über USB auf den ESP32, liest das serielle Debug-Protokoll und reagiert automatisch auf Fehler. Der Kreislauf sieht so aus:

    Code schreiben → flashen → serielle Ausgabe lesen → Fehler beheben → erneut flashen.

    Und das alles, ohne dass ich etwas anfassen muss. Claude steuert den gesamten Zyklus.

    Ich arbeitete an einem Touchdisplay-Projekt. Claude konnte den Bildschirm natürlich nicht sehen. Also fragte es mich einfach: „Ich kann das Display nicht sehen. Sieht es richtig aus? Sag einfach Ja oder Nein.“ Ansonsten war es vollkommen zufrieden damit, den Debug-Port auszulesen und selbstständig zu iterieren.

    Diese Rückkopplungsschleife ist die konkrete Hardware-Version desselben Prinzips aus meinem anderen Beitrag. Das Modell ist intelligent. Aber was es zum Handeln bringt, ist der Kontext: der Code, das Fehlerprotokoll, die serielle Ausgabe, die bestätigte Hardwarekonfiguration in knowledge/. Nimm irgendetwas davon weg, und die Schleife bricht ab.

    Echte Projekte, die so umgesetzt wurden

    Das ist keine Theorie. Ich habe dieses Setup verwendet, um mehrere echte Projekte zu realisieren:

    • Soundbox – Hardware-Audio-Projekt mit ESP32: Claude hat die Firmware geschrieben, sie per USB geflasht, das serielle Protokoll gelesen und autonom debuggt
    • PyLearn – eine Python-Lern-App, hier auf 44-2.de gepostet – an ein paar Abenden erstellt
    • Eine Firefox-Erweiterung, die die Perplexity-Chat-Seitenleiste auf die gesamte Bildschirmbreite erweitert – an einem Abend fertig

    Projekte, für die ich früher Wochen gebraucht hätte, dauern jetzt zwei oder drei Abende. Und die Codequalität? Ehrlich gesagt, mindestens so gut wie meine. Oft besser strukturiert. Manchmal besser dokumentiert, als ich mir die Mühe gemacht hätte.

    Vorsicht

    Ein paar echte Risiken, die du kennen solltest:

    • API-Kosten: Claude ruft die Anthropic-API frei aus dem Container heraus auf. Lege ein Ausgabenlimit auf console.anthropic.com fest – im Ernst, tu das, bevor du anfängst.
    • Git-Push-Risiko: Claude hat Zugriff auf deinen weitergeleiteten SSH-Schlüssel und kann Remote-Branches pushen oder löschen. Schütze deine wichtigen Branches auf GitHub oder richte ENABLE_GIT=false in .env.
    • USB-Sicherheit: Das /dev Dateisystem ist für die USB-Unterstützung als Bind-Mount eingebunden. Nur ttyACM und ttyUSB Geräteklassen sind über cgroup-Regeln zugänglich – aber sei dir bewusst, was du damit aktivierst.
    • Firewall-Umgehung: Wenn du NET_ADMIN für die optionale Firewall, könnte Claude theoretisch seine eigenen iptables-Regeln löschen. Akzeptabel, wenn du dem Modell vertraust. Entferne die Fähigkeit, wenn du das nicht tust.

    Die Container-Isolation ist sehr gut. Es ist keine Zauberei. Sei dir der Kompromisse bewusst.

    Was kommt als Nächstes

    Ein paar Dinge, die ich untersuchen möchte:

    • Mehr Skill-Dateien für verschiedene Hardware-Boards – ESP32-S3, RP2040, verschiedene Arduino-Varianten – jeweils mit Pinbelegungen, bewährten Bibliotheken und bereits geladenen Fallstricken
    • Bessere Firewall-Profile: projektspezifische Zulassungslisten statt einer globalen Liste

    Der tiefergehende Gedanke dahinter ist, dass Skill-Dateien zu einer Community-Ressource werden könnten. Teile den Skill für dein Board, dein Framework, dein Setup – und die Claude-Sitzungen aller werden sofort smarter in Bezug auf diese Umgebung.

    Die Vorlage findest du auf GitHub: happychriss/claude-code-container

    Kopiere sie. Bearbeite requirements.md , ändere die .env-Datei mit deinem Projektnamen und aktualisiere bei Bedarf dein USB-Gerät. Beschreibe, was du erstellen möchtest (und wenn du möchtest – welche Plattform oder Sprache). Schau zu, was passiert.

  • ESP32-Soundmaschine in einem IKEA-Bilderrahmen

    ESP32-Soundmaschine in einem IKEA-Bilderrahmen

    Ein Freund von mir hat einen ganz besonderen Musikgeschmack. Als unsere Gruppe also beschloss, Geschenke zu machen, die alle – im wahrsten Sinne des Wortes – in einen gemeinsamen Rahmen passen, kam mir eine Idee. Warum nicht eine echte Soundmaschine in einen IKEA-Bilderrahmen bauen? Gesamtbudget: unter 30 €, ein Wochenende und ein KI-Programmierassistent. Los geht’s.

     

    Die Hardware

    Ich hatte nicht viel Zeit, also habe ich einfach alles auf einmal bei AliExpress bestellt:

    • Ai-Thinker ESP32-Audio-Kit (ESP32-A1S V2.2) – ESP32 mit integriertem ES8388-Audio-Codec, zwei NS4150-Class-D-Verstärkern, SD-Kartensteckplatz, Bluetooth, sechs Hardware-Tasten, alles auf einer Platine. Etwa 17 €.
    • WS2812B-LED-Streifen, 30 LEDs – einzeln adressierbares RGB, angeschlossen an GPIO22. Etwa 4 €.
    • Zwei kleine Lautsprecher aus meinem Bastelvorrat.
    • Ein 5×7"-Bilderrahmen von IKEA – 5 €.
    • Ein USB-Stromkabel für 5-V-Versorgung.

      • Das war’s. Keine selbstbestückte Leiterplatte, kein Wirrwarr auf dem Steckbrett. Die Platine hat zwei USB-Anschlüsse – einen zum Flashen, einen für die Stromversorgung –, was die Sache noch übersichtlicher macht.

      Die Lautsprecher sitzen im Rahmen und sind auf die Kunststoffrückwand geklebt. Wenn ich das noch einmal bauen würde, würde ich sie direkt am Holzrahmen befestigen, damit dieser als Resonanzkörper fungiert – der 6-W-Verstärker ist da, die 4-Ω-Treiber sind da, aber im Moment entweicht der Klang durch den Kunststoff. Für 5-Euro-Lautsprecher klingt es immer noch überraschend gut. Mit dem Rahmen als Resonanzkörper wäre es wirklich hervorragend.

      Der Bau

      Alles wird mit doppelseitigem Klebeband und einer Heißklebepistole zusammengefügt. Das einzige, was gelötet werden muss, ist:

      1. Lautsprecherkabel an die JST-Anschlusspads der Platine
      2. Strom- und Signalkabel des LED-Streifens an die Platine

        3. Die Platine ist leicht in die Rückseite des Rahmens eingelassen, sodass nichts über die Rahmentiefe hinausragt. Du kannst das direkt an die Wand hängen.

        Eine Kleinigkeit, die ich beim nächsten Mal hinzufügen würde: einen externen Netzschalter. Momentan zieht man einfach den Stecker. Funktioniert zwar gut, aber trotzdem.

        Was es kann

        Der Funktionsumfang ist letztendlich ziemlich komplett geworden:

        • Spielt alle .mp3 Dateien aus dem Stammverzeichnis der SD-Karte in alphabetischer Reihenfolge der Dateinamen ab, in einer Endlosschleife
        • _welcome.mp3 wird beim Hochfahren immer als Erstes abgespielt (Unterstriche werden vor Buchstaben sortiert) – das Gerät begrüßt dich mit einem violetten Lichtrahmen
        • KEY1 kurz drücken: Pause/Weiter
        • KEY1 lang drücken (2 s): Bluetooth-A2DP-Empfangsmodus umschalten – LEDs blinken während des Pairings blau, dann streamt dein Handy Audio über denselben Codec und die gleiche LED-Anzeige
        • Taste 3/Taste 4: Vorheriger/Nächster Titel
        • Taste 5/Taste 6: Lautstärke runter/rauf
        • Bluetooth-Gerätename: Dietmars-Soundbox (natürlich ein personalisiertes Geschenk)

          • Die LED-Show

          Hier wird es technisch interessant. Die LED-Task führt auf Core 0 eine aus 5 Ebenen zusammengesetzte Show aus:

          1. Ambient – langsames Farbwechseln basierend auf der Gesamtlautstärke
          2. Beat-Burst – Blinken bei Kick-Erkennung
          3. Bass-Blob – auf die Helligkeit abgebildete tieffrequente Energie
          4. Sparkles – zufällige hochfrequente Glitzereffekte
          5. Picture Frame – die vier Seiten des Rahmens erhalten jeweils einen eigenen Farbton, gesteuert durch die Lautstärkestufe

            6. Die Audio-Pipeline funktioniert so: PCM-Samples werden aus dem I2S-Write-Callback abgegriffen (sowohl im SD- als auch im Bluetooth-Modus), von Stereo int16 in Mono float konvertiert und in einen Stream-Puffer geschoben. Die LED-Task leert diesen Puffer, führt eine 512-Punkt-FFT mit einem Hann-Fenster durch, teilt das Ergebnis in 8 logarithmische Bänder von 60 Hz bis 20 kHz auf, wendet bandweise AGC mit einer Zeitkonstante von ~10 s an und führt die Beat-Erkennung über ein Dual-EMA-Subbass-Verhältnis durch: kick_fast / kick_slow > 1.3, mit einem Mindestabstand von 200 ms zwischen den Schlägen.

            Bei leisen Passagen atmet der Rahmen in ruhigen Farben bei geringer Sättigung. Laute und schnelle Musik löst Disco-Snaps mit voller Sättigung aus, bei denen jede Seite des Rahmens einen zufällig zugewiesenen Farbton mit einer erzwungenen Trennung von ~80–120° erhält – so kommt es nie vor, dass zwei Seiten versehentlich dieselbe Farbe haben. Lautstärkestufen (leise / mittel / laut) steuern, wie viele Rahmenseiten gleichzeitig beleuchtet werden.

            Das sorgt wirklich für die richtige Stimmung im Raum. Es war toll zu sehen, wie dieser Teil funktioniert.

            Entwicklung mit Claude Code

            Ich hatte einen Docker-Container aus einem früheren Projekt – Ubuntu-Basis, Node.js, @anthropic-ai/claude-code installiert, USB-Seriell-Passthrough über docker-compose.yml. Ich habe alle AliExpress-Datenblätter und Platinen-Schaltpläne, die ich finden konnte, in einen external-docs/ Ordner, schrieb ein grobes requirements.mdund ließ Claude loslegen.

            Die Konfiguration ist es wert, beschrieben zu werden: Das Repo enthält eine CLAUDE.md , das Claude anweist, requirements.md, alle skills/ Dateien (Arbeitskonventionen pro Thema) und alle knowledge/ Dateien (validierte Konfigurationsnotizen pro Komponente) zu Beginn jeder Sitzung zu lesen. Auf diese Weise verfügt Claude über eine kontextübergreifende Persistenz über Sitzungen hinweg, ohne auf den Konversationsverlauf angewiesen zu sein. Jedes Mal, wenn Claude eine funktionierende Konfiguration bestätigt, schreibt er eine Notiz in knowledge/ — so beginnt die nächste Sitzung mit dem, was sich bereits bewährt hat.

            Die erste Herausforderung bestand darin, überhaupt Audioausgabe zu erhalten. Der ES8388-Codec reagiert empfindlich auf die Initialisierungsreihenfolge: Die SD-Karte muss vor der I2S-Initialisierung gemountet werden (GPIO25/26-Konflikt), MCLK muss vor der Codec-Initialisierung 100 ms lang stabil sein, und du musst I2S_CLK_SRC_DEFAULT — APLL verursacht breitbandiges weißes Rauschen auf dem ESP32. Claude hat all das gemeistert, indem er es versuchte, scheiterte, den Fehler auslas und Anpassungen vornahm. Der richtige Weg war, espressif/esp_codec_dev und niemals direkt in die ES8388-Register zu schreiben.

            Es gab auch einen fiesen Bug, bei dem jeder Song mit eingebettetem Cover-Art am Anfang knisterte. Die Ursache: Der ID3v2-Tag kann ein mehrere hundert KB großes JPEG enthalten, und der Helix-MP3-Decoder durchsuchte es Byte für Byte auf der Suche nach einem Sync-Frame, wodurch der I2S-DMA-Puffer leergefegt wurde. Die Lösung bestand darin, die Syncsafe-Größe aus dem ID3v2-Header zu parsen und fseek() das gesamte Tag zu überspringen, bevor die Datei an den Decoder übergeben wurde. Claude hat das selbstständig herausgefunden, nachdem ich ihm das Knackgeräusch beschrieben hatte.

            Bluetooth benötigte eine benutzerdefinierte 3-MB-Partitionstabelle, da der BT-Stack die Binärdatei auf ~1,1 MB aufbläht. Der A2DP-Daten-Callback muss streng nicht-blockierend sein – übertrage ihn StreamBufferHandle_t, Drain in einer separaten Task auf Core 1 – sonst bricht die BT-Verbindung bei jeder Belastung ab.

            Ich bin ein passabler Programmierer. Ich hätte zwei oder drei Wochenenden gebraucht, um das alles alleine zum Laufen zu bringen. Mit Claude Code war es eins.

            Stückliste

            TeilKosten
            ESP32-Audio-Kit (A1S V2.2, ES8388)17
            WS2812B LED-Streifen (30 LEDs)4
            IKEA-Bilderrahmen5
            Sonstiges (USB-Kabel, Klebeband, Kleber)~3
            Gesamt~29

            Lautsprecher aus dem Bastelvorrat, SD-Karte aus der Schublade. Rechne noch 5 € dazu, wenn du diese Teile kaufst.

            Was kommt als Nächstes

            Die naheliegende Erweiterung ist ein kleiner 5-V-LiPo-Akku unter dem Rahmen für die kabellose Wandmontage. Der LED-Streifen benötigt ohnehin 5 V, daher ist kein Aufwärtswandler erforderlich – nur ein winziger LiPo-Akku mit einer TP4056-Ladekarte unter dem Rahmen. Und ein ordentlicher externer Netzschalter.

            Der vollständige Quellcode und das Devcontainer-Setup sind auf GitHub.

            Ein paar Erkenntnisse, die ich daraus gewonnen habe: Günstige AliExpress-Hardware ist wirklich leistungsfähig, wenn du weißt, was du kaufst. Der ES8388-Codec ist ein echter Audio-Chip – er klingt gut. Und Claude Code ist ein wirklich nützliches Tool für Embedded-Projekte, nicht nur für Web-Sachen, solange du ihm einen strukturierten Kontext gibst. Der knowledge/ Ordneransatz – bei dem sich bestätigte Hardware-Fakten über mehrere Sitzungen hinweg ansammeln – hat einen echten Unterschied gemacht. Es lohnt sich, das richtig einzurichten.

            GitHub: happychriss/ESP32-A1S-sound-machine

        • Perplexity über MCP mit WordPress verbinden

          Perplexity über MCP mit WordPress verbinden

          Heute Abend habe ich Perplexity direkt mit meiner selbst gehosteten WordPress-Seite unter 44-2.de verbunden – mithilfe des WordPress.org-MCP-Connectors über Pipedream. Die Idee: mit einer KI sprechen und am Ende einen veröffentlichten Beitrag erhalten. Kein Kopieren und Einfügen, kein Wechseln zwischen Tabs.

          So richtest du es ein

          1. Geh im WordPress-Adminbereich zu Benutzer → Neu hinzufügen. Erstelle einen Benutzer mit der Rolle „Redakteur“. Verwende nicht dein Admin-Konto.
          2. Öffne das Profil des neuen Benutzers und scrolle nach unten zu „Anwendungspasswörter“. Gib einen Namen ein (z. B. „Perplexity MCP“) und klicke auf „Neues Anwendungspasswort hinzufügen“.
          3. WordPress zeigt dir das Passwort einmalig an. Kopiere es sofort – du wirst es nicht noch einmal sehen. Der Name ist nur eine Bezeichnung; die lange generierte Zeichenfolge ist das eigentliche Passwort.
          4. Geh zur Perplexity-Add-on-Seite und verbinde die WordPress-Integration. Gib deine Website-URL (mit https://, nicht http://), den Benutzernamen und das Anwendungs-Passwort ein.
          5. Die Bestätigung „Verbindung authentifiziert“ überprüft nicht, ob deine Anmeldedaten tatsächlich funktionieren – sie überprüft lediglich, ob eine Verbindung hergestellt wurde. Der eigentliche Test findet statt, wenn du versuchst, sie zu nutzen.
          6. Drücke im Perplexity-Chat auf „+“, füge das WordPress-MCP hinzu, und schon kannst du loslegen.

          Was mir Probleme bereitet hat

          Falscher Benutzer – Ich habe mit dem Admin-Konto angefangen. Admin sollte für Admin-Dinge bleiben.

          Pipedream aktualisiert nicht automatisch – Nach dem Benutzerwechsel in WordPress verwendete Pipedream weiterhin die alten Anmeldedaten. Du musst die Verbindung manuell trennen und neu herstellen, damit die Änderungen wirksam werden.

          Die Benutzeroberfläche für das Anwendungspasswort – Ich habe den Namen kopiert statt des generierten Passworts. WordPress zeigt das eigentliche Passwort einmalig direkt neben dem Namensfeld an. Das kann man leicht übersehen, wenn man nicht danach sucht.

          Was kommt als Nächstes

          Als Nächstes steht GitHub an. Der Plan ist, dass der Projektfortschritt – Commits, Notizen, Entscheidungen – über Konversationen in Beiträge einfließt. Dieser Beitrag wurde vollständig über die MCP-Verbindung verfasst und veröffentlicht. Darum geht es.