Fehlerbehebung

Dieses Kapitel ist nach Symptomen gegliedert. Jeder Eintrag nennt die wahrscheinliche Ursache und die Schritte zur Behebung. Beginnen Sie mit Erste Anlaufstelle: Zeitleiste, Protokoll und Health-Check — fast jede Diagnose unten stützt sich auf eine dieser Quellen — und springen Sie dann zu dem Abschnitt, der zu Ihrer Beobachtung passt.

Zwei Tatsachen liegen dem Folgenden meist zugrunde. Erstens ist eine Maschine (im Einstellungseditor ein Arbeitsbereich) eine dauerhafte Sandbox: Ihre Systemfestplatte (disk.img) und ihr Linux-Home (home.img) überdauern Neustarts, ein Problem darin verschwindet also nicht durch bloßes Neustarten. Zweitens setzt Bromure Agentic Coding die Sicherheitsrichtlinien auf dem Host durch, bevor der Verkehr die VM erreicht — Blockierungen und Fehler, die „im“ Gast aufzutreten scheinen, stammen daher meist vom Host-Proxy und werden in der App gelöst, nicht in der VM.

Erste Anlaufstelle: Zeitleiste, Protokoll und Health-Check

Bevor Sie etwas ändern, finden Sie heraus, was die App selbst meldet.

Die Sicherheits-Zeitleiste

Öffnen Sie Fenster › Sicherheit… (oder suchen Sie es mit ⌘K). Es zeichnet jede Entscheidung auf, die Bromures Sicherheits-Engines für Ihre Agenten getroffen haben — Vermittlung und Nutzung von Zugangsdaten, Firewall- und OpenShell-Urteile, Verweigerungen der Gast-Sandbox, Schutzmechanismen, Lieferkettenprüfungen, Prompt-Injection-Scans, Ersetzungen personenbezogener Daten, Nachrichten der Agenten-Delegation und Upstream-TLS-Probleme. Die Aufzeichnung ist immer aktiv, übersteht Neustarts, und die Ereignisse jedes Tages werden 90 Tage lang aufbewahrt.

Das Fenster Sicherheit auf dem Tab Übersicht: Kacheln für die letzten 24 Stunden mit Blockiert, Erlaubt, Anmeldedaten-Vermittlung, Lieferkette und Schutz personenbezogener Daten, eine Tabelle mit den Schutzfunktionen jeder Maschine und eine Liste der letzten Blockierungen
  • Der Tab Übersicht fasst einen zurückliegenden Zeitraum zusammen (standardmäßig die letzten 24 Stunden) — Blockiert, Erlaubt, Anmeldedaten-Vermittlung, Lieferkette, Schutz personenbezogener Daten —, zeigt die Schutzfunktionen jeder Maschine und listet die Letzte Blockierungen. Eine Blockierung ist meist die schnellste Antwort auf „Warum ist die Anfrage des Agenten fehlgeschlagen?“; klicken Sie darauf, um jedes Vorkommen zu finden.
  • Der Tab Zeitleiste listet jedes Ereignis. Grenzen Sie ihn mit dem Feld Ereignisse filtern… (ein Paketname, ein Host, eine Maschine), den Filtern für Arbeitsbereich, Zeitraum und Engine und, wenn Sie entfernte Hosts spiegeln, dem Maschinenfilter (Alle Maschinen / Dieser Mac / ein Host) ein.
  • Auf einer Maschine mit dem Kernel-Sentry doppelklicken Sie auf eine Zeile Netzwerk, um zu sehen, welcher Prompt, welcher Tool-Aufruf und welcher Prozess die Verbindung aufgebaut haben (Netzwerk-Abstammung).
  • Exportieren… speichert die Ereignisse — mit angewendetem Filter — als CSV-Datei. Hängen Sie sie an einen Fehlerbericht an oder geben Sie sie Ihrem Sicherheitsteam.
  • Leeren blendet die Ereignisse nur im Fenster aus; die Tagesdateien auf der Festplatte bleiben erhalten.
Der Tab Zeitleiste des Fensters Sicherheit: ein Filterfeld, Filter für Arbeitsbereich, Zeitraum und Engine, die Schaltflächen Exportieren… und Leeren sowie Zeilen der Engines Schutz personenbezogener Daten, Prompt-Injection, Lieferkette, Firewall und Anmeldedaten-Vermittlung

Das Fenster ist ausführlich in Sicherheitsübersicht und Zeitleiste beschrieben.

Das App-Protokoll

Die App bewahrt eine Kopie von allem, was sie auf die Standardfehlerausgabe schreibt, in ~/Library/Logs/BromureAC/bromure-ac.log auf — ob Sie sie aus einem Terminal gestartet haben oder nicht. Jeder Lauf beginnt mit einer Zeile === … launch pid …, die Build und macOS-Version nennt, und endet mit einer Zeile exit; ein Absturz hinterlässt eine Zeile mit dem Namen des fatalen Signals. Überschreitet die Datei 8 MB, wird sie beim nächsten Start rotiert, und eine vorherige Datei wird als bromure-ac.log.1 aufbewahrt.

Hier sollten Sie nachsehen, wenn:

  • der gespeicherte Zustand einer Maschine nicht wiederhergestellt werden konnte (die Zeile nennt, was sich seit dem Anhalten geändert hat — siehe Eine angehaltene Maschine setzt nicht dort fort, wo sie aufgehört hat);
  • ein unbeaufsichtigter Start abgelehnt wurde oder eine Dateisystemreparatur lief;
  • die App unerwartet beendet wurde. Zeigt macOS keinen Absturzbericht, sind die letzten Zeilen des Protokolls die beste Aufzeichnung dessen, was passiert ist. Die eingebettete Terminal-Engine hat Absturzdetails eventuell auch in ~/Library/Caches/com.mitchellh.ghostty/sentry abgelegt.

Um das Protokoll live zu sehen oder Debug-Ausgaben hinzuzufügen, starten Sie die App aus einem Terminal:

"/Applications/Bromure Agentic Coding.app/Contents/MacOS/bromure-ac"

Für tiefergehende Details setzen Sie eine Debug-Variable vor dem Befehl (siehe Anhang):

  • BROMURE_AC_DEBUG=1 — mit Zeitstempeln versehenes Debugging für die Automatisierungs-Engine, die Injection-Klassifizierer und die Trace-Pipeline.
  • BROMURE_CLI_DEBUG=1 — Diagnose der Control-Socket-Verbindung für CLI-Befehle.
  • BROMURE_REPAIR_DEBUG=1 — Diagnose des Reparatur-Proxys der lokalen Inferenz, angehängt an /tmp/bromure-repair.log.

Der Health-Check

Während die App läuft, stellt sie unter ~/Library/Application Support/BromureAC/control.sock einen Steuer-Socket nur für den Eigentümer bereit. Fragen Sie ihren Zustand ab, um zu bestätigen, dass die App lebt und antwortet:

curl --unix-socket "$HOME/Library/Application Support/BromureAC/control.sock" http://localhost/health
{ "status": "ok", "service": "bromure-ac-automation", "debugEnabled": false }

