Ich bin verwundert dass du den Sicherheitsaspekt von Claude.md völlig falsch darstellst dass diese nur lokal liegt.
Da du KI mehr vertraust habe ich mir mal herausgenommen Claude zu fragen:
Du meinst vermutlich die Claude.md – eine Konfigurationsdatei, die in Claude Code verwendet wird. Hier eine Übersicht:
Was ist die CLAUDE.md?
Die CLAUDE.md ist eine Markdown-Datei, die Claude Code beim Start eines Projekts automatisch einliest. Sie enthält projektspezifische Anweisungen, Kontext oder Regeln – z. B. Coding-Conventions, Architektur-Hinweise oder Befehle, die Claude kennen soll.
Sie kann an mehreren Orten liegen:
∙ Projektverzeichnis (./CLAUDE.md) – gilt für das aktuelle Projekt
∙ Home-Verzeichnis (~/.claude/CLAUDE.md) – gilt global für alle Projekte
Bleibt sie lokal oder wird sie gesendet?
Der Inhalt der CLAUDE.md wird als Teil des Kontextfensters an den Anthropic-Server gesendet, sobald du eine Anfrage in Claude Code machst. Sie ist kein lokales Geheimnis – sie wird wie jede andere Eingabe behandelt und über die API übertragen.
Das gilt für alles, was Claude Code einliest: Dateien, Code-Schnipsel, und eben auch die CLAUDE.md.
Ist es sicher, Passwörter dort zu speichern?
Nein – das ist keine gute Idee, aus mehreren Gründen:
Übertragung an Server: Wie oben erklärt, wird der Inhalt an Anthropic gesendet. Passwörter landen damit im API-Request.
Kein Schutz vor Git: Wenn die CLAUDE.md im Projektverzeichnis liegt, landet sie leicht versehentlich in einem Git-Repo – auch in öffentlichen.
Kein Secrets-Management: Die Datei hat keinerlei Verschlüsselung oder Zugriffskontrolle.
Bessere Alternativen für Secrets:
∙ Umgebungsvariablen (.env-Datei, die in .gitignore steht)
∙ macOS Keychain (direkt aus Swift über Security.framework zugänglich)
∙ 1Password CLI / Bitwarden CLI für automatisiertes Auslesen
∙ Secret-Management-Tools wie direnv oder Vault
Kurz gesagt: CLAUDE.md ist für Projektkontext gedacht, nicht für Geheimnisse. Passwörter dort abzulegen wäre ein Sicherheitsrisiko.
Muss ich wiedersprechen… das mag alles richtig sein, aber je nachdem mit welchem Bias du an die Sache ran gehst, übernimmt die KI den und macht ein riesiges Drama draus…
aber ja.. natürlich landen die Daten auf dem Server.
Jetzt klopfen sich wieder 3 auf die Schulter und laden ihre wichtigsten Dokumente bei google als backup hoch.. inklusive gesamten Telefoninhalt..
Dass diese Daten von der US Regierung ungefragt und unbemerkt abgesaugt werden und in Palantir gespeist….. darüber mach ich mir Sorgen.. nicht ob Claude weiß wie oft ich am Tag Stuhlgang habe. Die Credentials kann man wieder ändern wenn man dabei Bauchschmerzen hat
Wir müssen dieses Problem generell angehen.
Ich baue mein Setup gerade stark mit Cloud LLMs aus.
Ab April stehen wahrscheinlich rund 100GB für KI Modelle lokal zur Verfügung, dann sieht die Sache ganz anders aus.
Ich bin absolut für mehr Open Source, weniger US Big Tech!
Aber dann bitte überall…
Lieber @Bomba5000 et al,
Für mich wäre das ideale Szenario eine Art ‘Read-Only’-Zugriff. Stellt euch vor, Claude (um den geht es ja hier) hätte vollen Einblick in alle Automatisierungen, Configs, Dashboards und Logs – aber eben nur lesend. Ich stelle meine Frage und die KI führt mich Schritt für Schritt zur Lösung, basierend auf dem, was sie im System sieht.
Einem nicht-deterministischen System direkt vollen SSH-Zugriff zu gewähren, fühlt sich für mich ein bisschen so an, als würde man einem Teenager die Schlüssel zum Ferrari schenken – kann gut gehen, muss es aber nicht.
Aber so ein reiner ‘Daten-Lese-Zugriff’, den Claude als Wissensbasis nutzen könnte, existiert aktuell noch nicht… oder habe ich da was übersehen?
Ich habe Claude nach einer Lösung gefragt und Claude schlug vor, einen read-only SSH zugang für “Cloude Code” einzurichten LOL…
ja so funktioniert das.. oder, du loggst dich selbst mit ssh ein, ziehst die yaml files mit denen du dich wohl fühlst und gibst Claude nur auf diesen Ordner Zugriff. Bzw das ist automatisch schon so, wenn du ihn aus diesem Ordner startest.
Dann setz dich an den PC mit bestmöglich 2 Monitoren und gib ihm die fehlenden Infos die er nicht sieht, zB welche Entitäten von einem Gerät zur Verfügung gesellt werden.
Es gibt viele Wege KI sicher mit HAOS zu nutzen.
Das ist einer mit der meisten Kontrolle.
Zusätzlich hat er einen Planmdous.
Ja, das Thema KI verfolgt mich auch schon eine ganze Weile (beruflich zwischen Fotografie und Software-Entwicklung unterwegs ).
Das Problem ist ja meistens: Man kann sich bei der KI eigentlich nur bei einer Sache sicher sein – nämlich dass sie im Hintergrund Dinge ‘optimiert’, von denen man selbst noch gar nicht wusste, dass sie existieren (oder kaputtgehen können).
Ich bin daher jetzt einen etwas anderen Weg gegangen: Ich nutze die Claude ‘Projekte’, eine Funktion die ich als neu für mich entdeckt habe (ist scheinbar neu).
Per Studio Code Server habe ich den kompletten YAML-Stack und einen sauberen JSON-Export meiner Entitäten (nach Raum/Funktion sortiert) dort als Wissensbasis hinterlegt. Claude ‘kennt’ meine Bude jetzt also in- und auswendig.
Ist extrem entspannt, um bspw. mit seiner hoffentlich wirklichen Hilfe die ellenlange automations.yaml mal in Ruhe auf das 2026.4.x Update zu prüfen und ggf. vorzubereiten, ohne dass die KI blind rät. Bisher gefällt mir das Setup richtig gut! "
Versehen mit ein paar “Regeln” in Form von “Präferenzen” fühlt es sich recht produktiv an.
Die Projekte, die @lemonbiter erwähnte, findest du auch in der Weboberfläche.
Wenn mittels ClaudeCode auf der Festplatte dann den /init Befehl ausführen, dann schreibt er sich selbst eine Anweisungsdatei.
zB “/init mit folgenden Regeln: Ausschließlich in diesem Verzeichnis bewegen, keine SSH-Keys oder secret-files lesen, Syntax nach YAML syntax - Home Assistant anwenden”
außerdem könnt ihr ihn fragen was sicher ist und was nicht. Er ist kein Mensch der sich denken könnte “Haha, dem erzähl’ ich jetzt scheiß”
Er erzählt euch das nach bestem Wissen und Gewissen.
Wenn es dann um die letzten technischen Details geht, empfehle ich eine DeepResearch mit ChatGPT oder alternativ auch sehr gut Perplexity durchzuführen. Claude schreit euch den exakten Prompt dafür.
Wer sich an ein spezielles Projekt heranwagt führt erst eine Research zu best practices zu dem Thema in der entsprechenden Konfiguration durch und gibt dieses Ergebnis dann wieder zurück an Claude der sich daraufhin seine eigenen Regeln schreibt, an die er sich halten muss.
zB keine Credentials in normalen YAML-files etc.
Könnte mir als Aufgabe das Sortieren und Umbenennen der Entitäten vorstellen… Ist bei nem gewachsenen Anfängersystem an dem viel getestet wurde keine schöne Aufgabe. Schieb ich schon bestimmt einen Monat vor mir her…
Hab mir jetzt über Ostern ein “Experimentier-System” aufgesetzt, ebenfalls auf einem PI5. Quasi 1:1 wie mein Hauptsystem, aber mit nur einer Auswahl an Geräten.
Da ich nicht zwingend VS Code nutzen möchte, sondern eher VS Codium - hast du da ggf. auch einen Überblick zur Einbindung von Claude?
Hi, das hört sich toll an mit dem Experimentier-System auf dem Pi5! Codium kenne ich selber nicht, aber soweit ich weiß ist das ein Fork von VS Code und sollte ähnlich funktionieren. Die Claude Code Extension gibts glaube ich offiziell nur für VS Code, aber es gibt wohl auch Community-Varianten für Codium — müsstest du mal schauen ob die Extension kompatibel ist.
Zum Modell/Abo: Claude Code ist mit dem Pro-Abo verfügbar (20$/Monat), da hast du Claude Sonnet mit einem gewissen Kontingent. Für intensivere Nutzung gibts noch das Max-Abo (100$/200$ je nach Tier) mit mehr Tokens und Zugang zu Opus. Ich würde erstmal mit Pro starten und schauen ob dir das reicht — für die meisten HA-Projekte sollte das locker reichen.
Mein Setup spart mir echt unglaublich viel Zeit, besonders bei den ganzen YAML-Configs und Automationen. Kann ich nur empfehlen!
Verstehe die Bedenken total — klingt erstmal gruselig einem AI-System SSH-Zugriff zu geben. Aber in der Praxis ist es weniger wild als man denkt:
Claude Code hat ein eingebautes Permission-System. Jeder Befehl den Claude ausführen will wird dir vorher angezeigt und du musst ihn explizit bestätigen. Du siehst also genau was passiert bevor es passiert — kein blindes “mach mal”. Eher wie ein sehr guter Assistent der dir sagt “ich würde jetzt X machen, ok?” und du sagst ja oder nein.
Und wenns doch mal schief geht: alles liegt bei mir im Git (lokal), also kann ich jederzeit zurückrollen. Hat mich auch schon gerettet
Aber deine Idee mit Read-Only ist trotzdem valide. Man könnte z.B.:
Einen SSH-User ohne Schreibrechte anlegen (geht tatsächlich, ist nicht so absurd wie Claude es vorgeschlagen hat lol)
Oder Claude nur die HA REST API zum Lesen geben — dann sieht er States, Configs, Logs, aber kann nichts ändern
Für mich persönlich überwiegt der Vorteil vom vollen Zugriff — wenn Claude direkt Configs editieren und HA neustarten kann spart das enorm Zeit. Aber jeder hat da ne andere Schmerzgrenze und das ist auch völlig ok.
Ich hab es aktuell via VS-Code mit Github Copilot umgesetzt. Anbindung via REST-API Extension in VS-Code RickyKleinhempel/homeassistantMcp_vsc_extension
Vorteil ist, man kann verschiedene Modelle nutzen. Habe im Prompt auch den Hinweis, umsetzen nur mit manueller Bestätigung von mir. Dann sollte da auch erstmal nix passieren.