Wenn Sie den Loopback-Automatisierungsserver eingeschaltet haben (Einstellungen › Automatisierung, standardmäßig aus), antwortet derselbe Endpunkt über TCP am konfigurierten Port — standardmäßig 9223:

curl http://127.0.0.1:9223/health

Eine abgelehnte Verbindung bedeutet, dass die App (oder ihr headless Agent) nicht läuft; bromure-cli vm ls startet den Hintergrund-Agenten bei Bedarf und ist ein weiterer schneller Lebenscheck. Wie Sie bromure-cli installieren, steht in CLI, API & MCP.

Die Installationskonsole

Während das Basis-Image installiert wird — im Schritt Installation des Einrichtungsassistenten oder nach Base-Image neu erstellen… — hat die Fortschrittsansicht einen eingeklappten Bereich Konsolenausgabe, der das rohe Installationsprotokoll streamt, mit einer Schaltfläche Kopieren. Nur die letzten 100 Zeilen bleiben auf dem Bildschirm; kopieren Sie das Protokoll also, bevor sich das Fenster schließt, wenn Sie es einem Bericht beifügen müssen.

Einrichtung und Base-Image-Installation

Keine Maschine kann laufen, solange kein Linux-Basis-Image existiert. Beim ersten Start öffnet sich der Einrichtungsassistent mit Willkommen bei Bromure; ein Klick auf Loslegen wechselt zum Schritt Installation, der dieselbe Installation wie bromure-ac init ausführt. Der vollständige Ablauf steht in Installation & erster Start; dieser Abschnitt behandelt, was zu tun ist, wenn er fehlschlägt.

Der Willkommensschritt des Einrichtungsassistenten: Willkommen bei Bromure, eine Schaltfläche Loslegen und die Schrittleiste Willkommen, Installation, Zugangsdaten, Auswahl, Modelle, Fertig

Der vorgefertigte Download schlägt fehl oder bleibt hängen

Ursache. Der bevorzugte Weg lädt ein signiertes, gzip-komprimiertes Image von https://dl.bromure.io, prüft dessen SHA-256 und entpackt es. Eine Netzwerkunterbrechung, ein CDN-Aussetzer oder eine abweichende Prüfsumme brechen ihn ab. Der Download versucht es bereits erneut und holt den Katalog zwischen den Versuchen neu (die wöchentliche Veröffentlichung kann den vorherigen Build mitten im Download ersetzen).

Behebung. Beobachten Sie Status und Konsolenausgabe. Bei einem Fehler auf der Download-Seite zeigt die App den Hinweis Image-Download fehlgeschlagen mit Lokal bauen oder Abbrechen:

  1. Wenn Sie online sind und der Fehler vorübergehend war, versuchen Sie es aus dem App-Menü erneut: Base-Image neu erstellen… → Vorgefertigtes herunterladen.
  2. Wenn der Download nicht gelingen will (restriktives Netzwerk, blockiertes CDN), wählen Sie Lokal bauen, um das Image stattdessen auf Ihrem Mac zu bauen (etwa 10 Minuten). Das Ergebnis ist dasselbe Image.
  3. Auf der Befehlszeile fällt bromure-ac init automatisch auf den lokalen Build zurück.

"Netzwerkproblem während der Base-Image-Erstellung"

Ursache. Der lokale Build bootet eine wegwerfbare Alpine-Installer-VM, die einen DHCP-Lease und ausgehenden Zugriff benötigt. In manchen VPNs und abgeschotteten Netzwerken erhält sie keinen Lease oder ihre Downloads verschwinden aufgrund einer MTU-Diskrepanz im Nichts.

Behebung. Der Build stoppt mit dem Hinweis Netzwerkproblem beim Bau des Basis-Images mit Reparieren und erneut versuchen (startet die Netzwerk-Daemons von macOS neu — fragt nach Ihrem Administratorpasswort) oder Abbrechen. Scheitert es über ein VPN weiterhin, begrenzen Sie vor dem erneuten Versuch die MTU der Netzwerkkarte des Gasts:

defaults write io.bromure.agentic-coding vm.mtu -int 1280

Die MTU ist bereits standardmäßig auf 1280 gesetzt; senken Sie sie nur dann weiter, wenn ein Firmen-PMTU-Pfad es erfordert.

Der Installation geht der Speicherplatz aus

Ursache. Jede Image-Installation verlangt vorab mindestens 8 GB freien Speicher auf dem Volume mit dem Support-Verzeichnis, und ein Monitor bricht den Build ab, wenn der freie Speicher ausgeht, damit er nicht in eine unerklärte Zeitüberschreitung läuft.

Behebung. Geben Sie Speicherplatz frei und versuchen Sie es erneut. Siehe Speicherplatz für das, was am meisten verbraucht.

Das Base-Image verbleibt in einem unvollständigen Zustand

Ursache. Ein Abbruch mitten in der Installation oder ein fehlgeschlagener Build hinterlässt temporäre Dateien: base.img.partial, base.img.gz.partial, stock.img.partial und efivars.partial im Support-Verzeichnis. Ihr Vorhandensein bedeutet, dass eine Installation läuft oder unterbrochen wurde. Das echte Image wird immer nur atomar ersetzt, sodass ein vorhandenes, funktionierendes Image die ganze Zeit nutzbar bleibt.

Behebung. Lassen Sie die Installation vollständig durchlaufen (Base-Image neu erstellen… oder bromure-ac init). Um ganz von vorn zu beginnen, löscht bromure-ac reset nach einer Bestätigung die Dateien des Basis-Images (base.img, efivars.bin, base.version, image-state.json sowie den gespeicherten Download stock.img / stock-state.json) — Ihre Maschinen berührt es nicht. Was installiert ist, prüfen Sie jederzeit mit bromure-ac info.

Ein neueres Basis-Image ist verfügbar

Zwei verschiedene Abfragen können erscheinen:

  • Update für das Basis-Image verfügbar (beim Start) — die App bringt ein neueres Basis-Image mit, als auf der Festplatte liegt, oder der Katalog veröffentlicht eines. Jetzt aktualisieren lädt es herunter (mit lokalem Neubau als Rückfall); Später fragt beim nächsten Start erneut. Das aktuelle Image funktioniert in der Zwischenzeit weiter.
  • Ein neueres Basis-Image ist verfügbar. (beim Start einer Maschine) — die Basis auf der Festplatte ist neuer als die, von der die Systemfestplatte dieser Maschine geklont wurde. Ja, aktualisieren setzt die Systemfestplatte der Maschine auf die neue Basis zurück: Alles, was in der VM mit apt installiert wurde, wird gelöscht, der Home-Ordner bleibt erhalten. Nein behält die aktuelle Basis bis zur nächsten; Später erinnern fragt beim ersten Start nach morgen erneut. Die Antwort wird pro Maschine gespeichert.

Ein Update des Basis-Images ändert nie von sich aus die Festplatte einer vorhandenen Maschine; jede Maschine wird erst aktualisiert, wenn Sie Ja, aktualisieren sagen.

Eine Maschine startet nicht, bootet nicht oder setzt nicht fort

Maschinen sind in der Seitenleiste unter Virtuelle Maschinen aufgeführt. Die Schaltfläche ⋯ in der Zeile einer Maschine bietet Starten (oder Fortsetzen, bzw. Herunterfahren / Anhalten / Neu starten, während sie läuft). Mit einer Sitzung auf der Bühne bietet das Maschinenmenü in der Symbolleiste — die Kapsel mit dem Namen der Maschine — Maschinendetails: das Dashboard mit den Karten CPU, Arbeitsspeicher, Festplatte und Betriebszeit, die Konfigurationsübersicht und die Ein-/Aus-Schaltflächen. Maschinen werden in Maschinen behandelt.

Der Start wird nie fertig („TAUCHGANG FEHLGESCHLAGEN“)

Ursache. Maschinen werden nicht vorgewärmt — sie booten kalt von ihrer Copy-on-Write-Festplatte (oder stellen einen Snapshot vom Anhalten wieder her), was einige Sekunden dauert. Antwortet nach 30 Sekunden kein Terminal, wechselt der Startbildschirm zu TAUCHGANG FEHLGESCHLAGEN: „Die VM hängt möglicherweise, oder ihre Systemfestplatte ist beschädigt.“

Behebung.

  1. Klicken Sie einmal auf Weiter warten — ein erster Start nach einem Image-Update oder ein langsamer Mac kann länger dauern.
  2. Kommt sie immer noch nicht hoch, starten Sie die Maschine über ihr Menü ⋯ neu (Neu starten).
  3. Ist eine beschädigte Datei auf der Systemfestplatte die Ursache, siehe Eine Maschine retten, die wegen einer defekten Datei nicht startet, oder klicken Sie auf Systemfestplatte zurücksetzen…, um die Systemfestplatte neu vom Basis-Image zu klonen. Ihr Home-Ordner — Projekte, Dotfiles, .ssh-Schlüssel, Shell-Verlauf — bleibt erhalten; alles, was Sie mit apt installiert haben, und Änderungen unter /etc gehen verloren.

Der Start einer Maschine bricht mit einem Festplattenfehler ab

Ursache. Die Systemfestplatte hat die Dateisystemprüfung beim Start nicht bestanden — meist, weil die VM mitten im Schreiben gestoppt wurde (erzwungenes Beenden, Absturz, Stromausfall). Der Gast kommt an dieser Stelle nicht von allein weiter.

Behebung. Die Bühne der Maschine zeigt FESTPLATTENFEHLER — „Die Systemfestplatte hat die Dateisystemprüfung beim Start nicht bestanden, der Start kann nicht fortgesetzt werden.“ — mit der Konsolenzeile, die ihn ausgelöst hat:

  1. Klicken Sie auf Festplatte reparieren. Bromure stoppt die VM, spielt das Journal der Festplatte auf dem Mac mit seinem eingebauten Prüfer ab und startet erneut. Nichts wird gelöscht.
  2. Schlägt der Start nach einer Reparatur erneut fehl, klicken Sie auf Systemfestplatte zurücksetzen… und bestätigen Sie Auf Basis zurücksetzen. Der Home-Ordner bleibt erhalten.

Auf einem Rich Client kommt dieselbe Wahl als Abfrage: „“‹machine›” can't boot — disk error“, zuerst mit Festplatte reparieren / Später und, sobald eine Reparatur versucht wurde, mit Reset System Disk / Später. Sie können die Reparatur auch selbst bei gestoppter Maschine ausführen: bromure-cli vm fsck <machine> --repair. Siehe Erweitert.

Eine angehaltene Maschine setzt nicht dort fort, wo sie aufgehört hat

Ursache. Das Fortsetzen stellt den gespeicherten Arbeitsspeicher (vm.state) auf der exakt gleichen virtuellen Hardware der Maschine wieder her. Hat sich die Konfiguration seit dem Anhalten geändert — mehr oder weniger Arbeitsspeicher, andere geteilte Ordner, ein neuer App- oder Basis-Image-Build —, lässt sich der gespeicherte Zustand nicht mehr wiederherstellen.

Was passiert. Bromure lässt die Maschine nicht hängen: Schlägt eine Wiederherstellung fehl, verwirft es den gespeicherten Zustand und startet die Maschine frisch, mit derselben Festplatte und demselben Home. Ihre Dateien sind alle da; nur die laufenden Programme und offenen Terminals der angehaltenen Sitzung gehen verloren. Das App-Protokoll hält den Grund fest und nennt, was sich geändert hat — zum Beispiel configuration changed since the suspend: memoryGB: 8 → 6 — booting fresh. Automatisierungen und Delegationen, die eine angehaltene Maschine starten, verhalten sich genauso.

Einige verwandte Fälle:

  • Geteilte Ordner während des Anhaltens geändert. Beim Sichern der Einstellungen der Maschine erscheint Angehaltene VM für „‹machine›“ verwerfen? — wählen Sie Verwerfen und sichern; der nächste Start ist ein Kaltstart. Dateien im Home und in den geteilten Ordnern sind nicht betroffen.
  • Das Zurücksetzen oder Löschen einer Festplatte verwirft immer den gespeicherten Zustand: Eine frische Festplatte mit altem Arbeitsspeicher wäre sofort beschädigt.
  • Entwickler-Builds. Ein Zustand, den ein App-Build gespeichert hat, lässt sich von einem anderen lokalen Build oft nicht wiederherstellen. Fahren Sie Maschinen herunter, statt sie anzuhalten, bevor Sie den Build wechseln.

Die Maschine ist als „Kompromittiert“ markiert

Ursache. Der Proxy hat gesehen, wie die Platzhalter-Zugangsdaten einer Maschine zu einem Host unterwegs waren, für den sie nicht ausgestellt wurden — das Kennzeichen einer Exfiltration. Die Anfrage wird blockiert, die VM pausiert, und der Hinweis Diese Umgebung könnte kompromittiert sein listet die Lecks mit vier Optionen:

SchaltflächeWas passiertMaschine als kompromittiert markiert?
Herunterfahren (Standard)Die VM wird heruntergefahren.Ja
BlockierenNur diese Anfrage wird abgelehnt; die VM läuft weiter. Versucht sie es erneut, kommt der Hinweis wieder.Nein
ErlaubenSie bürgen für das Ziel: Für den Rest dieser Sitzung werden die Zugangsdaten eingesetzt und dorthin gesendet, und spätere Anfragen dorthin werden nicht mehr markiert.Nein
Für Untersuchung speichernSie wählen einen Ordner; Bromure kopiert das Festplatten-Image und Archive des Homes und der geteilten Ordner dorthin und fährt die VM dann herunter.Ja

Auf einem Rich Client oder einem headless Mac bietet die Abfrage Herunterfahren / Blockieren / Erlauben und fällt auf Herunterfahren zurück, wenn niemand antwortet. Haben Sie im Bereich Schutzmechanismen der Maschine Nicht bei Exfiltration von Anmeldedaten warnen eingeschaltet, erscheint kein Hinweis: Das Leck wird trotzdem blockiert und in der Zeitleiste festgehalten.

Behebung. Eine als kompromittiert markierte Maschine zeigt „Kompromittiert — beim Start werden Sie aufgefordert, Disk und Home zu löschen“ und startet erst, wenn Sie die Löschung in ⛔ „‹machine›“ ist als kompromittiert markiert bestätigen. Löschen und starten entfernt Festplatte, Home und gespeicherten Zustand und startet dann eine frische VM — Ihre Zugangsdaten, SSH-Schlüssel und Maschineneinstellungen bleiben erhalten. Geteilte Projektordner liegen außerhalb von Bromures Speicher und werden nicht gelöscht; prüfen Sie sie also von Hand auf kontaminierte Dateien. Eine Automatisierung oder Delegation kann die Löschung nicht bestätigen: Ihr Start wird mit „The workspace is marked compromised — start it yourself to confirm the wipe.“ abgelehnt. Das Erkennungsmodell ist in Zugangsdaten & die Übertragungsgrenze beschrieben.

„The workspace did not boot in time“ / „did not start in time“

Ursache. Eine Sitzung, Automatisierung oder Coding-Aufgabe hat darauf gewartet, dass ihre Maschine hochfährt, und aufgegeben. Häufige Gründe:

  • Die Maschine ist tatsächlich nicht gestartet — suchen Sie auf ihrer Bühne nach TAUCHGANG FEHLGESCHLAGEN oder FESTPLATTENFEHLER (oben).
  • Ein unbeaufsichtigter Start wurde abgelehnt, weil er eine Antwort von Ihnen gebraucht hätte. Der Laufverlauf einer Automatisierung zeigt dann den Grund statt der Zeitüberschreitung: „The workspace is marked compromised — start it yourself to confirm the wipe.“ oder „“‹model›” is still downloading — the workspace can't start until it has.“
  • Der Mac war im Ruhezustand oder überlastet.

Behebung. Starten Sie die Maschine selbst über ihr Menü ⋯, beobachten Sie ihre Bühne, beantworten Sie etwaige Abfragen und wiederholen Sie dann die Sitzung oder den Lauf. Start-Abfragen (Image-Updates, neue empfohlene Pakete) erscheinen als Sheets am Hauptfenster und blockieren nie den Start von Maschinen.

Meldet eine neue Sitzung stattdessen „Der Agent hat sich nie gemeldet…“, läuft auf der Maschine womöglich ein älterer Agent in der VM: Starten Sie sie über ihr Menü ⋯ mit Neu starten neu und versuchen Sie es erneut.

Nicht genügend freier Speicherplatz

Ursache. Das Erstellen eines Copy-on-Write-Klons oder Home-Images weigert sich fortzufahren, wenn weniger als 1 GB auf dem Volume frei ist, und schlägt mit einem Disk-Full-Fehler schnell fehl, statt mitten in der Sitzung stecken zu bleiben.

Behebung. Schaffen Sie Platz (siehe Speicherplatz) und starten Sie die Maschine erneut.

Eine Maschine retten, die wegen einer defekten Datei nicht startet

Ursache. Eine in den Gast geschriebene Fehlkonfiguration — eine defekte /etc/fstab, eine beschädigte Dotfile — kann die VM am Booten hindern, bevor Sie sich zur Behebung anmelden können. Da macOS ext4 nicht mounten kann, können Sie die Platte nicht einfach im Finder öffnen.

Behebung. Verwenden Sie den eingebauten ext4-Browser, bei gestoppter Maschine:

  1. Arbeitsbereiche › ext4-Datei öffnen…, dann die disk.img oder home.img der Maschine unter ~/Library/Application Support/BromureAC/profiles/<uuid>/ wählen.
  2. Navigieren Sie zur betreffenden Datei. Klicken Sie mit der rechten Maustaste, um sie in der Vorschau anzuzeigen oder auf Ihren Mac zu Extrahieren….
  3. Um sie direkt zu reparieren, klicken Sie auf Bearbeitung aktivieren… (bearbeiten Sie nie ein Image, das eine laufende VM geöffnet hat), dann Rechtsklick → Ersetzen… mit einer korrigierten Kopie von Ihrem Mac.
  4. Meldet der Browser, dass das Journal wiederhergestellt werden muss, klicken Sie zuerst auf fsck ausführen…. Der Prüfer ist eingebaut; nichts muss installiert werden.

Liegt der Schaden im Home — ein Agent hat etwas gelöscht oder kaputt gemacht —, setzt Home zurückdrehen… im Menü ⋯ der Maschine das Home auf den Stand eines früheren Starts zurück. Siehe Erweitert.

Warnung: Ein Ersetzen an Ort und Stelle funktioniert nur, wenn die neuen Inhalte in die bereits zugewiesenen Blöcke der Datei passen — das Vergrößern einer Datei wird verweigert ("Diese Datei müsste wachsen"). Verwenden Sie es, um Konfigurationen zu korrigieren und Dateien herauszuholen, nicht um Daten hinzuzufügen.

"Disk zurücksetzen" / "Home löschen…" sind ausgegraut

Ursache. Diese destruktiven Aktionen werden abgelehnt, solange die Maschine läuft.

Behebung. Fahren Sie die Maschine zuerst herunter (der Tooltip lautet „Close the session window first.“) und versuchen Sie es dann erneut.

Kubernetes-Knoten und Registries

Cluster und Registries laufen in eigenen Maschinen, aufgeführt unter Virtuelle Maschinen › Kubernetes und Registries. Siehe Kubernetes-Cluster und Registries.

Ein Knoten oder eine Registry kommt nach dem Beenden oder Stoppen nicht zurück

Was Bromure tut. Das Beenden der App hält Cluster-Knoten und Registries an, und der nächste Start setzt sie fort; ein Snapshot, der sich nicht wiederherstellen lässt, fällt wie bei jeder Maschine auf einen frischen Start zurück. Ein ausdrückliches Stoppen fährt sie sauber herunter, mit bis zu 60 Sekunden Kulanzzeit.

Bricht der Start eines Knotens trotzdem bei einer Dateisystemprüfung ab, erkennt Bromure das an der Konsole, stoppt die VM, führt seinen eingebauten Prüfer auf den System- und Datenfestplatten des Knotens aus und — wenn das nicht reicht — lässt Linux' e2fsck von einer Wegwerf-Maschine aus darauf laufen. Es versucht den Start noch einmal; schlägt auch das fehl, zeigt der Cluster einen klaren Fehler.

Behebung. Sehen Sie im Tab Protokoll des Clusters nach, was passiert ist. Hat die automatische Reparatur aufgegeben, starten Sie den Cluster über sein Menü Cluster-Aktionen neu; als letzten Ausweg löschen Sie ihn und legen ihn neu an.

Ein Arbeitsbereich sieht einen Cluster oder eine Registry nicht

Ursache. Der Zugriff gilt pro Maschine. Eine Maschine, die nicht auf der Zugriffsliste eines Clusters oder einer Registry steht, erhält keinen ~/.kube/config-Kontext und kein $BROMURE_REGISTRY.

Behebung. Öffnen Sie den Tab Zugriff des Clusters oder der Registry (bei einem Cluster auch Cluster-Aktionen › Workspace-Zugriff…) und fügen Sie die Maschine hinzu. Der Kontext eines Clusters wird in die ~/.kube/config laufender Maschinen übertragen, sobald Sie seinen Zugriff ändern.

Anmelde- und Modellprobleme

Die Architektur hält echte Zugangsdaten aus der VM heraus: Der Gast arbeitet mit Platzhalter-Tokens („Fake“-Tokens), und der Host-Proxy setzt die echten Geheimnisse auf dem Übertragungsweg ein. Die meisten „Auth“-Symptome gehen auf diese Grenze zurück. Siehe Zugangsdaten & die Übertragungsgrenze und Modelle & Anbieter.

Der Agent — oder Sie — sieht einen gefälschten API-Schlüssel

Ursache. Das ist zu erwarten. Umgebungsvariablen wie ANTHROPIC_API_KEY, OPENAI_API_KEY, XAI_API_KEY, GH_TOKEN und die AWS-Variablen innerhalb der VM sind absichtliche Köder. Der Proxy ersetzt den echten Wert host-seitig für erlaubte Ziele, sodass ein geleakter gefälschter Wert wertlos ist.

Behebung. Nichts — versuchen Sie nicht, den Schlüssel in der VM zu „korrigieren“. Scheitern echte Anfragen beim Anbieter mit einem Authentifizierungsfehler, liegt das Problem beim echten Geheimnis auf dem Host: Geben Sie den API-Schlüssel des Anbieters erneut in Einstellungen › Modelle ein (oder im eigenen Bereich Modelle der Maschine, falls sie eigene Modelleinstellungen hat). Ein Fake-Token, der in einer Anfrage an den falschen Host auftaucht, löst die Kompromittierungserkennung aus, statt zu authentifizieren.

Ein Abonnement funktioniert nicht mehr („Anmeldung abgelaufen“)

Ursache. Abonnement-Anmeldungen (Claude, ChatGPT, Grok, Kimi) werden verschlüsselt auf dem Host gespeichert, der sie auch erneuert. Widerruft der Anbieter das Refresh-Token oder endet die Sitzung des Kontos, kann der Host kein gültiges Token mehr ausstellen, und jede Sitzung, die diese Anmeldung nutzt, schlägt fehl.

Behebung.

  1. Öffnen Sie Einstellungen… › Modelle (⌘,). Der Anbieter zeigt Anmeldung abgelaufen und „‹Anbieter› hat die gespeicherte Anmeldung abgelehnt (gespeichert ‹Datum›). Sitzungen können sie erst wieder nutzen, wenn Sie sich erneut anmelden.“
  2. Klicken Sie auf Erneut anmelden und schließen Sie die Anmeldung im Browser ab. Der Platzhalter-Schlüssel in den Maschinen ändert sich nie, sodass laufende Agenten die neue Anmeldung übernehmen.
  3. Scheitert eine Maschine weiterhin, während andere funktionieren, hat sie wahrscheinlich eine eigene Anmeldung. Eine Anmeldung, die in einer Maschine gestartet wurde, fragt Mit jedem Arbeitsbereich teilen? — Nur diesen Arbeitsbereich gibt dieser Maschine eine private Anmeldung, die die gemeinsame überdeckt. Prüfen Sie den Bereich Modelle der Maschine: Melden Sie sich dort erneut an, oder klicken Sie auf Globalen Anbieter verwenden, damit die Maschine die gemeinsame Anmeldung erbt.

In einem Chat zeigt ein Agent, der sich nicht authentifizieren kann, eine Karte: Bei ‹Agent› anmelden, mit Anmeldeseite öffnen und einem Feld Code einfügen. Die Zeile in der Seitenleiste zeigt „Anmeldung nötig“. Die Anmeldung über die Karte erfasst die Zugangsdaten auf dem Host, genau wie der Bereich Modelle.

Ein Agent braucht einen Modellanbieter

Ursache. Der gewählte Agent hat auf dieser Maschine nichts, worauf er laufen kann — keinen API-Schlüssel, keine Anmeldung, keinen eigenen Server und kein Modell auf dem Gerät. Der Chat zeigt „‹Agent› braucht einen Modellanbieter“ und „‹Agent› hat auf dieser Maschine noch keinen Modellanbieter. Fügen Sie in den Einstellungen der Maschine einen API-Schlüssel oder ein lokales Modell hinzu und starten Sie die Sitzung dann erneut.“

Behebung. Klicken Sie in der Karte auf Maschineneinstellungen… oder richten Sie in Einstellungen › Modelle einen Anbieter ein und starten Sie die Sitzung dann erneut. Auf dem Bildschirm für neue Sitzungen ist ein Agent in diesem Zustand mit „Beim Start anmelden“ oder „Beim Start einen Modellanbieter wählen“ markiert.

Ein Agent hängt auf einem Erststart-, Vertrauens- oder Anmeldebildschirm

Ursache. Coding-Agenten haben eigene Erststart-Bildschirme — Theme-Auswahl, Fragen zum Ordnervertrauen, Anmeldemenüs —, die der Chat nicht unverändert anzeigen kann. Bromure beantwortet die Einrichtungsbildschirme, bevor der Agent startet, und verwandelt den Rest in Karten im Chat:

  • eine Anmeldekarte für ein Anmeldemenü (Claudes „Not logged in“, Codex' ChatGPT-Auswahl, Groks Gerätecode, Kimis Anmeldung);
  • Diesem Ordner vertrauen und weiter, wenn der Agent darauf wartet, dass Sie dem Ordner vertrauen;
  • rote Karten, wenn der Agent sich nicht authentifizieren konnte, ein Nutzungslimit erreicht hat oder mit einem Fehler stehen geblieben ist;
  • für Oh My Pi, das keine eigene Anmeldung hat, eine Anbieterkarte, die auf die Einstellungen der Maschine verweist.

Behebung. Beantworten Sie die Karte. Wirkt der Chat weiterhin festgefahren — „Denkt nach…“, ohne dass etwas passiert —, drücken Sie Linux in der Symbolleiste (⌥⌘U), um das echte Terminal des Agenten zu sehen, erledigen Sie, was dort angezeigt wird, und drücken Sie Sitzung, um zurückzukehren. „Wechseln Sie ins Terminal, um es zu lösen, und senden Sie dann erneut.“ auf einer Karte bedeutet dasselbe.

Für Kimi Code meldet sich Bromure beim internationalen Dienst von Kimi (kimi.ai) an. Eine Kimi-Anmeldung von vor dieser Änderung funktioniert möglicherweise nicht mehr und zeigt eine Anmeldekarte; melden Sie sich erneut an.

"Abonnement-Token austauschen?" erscheint immer wieder oder wurde versehentlich abgelehnt

Ursache. Meldet sich ein Agent in der VM mit einem echten Token an, erkennt der Proxy das und bietet an, es auf den Host zu verlagern, damit das echte Geheimnis den Gast verlässt. Die Wahl wird pro Maschine und pro Anbieter gespeichert.

Behebung. Im Bereich Tracing der Maschine zeigen die Zeilen Claude-Abonnement-Token-Austausch und Codex-Abonnement-Token-Austausch den aktuellen Zustand mit einem Zurücksetzen-Steuerelement — Austausch vergessen (in der nächsten Sitzung erneut fragen) oder Aufforderung wieder aktivieren.

Netzwerk in der VM

IPv6 funktioniert im Gast nicht

Ursache. Das ist so gewollt. Bromures Host-Netzwerkpfad ist reines IPv4, und ein LAN, das IPv6 ankündigt, ohne funktionierenden IPv6-Ausgang zu haben, lässt jede AAAA-Abfrage hängen. Aktuelle Basis-Images schalten IPv6 im Gast ab, und apt wird bei jedem Start auf IPv4 gezwungen.

Behebung. Verwenden Sie IPv4-Adressen und Hostnamen. localhost löst im Gast nur zu 127.0.0.1 auf.

Das Subnetz der Maschinen kollidiert mit einem Netzwerk, das Sie nutzen

Ursache. Neue Installationen legen ihre Maschinen in ein zufälliges privates /24 innerhalb von 172.16.0.0/12 (unter Auslassung von Dockers üblichem 172.17–172.20 und jedes Bereichs, in dem sich der Mac bereits befindet). Ältere Installationen verwenden womöglich noch 192.168.64.0/24. Beides kann mit einem VPN oder Büronetz kollidieren.

Behebung. Öffnen Sie Einstellungen… › Ressourcen. Unter Arbeitsbereich-Subnetz wechselt Privates Subnetz verwenden (vermeidet Konflikte zwischen Remotes) auf ein zufälliges 172.16/12-Subnetz, und Zufällig wählen wählt ein neues. Änderungen gelten ab dem nächsten Start Ihrer Maschinen.

Der Verkehr einer Maschine scheitert über ein VPN

Ursache. VPN-Tunnel verkleinern die nutzbare Paketgröße; eine zu große MTU lässt Downloads im Nichts verschwinden.

Behebung. Die Netzwerkkarte des Gasts ist bereits auf 1280 Byte begrenzt. Braucht ein Firmenpfad weniger, senken Sie vm.mtu wie in Netzwerkproblem während der Base-Image-Erstellung gezeigt.

TLS- und Zertifikatfehler innerhalb der VM

"self-signed certificate" oder "unable to get local issuer certificate"

Ursache. Sämtliches HTTPS des Gasts wird vom Host-MITM-Proxy abgefangen, der den Datenverkehr mit einer Root-CA pro Installation neu signiert. Werkzeuge innerhalb der VM vertrauen ihr über die CA-Bundle-Umgebungsvariablen, die Bromure für node, python, go, rust, curl, deno und das AWS SDK setzt, sowie über die in die Meta-Freigabe eingespielte CA-Datei (bromure-ca.pem). Ein Werkzeug, das diese Variablen ignoriert — oder ein Container, der seinen eigenen Trust Store mitbringt — wird das Zertifikat des Proxys ablehnen.

Behebung.

  1. Für die meisten Werkzeuge ist nichts zu tun. Scheitert ein bestimmtes Werkzeug, verweisen Sie es auf das exportierte CA-Bundle, statt die Prüfung abzuschalten; die CA-Datei ist im Gast verfügbar, und die üblichen Variablen wie *_CA_BUNDLE / SSL_CERT_FILE sind bereits exportiert.
  2. Für einen Docker-Container, der ins Netzwerk muss, verwenden Sie den Schalter HTTP-Proxy-Einstellungen übernehmen im Sheet Neuen Container ausführen, damit http_proxy/https_proxy (der Proxy im Gast unter 127.0.0.1:65534) weitergegeben werden, und binden oder installieren Sie die CA dort, wo die Werkzeuge des Containers sie suchen.
  3. Treten Zertifikatsfehler erst auf, nachdem Sie die CA gelöscht oder rotiert haben (unten), starten Sie die betroffenen Maschinen neu, damit die neue CA bereitgestellt wird.

Für einen Host, der sein Zertifikat pinnt, kann der Bereich Schutzmechanismen der Maschine das Abfangen für eine einzelne Anfrage umgehen (X-bromure-insecure) — siehe Einstellungen der Schutzmechanismen.

Rotieren der Root-CA

Ursache / wann durchzuführen. Der private Schlüssel der Root-CA liegt unter ~/Library/Application Support/BromureAC/ca/key.pem (Modus 0600) mit seinem Zertifikat in cert.pem. Sie sollten sie rotieren, wenn Sie vermuten, dass der Schlüssel offengelegt wurde.

Behebung. Beenden Sie die App, löschen Sie das Verzeichnis ca/ und starten Sie neu — eine frische CA wird erzeugt und beim nächsten Start der Maschinen dort bereitgestellt. Bereits erfasste Trace-Inhalte sind nicht betroffen, aber jeder Gast, der das alte Zertifikat gepinnt hat, muss dem neuen vertrauen.

Lieferketten-Blockaden

Wenn npm install, pip install oder Ähnliches bei einem Agenten mit einem charakteristischen Fehler scheitert, hat höchstwahrscheinlich die Lieferketten-Pipeline des Hosts eingegriffen. Die Richtlinie und ihre Ebenen sind in Lieferketten-Schutz und in der Referenz Lieferketten-Einstellungen dokumentiert.

Eine Installation ist mit HTTP 451 fehlgeschlagen

Ursache. Ein 451 ("Unavailable For Legal Reasons") ist Bromures Lieferketten-Blockade — so gewählt, dass sie auf einen Blick vom 403 unterscheidbar ist, das Schutzmechanismen verwendet. Der Paketmanager gibt den Grund wortwörtlich in seiner Fehlerausgabe aus, zum Beispiel:

Bromure Supply-Chain Security blocked this request: npm package [email protected]
published 4 hours ago — policy requires 2 days minimum

Behebung. Lesen Sie den Grund. Die häufigen Auslöser und ihre Abhilfen:

Grund in der MeldungSchichtWie fortzufahren ist
„published … ago — policy requires N days“AltersschrankePinnen Sie eine ältere Version oder fügen Sie das Paket im Bereich Lieferkette der Maschine zu Ausgenommene Pakete hinzu.
Ein CVE / Advisory auf oder über Ihrer SchwelleOSV oder socket.devWählen Sie eine gepatchte Version oder erhöhen Sie die Schwelle Blockieren ab Schweregrad.
Als kompromittiert / Malware / Typosquat markiertsocket.devBehandeln Sie es als echtes Signal — überprüfen Sie den Paketnamen, bevor Sie es überschreiben.

Den Grund in der Zeitleiste finden

Öffnen Sie die Sicherheits-Zeitleiste, wählen Sie die Engine Lieferkette und führen Sie die Installation erneut aus. Jedes geprüfte Paket erscheint als Zeile: grün, wenn es durchkam, rot, wenn es blockiert oder entfernt wurde. Eine stille Zeitleiste während einer Installation bedeutet meist, dass alles aus dem Cache kam — die Kachel Geprüfte Pakete auf dem Tab Übersicht zeigt, dass Prüfungen stattfinden.

Eine Blockade überschreiben

Behebung. Lieferketten-Ebenen sind Ein/Aus-Schalter pro Maschine, die sofort wirken (kein VM-Neustart nötig). Um ein bestimmtes Paket durchzulassen, fügen Sie im Bereich Lieferkette eine Ausnahme oder einen Eintrag in der Zulassungsliste hinzu, oder senken bzw. deaktivieren Sie die betreffende Ebene für diese Maschine.

Jede Installation fragt nach Zustimmung (offline oder socket.dev + Cargo)

Ursache. Wenn OSV oder socket.dev aktiviert ist, aber kein Urteil liefern kann — das Netzwerk ist ausgefallen oder das Ökosystem wird nicht unterstützt — verhält sich Bromure fail-closed und hält jedes Paket für Ihre Zustimmung zurück, statt es stillschweigend zuzulassen. Zwei Situationen erzeugen eine Aufforderung pro Paket:

  • Offline arbeiten mit aktiviertem OSV oder socket.dev: Jedes nicht zwischengespeicherte Paket wird zurückgehalten.
  • socket.dev mit Cargo: socket.dev hat keine Cargo-Unterstützung, sodass jedes crates.io-Artefakt kein Urteil ergibt.

Behebung. Für Offline-Phasen deaktivieren Sie OSV und socket.dev — das Alters-Gate arbeitet aus bereits zwischengespeicherten Metadaten ohne Konnektivität weiter. Für umfangreiche Rust-Arbeit schalten Sie entweder socket.dev aus oder beantworten Sie die Aufforderungen (Gewährungen sind pro package@version verschlüsselt). Der Backstop zur PyPI-Veröffentlichungszeit ist die einzige Prüfung, die bei einem reinen Netzwerkfehler fail-open ist.

Falschmeldungen bei Prompt-Injection

Der Prompt-Injection-Detektor prüft Inhalte, die an den Agenten zurückgehen, und kann protokollieren, nachfragen oder blockieren. Sein Verhalten und seine Feinabstimmung stehen in Prompt-Injection-Erkennung & Schutzmechanismen und in der Referenz Prompt-Injection-Einstellungen.

Eine legitime Anfrage wurde markiert oder blockiert

Ursache. Der Klassifikator hat einem eingehenden Abschnitt eine Bewertung über dem Schwellenwert der Maschine gegeben — Sicherheitsdokumentation, eine Seite, die einen Angriff zitiert, oder ein Schnipsel, der wie eine Anweisung an den Agenten klingt, können alle nach Injection aussehen.

Behebung.

  1. Prüfen Sie die Zeilen Prompt-Injection in der Zeitleiste, um zu beurteilen, ob es ein echter Versuch war.
  2. War es ein Fehlalarm und stören die Blockierungen, stellen Sie den Prompt-Injection-Modus der Maschine im Bereich Prompt-Injection von Blockieren auf Nachfragen (Sie entscheiden bei jeder Erkennung) oder Protokollieren (nur aufzeichnen, nie blockieren) um.
  3. Die Einstellungen gelten pro Maschine, sodass eine lärmige Recherche-Maschine im Modus Protokollieren laufen kann, während eine Produktionsmaschine auf Blockieren bleibt.

Auch Nachrichten zwischen Agenten werden geprüft: Eine markierte Delegations-Nachricht zeigt „zurückgehalten – Prompt-Injection“ und wird unter Agenten-Delegation festgehalten.

Ereignisgesteuerte Automatisierungen sind alle blockiert

Ursache. Ereignisgesteuerte Automatisierungen erfordern das PromptGuard-Modell. Ohne es wird jeder Ereignis-Lauf blockiert mit "PromptGuard model not installed — event triggers require it (download in Settings)." Das ist beabsichtigt, kein Fehler.

Behebung. Installieren Sie das PromptGuard-Modell über den Bereich Prompt-Injection. Ist ein Detektor-Schalter an, das Modell aber nicht heruntergeladen — etwa weil die Festplatte voll war —, läuft die Maschine ungeschützt, und der Fehler wird protokolliert; laden Sie es erneut herunter, sobald wieder Platz ist.

Speicherplatz: wohin er geht und wie man ihn zurückgewinnt

Was Speicherplatz verbraucht

Der Speicher liegt unter ~/Library/Application Support/BromureAC/ (die vollständige Übersicht steht im Anhang). Die großen Verbraucher:

WasWoTypische Größe
Das Ubuntu-Basis-Imagebase.img24 GB logisch, einige GB physisch
Systemfestplatten pro Maschineprofiles/<uuid>/disk.imgCopy-on-Write-Klon der Basis; wächst nur, wenn der Gast schreibt
Homes pro Maschineprofiles/<uuid>/home.imgSparse-ext4, standardmäßig 16 GB scheinbar, bei Bedarf belegt
RAM-Snapshots angehaltener VMsprofiles/<uuid>/vm.stateBis zum zugewiesenen RAM der Maschine, pro angehaltener Maschine
Checkpoints von Festplatte und Homeprofiles/<uuid>/checkpoints/Echter Platz erst, wenn sie von den aktiven Festplatten abweichen
Kubernetes-Knoten, Registries, Messaging-Konnektorkube/<id>/nodes/<uuid>/Je eine Systemfestplatte, plus eine Datenfestplatte pro Knoten mit Longhorn (standardmäßig 40 GB scheinbar) oder der Image-Speicher der Registry
Modelle auf dem Gerätmodels/<org>--<name>/Mehrere GB pro Modell
DetektormodelleModels/prompt-injection/, Models/claudemd-guard/Jeweils Hunderte MB
Trace-Bodystraces/Begrenzt: 100 MB pro Sitzung, 5 GB insgesamt
Kopien der Unterhaltungentranscripts/, task-transcripts/, runs/Wächst mit Ihren Sitzungen, Aufgaben und Automatisierungsläufen
Datensätze zu Sitzungen, Räumen und Delegationensessions.json, rooms.json, delegations.jsonKlein
Sicherheits-Zeitleistesecurity-timeline/<date>.jsonlKlein; standardmäßig 90 Tage aufbewahrt (Einstellungen › Aufzeichnung › Security history)
App-Protokoll~/Library/Logs/BromureAC/Höchstens etwa 16 MB (8 MB plus eine rotierte Datei)

Hinweis: Die Disk-Karte des Dashboards bevorzugt die eigenen df-Zahlen des Gasts gegenüber der Zuweisung des Host-Klons, weil ein Copy-on-Write-Klon die Nutzung überzeichnet — im Gast freigegebene Blöcke bleiben im Klon materialisiert.

Speicherplatz zurückgewinnen

  • Fahren Sie angehaltene Maschinen herunter, die Sie nicht nutzen. Ein vollständiges Herunterfahren löscht vm.state; die Maschine bootet beim nächsten Mal kalt.
  • Entfernen Sie Modelle auf dem Gerät, die Sie nicht mehr nutzen, über Einstellungen › Modelle oder mit bromure-cli model rm <id>.
  • Setzen Sie eine aufgeblähte Systemfestplatte zurück mit Datenträger zurücksetzen im Menü ⋯ der Maschine (klont neu von der Basis, behält das Home).
  • Löschen Sie Traces mit bromure-cli trace clear — wischt sowohl den Ring im Arbeitsspeicher als auch die Bodys auf der Platte.
  • Löschen Sie Sitzungen, die Sie nicht mehr brauchen (Sitzung löschen im Zeilenmenü), und löschen Sie Unterhaltungen, deren Maschine oder Ordner verschwunden ist, über die Aufräumzeile in der Seitenleiste.
  • Löschen Sie eine ganze Maschine, die Sie nicht mehr brauchen (⋯ › Arbeitsbereich löschen oder bromure-cli workspaces rm <workspace>); das entfernt ihre Festplatte und ihr Home.
  • Löschen Sie ungenutzte Cluster und Registries über ihre Dashboards.
  • Gewinnen Sie das Basis-Image zurück mit bromure-ac reset, wenn Sie neu beginnen möchten (Maschinen bleiben unberührt; führen Sie danach erneut init aus).

Fernzugriff und der Rich Client

Die optionale SSH-Eingangstür für den Fernzugriff und der Rich-Client-Spiegel werden in Fernzugriff & Clients behandelt. Die Symptome unten sind diejenigen, die eine Verbindung verhindern.

Verbindung über SSH (Port 2222) nicht möglich

Ursache. Die entfernte Eingangstür ist standardmäßig deaktiviert. Sie ist außerdem ein eingebetteter Server (nicht das sshd des Systems), daher hat das Aktivieren der entfernten Anmeldung von macOS keinen Einfluss auf sie, und sie ist während jeder Installation des Basis-Images pausiert.

Behebung.

  1. Prüfen Sie den Zustand mit bromure-cli remote status — es zeigt, ob der Server aktiviert ist und läuft, Bind-Adresse und Port, die Authentifizierungsmethoden, den Fingerabdruck des Hostschlüssels, eine fertige Verbindungszeile ssh -p <port> <user>@<host> und die Liste der autorisierten Schlüssel.
  2. Aktivieren Sie ihn mit bromure-cli remote enable (Standardwerte: Port 2222, Bind 0.0.0.0, beide Auth-Methoden an). Es meldet einen Fehler, wenn beide Auth-Methoden deaktiviert sind, wenn der Port unter 1024 liegt oder während das Base-Image fehlt oder installiert wird.
  3. Fügen Sie Ihren öffentlichen Schlüssel mit bromure-cli remote key add <path-or-key> hinzu. Das Hinzufügen oder Entfernen eines Schlüssels startet den Listener neu und trennt aktive Verbindungen — erwartetes Verhalten.

Diskrepanz beim Host-Schlüssel oder Fingerabdruck (TOFU)

Ursache. Der Rich Client pinnt den Hostschlüssel jedes Remotes bei der ersten Verbindung (Trust on First Use), gespeichert in ~/Library/Application Support/BromureAC/remote-client/known_hosts. Das Pinning gilt pro Endpunkt (address:port), daher löst das Ändern von Adresse oder Port eines gespeicherten Hosts zu Recht die Vertrauensabfrage erneut aus. Eine Abweichung bei unverändertem Endpunkt bedeutet, dass sich der Schlüssel des Remotes geändert hat — oder dass etwas die Verbindung abfängt.

Behebung. Wenn Sie den Remote rechtmäßig neu erstellt haben, entfernen Sie seinen Pin und verbinden Sie sich erneut, um ihm erneut zu vertrauen. Wenn Sie die Schlüsseländerung nicht erwartet haben, halten Sie inne und untersuchen Sie, bevor Sie sie akzeptieren.

Die Remote-Einstellungen laden nicht

Ursache. Ist ein Spiegelungsfenster geöffnet, können die Einstellungen… die Einstellungen eines entfernten Hosts bearbeiten (die Auswahl Einstellungen für:). Beim Abrufen zeigen sie „Einstellungen werden von ‹Host› geladen …“ und „Die Einstellungen des Remote-Servers konnten nicht geladen werden“, wenn die Verbindung abbricht oder das Remote eine ältere Version hat.

Behebung. Prüfen Sie, ob das Spiegelungsfenster verbunden ist, und klicken Sie dann auf Erneut versuchen. Wählen Sie in Einstellungen für: Dieser Mac, um in der Zwischenzeit Ihre eigenen Einstellungen zu bearbeiten.

Der systemweite Tunnel benötigt eine Genehmigung

Ursache. Der optionale systemweite Tunnel des Rich Clients verwendet einen privilegierten launchd-Daemon, der über SMAppService registriert ist. Seine erste Registrierung bringt einen Umschalter zur Genehmigung von Hintergrundobjekten zum Vorschein.

Behebung. Genehmigen Sie Bromure Agentic Coding unter Systemeinstellungen › Allgemein › Anmeldeobjekte & Erweiterungen (die App kann diesen Bereich für Sie öffnen). Durch den Tunnel wird ein ICMP-Ping an einen entfernten Gast lokal beantwortet und bestätigt das Routing, nicht, dass der Gast lebt.

Einen Fehler melden

Wenn Sie einen Bericht auf bromure.io einreichen, fügen Sie genug bei, damit ein Maintainer ihn reproduzieren kann:

  1. App- und Image-Versionen — die App-Version (aus About Bromure Agentic Coding) und die Ausgabe von bromure-ac info (der Versionsstempel des Basis-Images, Größen und Pfad).
  2. Das App-Protokoll — ~/Library/Logs/BromureAC/bromure-ac.log (und bromure-ac.log.1, falls das Problem vor dem letzten Start begann). Starten Sie mit BROMURE_AC_DEBUG=1 aus einem Terminal neu, wenn der Maintainer mehr Details anfordert.
  3. Die relevante Aufzeichnung — bei Einrichtungsfehlern die kopierte Konsolenausgabe; bei sicherheitsbezogenem Verhalten ein gefilterter CSV-Export… aus der Sicherheits-Zeitleiste.
  4. Was Sie erwartet haben im Vergleich zu dem, was passiert ist, und ob die Maschine aus, angehalten oder in Betrieb war.

Fügen Sie keine echten Geheimnisse bei — Trace-Einträge und Protokollzeilen kürzen sie bereits auf kurze Vorschauen, und die App ist so gebaut, dass echte Zugangsdaten gar nicht erst in eine VM gelangen. Ist Ihr Mac bei einem bromure.io-Workspace registriert, leiten Sie Berichte über den Administrator Ihrer Organisation. Die Registrierung wird in Enterprise behandelt.