Fehlerbehebung
Dieses Kapitel ist nach Symptomen gegliedert. Jeder Eintrag nennt die wahrscheinliche Ursache und die Schritte zur Behebung. Beginnen Sie mit Erste Anlaufstelle: Logs, Zustand und App-Status — nahezu jede Diagnose weiter unten stützt sich auf eine dieser drei Quellen — und springen Sie dann zu dem Abschnitt, der zu Ihrem Beobachtungsbild passt.
Zwei Tatsachen liegen dem meisten von dem, was folgt, zugrunde. Erstens ist ein Arbeitsbereich eine persistente Sandbox: seine Systemplatte (disk.img) und das Linux-Home (home.img) überdauern Neustarts, sodass sich ein Problem in einem von beiden nicht dadurch beheben lässt, dass man einfach neu startet. Zweitens erzwingt Bromure Agentic Coding die Sicherheitsrichtlinie auf dem Host, bevor der Datenverkehr die VM erreicht — Blockaden und Fehler, die scheinbar "innerhalb" des Gasts auftreten, sind also normalerweise der Host-Proxy, der spricht, und werden in der App gelöst, nicht in der VM.
Erste Anlaufstelle: Logs, Zustand und App-Status
Bevor Sie etwas ändern, finden Sie heraus, was die App selbst meldet.
Das Sicherheitsprotokoll
Öffnen Sie Fenster → Sicherheitsprotokoll…. Dies ist ein Live-Tail jedes Sicherheitsereignisses, das der Host-Proxy ausgibt: Lieferketten-Abfragen und 451-Blockaden, das Entfernen von Installationsskripten, Prompt-Injection-Erkennungen, Vertauschen von Zugangsdaten und Leck-Warnungen, Fusion- und Routing-Änderungen sowie Fernzugriffs-Ereignisse. Nutzen Sie das Feld Filter…, um auf einen Paketnamen, Host oder Arbeitsbereich einzugrenzen, und deaktivieren Sie Automatisch scrollen, um Ihre Position beim Lesen zu halten.
Hinweis: Das Sicherheitsprotokoll ist ein Ringpuffer im Arbeitsspeicher von etwa 5.000 Zeilen und bleibt über App-Neustarts hinweg nicht erhalten. Wenn Sie eine dauerhafte Kopie benötigen — oder etwas verfolgen, das die App zum Absturz bringt — starten Sie
bromure-cliaus einem Terminal (nächster Abschnitt); jede Protokollzeile wird ebenfalls auf stderr gespiegelt.
Erfassen von stderr aus einem Terminal
Die App spiegelt ihre Logs auf die Standardfehlerausgabe. Wenn Sie sie aus einem Terminal starten, erhalten Sie eine dauerhafte, kopierbare Aufzeichnung, die einen App-Neustart oder Absturz überdauert:
"/Applications/Bromure Agentic Coding.app/Contents/MacOS/bromure-cli" run
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 Automatisierungs-Zustandscheck (GET /health)
Die App betreibt einen ausschließlich für den Besitzer zugänglichen Control-Socket unter ~/Library/Application Support/BromureAC/control.sock, solange sie läuft. Sie können bestätigen, dass die App aktiv ist und antwortet, indem Sie sie nach ihrem Zustand fragen, was ein kleines JSON-Objekt zurückgibt:
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 aktiviert haben (Einstellungen → Automatisierung, standardmäßig aus), ist derselbe Endpunkt über TCP am konfigurierten Port erreichbar — 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 eine weitere schnelle Prüfung auf Erreichbarkeit. Das Flag debugEnabled meldet, ob BROMURE_DEBUG_CLAUDE die Debug-Endpunkte freigeschaltet hat.
Das Setup-Konsolenprotokoll
Während einer Base-Image-Installation verfügt das Setup-Fenster über ein eingeklapptes Aufklappelement Konsolenausgabe, das das rohe Installationsprotokoll streamt, mit einer Schaltfläche Kopieren. Klappen Sie es auf, um den Fortschritt zu beobachten, und kopieren Sie das gesamte Protokoll, falls Sie es einem Fehlerbericht anhängen müssen. Nur die letzten 100 Zeilen bleiben auf dem Bildschirm, kopieren Sie also, bevor das Fenster schließt.
Einrichtung und Base-Image-Installation
Die App kann keinen Arbeitsbereich ausführen, bevor ein Linux-Base-Image existiert. Der erste Start zeigt das Fenster Willkommen bei Bromure Agentic Coding; ein Klick auf Erste Schritte führt dieselbe Installation aus wie bromure-cli init. Der vollständige Ablauf ist in Installation dokumentiert; dieser Abschnitt behandelt, was zu tun ist, wenn er fehlschlägt.
Der vorgefertigte Download schlägt fehl oder bleibt hängen
Ursache. Der bevorzugte Weg lädt ein signiertes, gzip-komprimiertes Image (~3 GB) von https://dl.bromure.io herunter, überprüft dessen SHA-256 und entpackt es. Eine Netzwerkunterbrechung, ein CDN-Aussetzer oder eine Prüfsummen-Diskrepanz bricht ihn ab. Der Download versucht es bereits bis zu dreimal und ruft zwischen den Versuchen den Katalog erneut ab (die wöchentliche Veröffentlichung kann den vorherigen Build mitten im Download löschen).
Behebung. Beobachten Sie das Status-Pill und die Konsolenausgabe im Setup-Fenster. Bei einem Fehler auf der Download-Seite zeigt die GUI eine Warnung Image-Download fehlgeschlagen mit den Optionen Lokal erstellen oder Abbrechen:
- Wenn Sie online sind und es sich um einen vorübergehenden Fehler handelte, schließen Sie die Meldung und versuchen Sie es erneut über das App-Menü: Base-Image neu erstellen… → Vorgefertigtes herunterladen.
- Wenn der Download nicht erfolgreich sein wird (restriktives Netzwerk, blockiertes CDN), wählen Sie Lokal erstellen, um das Image stattdessen auf Ihrem Mac zu erstellen (etwa 10 Minuten). Dies erzeugt dasselbe Image.
- Über die Befehlszeile fällt
bromure-cli initohne Nachfrage 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 einer Warnung Netzwerkproblem während der Base-Image-Erstellung mit den Optionen Reparieren und wiederholen (startet die macOS-Netzwerk-Daemons über den Network Healer neu — fragt nach Ihrem Admin-Passwort) oder Abbrechen. Wenn er in einem VPN weiterhin fehlschlägt, begrenzen Sie die MTU der Gast-NIC vor dem erneuten Versuch (Tunnel im WireGuard-Stil benötigen oft 1280 oder weniger):
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 erfordert vorab mindestens 8 GB freien Speicher auf dem Volume, das das Support-Verzeichnis enthält, und ein Monitor bricht mitten im Build ab, wenn der freie Speicher unter 1 GB fällt (damit apt/debootstrap nicht in ein unerklärliches Timeout hineinlaufen).
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 vorübergehende Dateien: base.img.partial, base.img.gz.partial und efivars.partial im Support-Verzeichnis. Ihr Vorhandensein bedeutet, dass eine Installation entweder läuft oder unterbrochen wurde. Das eigentliche Image wird immer nur atomar heraufgestuft, sodass ein vorhandenes funktionierendes Image durchgehend nutzbar bleibt.
Behebung. Führen Sie die Installation vollständig erneut aus (Base-Image neu erstellen… oder bromure-cli init). Um komplett von vorne zu beginnen, löscht bromure-cli reset nach einer Bestätigung die vier Base-Image-Artefakte (base.img, efivars.bin, base.version, image-state.json) — es rührt Ihre Arbeitsbereiche, die zwischengespeicherten Alpine-Dateien oder den zwischengespeicherten Katalog nicht an. Bestätigen Sie jederzeit, was installiert ist, mit bromure-cli info, das den Versionsstempel, die logische und physische Größe sowie den Pfad ausgibt (oder "No base image yet.").
Ein Arbeitsbereich startet oder setzt nicht fort
Wählen Sie den Arbeitsbereich in der Seitenleiste aus, um sein Dashboard zu sehen: das Status-Pill (Aus, Angehalten, Läuft), die Karten CPU / Speicher / vCPUs / Disk / Betriebszeit, die Zusammenfassung KONFIGURATION und eine Schaltfläche Starten oder Fortsetzen. Der Lebenszyklus von Arbeitsbereichen wird in Arbeitsbereiche behandelt; die folgenden Symptome sind diejenigen, die eine VM hängen lassen.
Starten bewirkt nichts, oder die VM beendet das Booten nie
Ursache. Anders als der Browser-Bereich werden Arbeitsbereich-VMs nicht vorgewärmt — sie booten kalt von ihrer Copy-on-Write-Platte (oder werden aus einem Suspend-Snapshot wiederhergestellt), was einige Sekunden dauert. Ein CLI-Attach wartet bis zu etwa 60 Sekunden durch den Bootvorgang. Ein tatsächlich hängen gebliebener Boot bedeutet in der Regel ein defektes Gast-Dateisystem oder eine Konfigurationsdatei, an der sich der Gast verschluckt.
Behebung.
- Geben Sie ihm Zeit und prüfen Sie dann die CPU-Sparkline im Dashboard — nach einer Minute flach bei null bedeutet, dass er keine Fortschritte macht.
- Starten Sie ihn direkt über die Aktionsleiste des Dashboards neu (Neustart → Harter Neustart reißt ihn sofort ab).
- Wenn er immer noch nicht bootet, ist möglicherweise die Platte selbst beschädigt. Stellen Sie über die Rollback-Oberfläche des Arbeitsbereichs einen kürzlichen guten Zustand wieder her oder verwenden Sie Disk zurücksetzen, um vom Base-Image neu zu klonen (dabei bleibt das Home-Verzeichnis erhalten; ein gespeicherter RAM-Snapshot und der Tab-Zustand entfallen). Auf Basis zurücksetzen… ist die radikalste Option.
- Um zu reparieren statt zurückzusetzen, untersuchen Sie die gestoppte Platte mit dem ext4-Browser — siehe Einen Arbeitsbereich wiederherstellen, den eine defekte Datei am Booten hindert.
Ein angehaltener Arbeitsbereich lässt sich nicht fortsetzen
Ursache. Das Fortsetzen stellt den gespeicherten RAM (vm.state) und das Tab-Layout (tabs.json) wieder her, was die persistente Maschinenidentität und MAC des Arbeitsbereichs erfordert. Wenn sich die freigegebenen Ordner des Arbeitsbereichs geändert haben, während er angehalten war, wäre das Fortsetzen unsicher.
Behebung. Wenn sich Freigaben geändert haben, fragt die App Angehaltene VM für "…" verwerfen? — wählen Sie Verwerfen & sichern; der nächste Start bootet sauber kalt. Ihre Home- und freigegebenen Ordnerdateien bleiben unberührt. Beachten Sie, dass ein gespeicherter RAM-Snapshot immer verworfen wird, wenn die Platte zurückgesetzt oder gelöscht wird: Eine frische Platte in Kombination mit altem RAM würde sofort beschädigt werden, dies ist also beabsichtigt.
Der Arbeitsbereich ist als "Kompromittiert" markiert
Ursache. Der Proxy hat einen ausgehenden Versuch erkannt, Zugangsdaten einer Sitzung an einen Host zu leaken, für den sie nicht ausgestellt wurden, und Sie haben Herunterfahren oder Zur Untersuchung sichern gewählt. Der Arbeitsbereich ist mit compromised.flag gekennzeichnet und der Picker versieht ihn mit dem Abzeichen "Kompromittiert — beim Start wird zum Löschen von Disk und Home aufgefordert."
Behebung. Der nächste Start verweigert das Booten, bis Sie das Löschen bestätigen. Löschen und starten entfernt die Platte, das Home, den RAM-Snapshot und den Tab-Zustand und bootet dann sofort eine frische VM — Ihre Token, SSH-Schlüssel und Arbeitsbereich-Einstellungen bleiben erhalten. Freigegebene Projektordner liegen außerhalb des Speichers von Bromure und werden nicht gelöscht, prüfen Sie sie daher von Hand auf kontaminierte Dateien. Der vollständige Erkennungsablauf ist in Zugangsdaten beschrieben.
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. Geben Sie Speicherplatz frei (siehe Speicherplatz) und versuchen Sie Starten erneut.
Einen Arbeitsbereich wiederherstellen, den eine defekte Datei am Booten hindert
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 integrierten ext4-Browser im Userland, bei gestoppter Arbeitsbereich-VM:
- Menü Arbeitsbereiche → ext4-Datei öffnen…, wählen Sie dann die
disk.imgoderhome.imgdes Arbeitsbereichs unter~/Library/Application Support/BromureAC/profiles/. - Navigieren Sie zur betreffenden Datei. Klicken Sie mit der rechten Maustaste, um sie in der Vorschau anzuzeigen oder auf Ihren Mac zu Extrahieren….
- Um sie an Ort und Stelle zu korrigieren, klicken Sie auf Bearbeiten aktivieren… (es gibt eine ausdrückliche Warnung — bearbeiten Sie niemals ein Image, das eine laufende VM geöffnet hat), und dann mit Rechtsklick → Ersetzen… durch eine korrigierte Kopie von Ihrem Mac.
- Wenn der Browser meldet, dass das Journal wiederhergestellt werden muss, führen Sie zuerst fsck ausführen… aus (benötigt
e2fsprogs; die App schlägtbrew install e2fsprogsvor, falls es fehlt).
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 verweigert, während das Sitzungsfenster des Arbeitsbereichs geöffnet ist.
Behebung. Schließen Sie zuerst das Sitzungsfenster (der Tooltip der Schaltfläche lautet "Schließen Sie zuerst das Sitzungsfenster."), und versuchen Sie es dann erneut.
Fehler bei der Agent-Authentifizierung
Das Design hält echte Zugangsdaten von der VM fern: Der Gast läuft mit Platzhalter-Token ("gefälschten" Token), und der Host-Proxy setzt echte Geheimnisse auf der Übertragung ein. Die meisten "Auth"-Symptome lassen sich auf diese Grenze zurückführen. Siehe Zugangsdaten für das vollständige Modell.
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 innerhalb der VM zu "korrigieren". Wenn echte Anfragen mit einem Authentifizierungsfehler beim Anbieter fehlschlagen, liegt das Problem beim echten Geheimnis auf dem Host: Öffnen Sie den Bereich Zugangsdaten des Arbeitsbereichs und geben Sie es erneut ein. Ein gefälschtes Token, das in einer Anfrage an den falschen Host auftaucht, löst die Kompromittierungserkennung aus, statt zu authentifizieren.
Eine Abonnement-Anmeldung (Bei Claude / ChatGPT / Grok registrieren) funktioniert nicht mehr
Ursache. Im Auth-Modus Abonnement wurden die OAuth-Token einmalig in einer wegwerfbaren Registrierungs-VM erfasst und verschlüsselt auf dem Host gespeichert (claude-subscription.enc, codex-subscription.enc, grok-subscription.enc); der Host besitzt die Aktualisierung. Wenn das Refresh-Token widerrufen oder abgelaufen ist oder die Sitzung des Kontos endet, kann der Host kein gültiges Bearer-Token mehr ausstellen und Anfragen beginnen fehlzuschlagen.
Behebung. Registrieren Sie sich erneut. Vergessen Sie im Bereich Agenten des Arbeitsbereichs das gespeicherte Abonnement und führen Sie Bei Claude / ChatGPT / Grok registrieren erneut aus — dies startet eine frische wegwerfbare VM, erfasst neue Token und speichert sie host-seitig. Der Schein-Schlüssel innerhalb des Arbeitsbereichs ändert sich nie.
"Abonnement-Token austauschen?" erscheint immer wieder oder wurde versehentlich abgelehnt
Ursache. Dies ist der andere Abonnement-Mechanismus: Wenn sich ein Agent mit einem echten Token innerhalb der VM anmeldet, erkennt der Proxy dies und bietet an, es auf den Host zu verschieben, damit das echte Geheimnis den Gast verlässt. Die Wahl wird pro Arbeitsbereich und pro Anbieter gespeichert.
Behebung. Im Bereich Tracing des Arbeitsbereichs zeigen die Zeilen Claude subscription token swap und Codex subscription token swap Aktiv oder Abgelehnt mit einem Zurücksetz-Steuerelement an — Austausch vergessen (in der nächsten Sitzung erneut fragen) oder Aufforderung wieder aktivieren. Setzen Sie zurück, um in der nächsten Sitzung erneut gefragt zu werden. Zustimmungen und Pro-Sitzung-Gewährungen liegen nur im Arbeitsspeicher und überdauern keinen App-Neustart.
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.
- Für die meisten Werkzeuge ist keine Aktion erforderlich. Wenn ein bestimmtes Werkzeug fehlschlägt, verweisen Sie es auf das System-/exportierte CA-Bundle, statt die Überprüfung zu deaktivieren; die CA-Datei ist innerhalb des Gasts verfügbar und die Standardvariablen im Stil von
*_CA_BUNDLE/SSL_CERT_FILEsind bereits exportiert. - Für einen Docker-Container, der das Netzwerk erreichen muss, verwenden Sie den Umschalter HTTP-Proxy-Einstellungen übernehmen im Blatt Neuen Container ausführen, damit
http_proxy/https_proxypropagiert werden, und mounten oder installieren Sie die CA dort, wo die Werkzeuge des Containers danach suchen. - Wenn Zertifikatfehler erst nach dem Löschen oder Rotieren der CA auftreten (siehe unten), starten Sie betroffene Sitzungen neu, damit die neue CA erneut eingespielt wird.
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 bei ihrem nächsten Start erneut in die Arbeitsbereiche eingespielt. Bereits erfasste Trace-Bodys bleiben unberührt, aber jeder Gast, der das alte Zertifikat gepinnt hat, muss dem neuen erneut vertrauen.
Lieferketten-Blockaden
Wenn das npm install, pip install oder Ähnliches eines Agenten mit einem markanten Fehler fehlschlägt, hat höchstwahrscheinlich die Host-Lieferketten-Pipeline eingegriffen. Die Richtlinie, ihre Schichten und das Sicherheitsprotokoll sind in Lieferketten-Schutz und 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 Meldung | Schicht | Wie fortzufahren ist |
|---|---|---|
| "published … ago — policy requires N days" | Alters-Gate | Fixieren Sie eine ältere Version oder fügen Sie das Paket im Bereich Lieferkette des Arbeitsbereichs zu Ausgenommene Pakete hinzu. |
| Ein CVE / Advisory auf oder über Ihrer Schwelle | OSV oder socket.dev | Wählen Sie eine gepatchte Version oder erhöhen Sie die Schwelle Blockieren ab Schweregrad. |
| Als kompromittiert / Malware / Typosquat markiert | socket.dev | Behandeln Sie es als echtes Signal — überprüfen Sie den Paketnamen, bevor Sie es überschreiben. |
Das Sicherheitsprotokoll auf den Grund hin lesen
Öffnen Sie Fenster → Sicherheitsprotokoll… und führen Sie die Installation erneut aus. Zeilen sind farbcodiert: blau für ausgehende Abfragen, grün für saubere Urteile, rot für Blockaden und Fehler, orange für entfernte Installationsskripte und eine hervorgehobene Zeile [supply-chain] jedes Mal, wenn eine Richtlinie greift. Eine vollständig saubere Installation gibt weiterhin eine Zeile "inspecting pkg@ver" pro Artefakt aus — das ist beabsichtigt, sodass ein stilles Protokoll "alles zwischengespeichert" bedeutet, nicht "Proxy umgangen".
Eine Blockade überschreiben
Behebung. Lieferketten-Schichten sind Ein/Aus-Umschalter pro Arbeitsbereich, die live bearbeitet werden (kein VM-Neustart erforderlich). Um ein bestimmtes Paket durchzulassen, fügen Sie entweder einen Ausnahme-/Allowlist-Eintrag im Bereich Lieferkette hinzu oder senken/deaktivieren Sie die betreffende Schicht für diesen Arbeitsbereich. Das Sichern überträgt die Änderung sofort auf laufende Sitzungen.
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 durchsucht die an den Agenten zurückgegebenen Tool-Ergebnis-Spans und kann protokollieren, nachfragen oder blockieren. Sein Verhalten und seine Feinabstimmung finden sich in Prompt-Injection und der Referenz Prompt-Injection-Einstellungen.
Eine legitime Anfrage wurde markiert oder blockiert
Ursache. Der Klassifizierer bewertete einen eingehenden Span über der Schwelle des Arbeitsbereichs — Sicherheitsdokumentation, eine Seite, die einen Angriff zitiert, oder ein Ausschnitt, der wie eine Anweisung an den Agenten liest, können alle injection-förmig aussehen.
Behebung.
- Prüfen Sie das Sicherheitsprotokoll — die lokale Zeile enthält eine kurze Vorschau des markierten Ausschnitts, sodass Sie beurteilen können, ob es sich um einen echten Versuch handelte.
- Wenn es eine Falschmeldung war und Blockaden im Weg sind, ändern Sie den Prompt-Injection-Modus des Arbeitsbereichs von Blockieren auf Fragen (Sie entscheiden pro Erkennung) oder Protokollieren (nur aufzeichnen, niemals blockieren) im Bereich Prompt-Injection.
- Modell-Downloads und das Verhalten pro Umschalter sind pro Arbeitsbereich, sodass ein lärmender Recherche-Arbeitsbereich im Modus Protokollieren laufen kann, während ein produktiver auf Blockieren bleibt.
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 aus dem Bereich Prompt-Injection (oder Einstellungen → Automatisierung). Wenn ein Detektor-Umschalter aktiviert ist, das Modell aber nicht heruntergeladen werden konnte — zum Beispiel weil die Platte voll war — läuft der Arbeitsbereich ungeschützt und der Fehler wird protokolliert; laden Sie erneut herunter, sobald Speicherplatz verfügbar ist.
Speicherplatz: wohin er geht und wie man ihn zurückgewinnt
Was Speicherplatz verbraucht
Der Speicher liegt unter ~/Library/Application Support/BromureAC/ (siehe Anhang für die vollständige Karte). Die größten Verbraucher, größte zuerst:
| Was | Wo | Typische Größe |
|---|---|---|
| Das Ubuntu-Base-Image | base.img | 24 GB logisch, ~6–8 GB physisch |
| Systemplatten pro Arbeitsbereich | profiles/<uuid>/disk.img | Copy-on-Write-Klon der Basis; wächst nur, während der Gast schreibt |
| Homes pro Arbeitsbereich | profiles/<uuid>/home.img | Sparse ext4, standardmäßig 64 GB scheinbar, verzögert zugewiesen |
| RAM-Snapshots angehaltener VMs | profiles/<uuid>/vm.state | Ungefähr der zugewiesene RAM des Arbeitsbereichs (2–32 GB) pro angehaltenem Arbeitsbereich |
| Disk-/Home-Prüfpunkte | profiles/<uuid>/checkpoints/ | Echter Speicher, wenn sie von der Live-Platte abweichen |
| Lokale Inferenzmodelle | models/<org>--<name>/ | Mehrere GB pro Modell |
| Detektormodelle | Models/prompt-injection/, Models/claudemd-guard/ | ~300 MB bzw. ~600 MB |
| Trace-Bodys | traces/ | Begrenzt: 100 MB pro Sitzung, 5 GB insgesamt |
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 Arbeitsbereiche herunter, die Sie nicht verwenden. Ein vollständiges Herunterfahren löscht
vm.state; der Arbeitsbereich bootet beim nächsten Mal kalt. - Entfernen Sie ungenutzte lokale Modelle mit
bromure-cli model rm <id>(gibt die Gewichte sowohl aus dem neuen Layout als auch aus dem alten Hugging-Face-Cache frei). - Setzen Sie eine aufgeblähte Arbeitsbereich-Platte zurück mit Disk zurücksetzen (klont von der Basis neu, behält das Home) oder löschen Sie alte Prüfpunkte über die Rollback-Oberfläche.
- 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 einen ganzen Arbeitsbereich, den Sie nicht mehr benötigen, mit
bromure-cli workspaces rm <workspace>(entfernt Disk und Home nach Bestätigung). - Gewinnen Sie das Base-Image zurück mit
bromure-cli reset, wenn Sie neu beginnen möchten (Arbeitsbereiche bleiben unberührt, führen Sie danach also erneutinitaus).
Fernzugriff und der Rich Client
Die optionale SSH-Fernzugriffs-Vordertür und die Rich-Client-Spiegelung werden in Fernzugriff behandelt. Die folgenden Symptome sind diejenigen, die eine Verbindung blockieren.
Verbindung über SSH (Port 2222) nicht möglich
Ursache. Die Fernzugriffs-Vordertür ist standardmäßig deaktiviert. Sie ist außerdem ein eingebetteter Server (nicht das System-sshd), sodass das Aktivieren der macOS-Fernanmeldung nichts für sie bewirkt, und sie wird während jeder Base-Image-Installation oder -Änderung automatisch pausiert.
Behebung.
- Prüfen Sie den Status mit
bromure-cli remote status— es gibt aus, ob der Server ENABLED und laufend ist, die Bind-Adresse und den Port, die Auth-Methoden, den Fingerabdruck des Host-Schlüssels, eine fertige Verbindungszeichenkettessh -p <port> <user>@<host>sowie die Liste der autorisierten Schlüssel. - Aktivieren Sie ihn mit
bromure-cli remote enable(Standardwerte: Port2222, Bind0.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. - 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 Host-Schlüssel jedes Remotes bei der ersten Verbindung (Trust-on-First-Use), gespeichert in ~/Library/Application Support/BromureAC/remote-client/known_hosts. Das Pinning erfolgt pro Endpunkt (address:port), sodass das Bearbeiten der Adresse oder des Ports eines gespeicherten Hosts den übernommenen Pin ungültig macht und die Vertrauensaufforderung korrekt erneut auslöst. Eine Diskrepanz bei einem unveränderten 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.
Das Remote-Grid oder der Browser-Bereich lässt sich nicht spiegeln
Ursache. Ein Headless-Remote — die App läuft, hat aber kein vereinheitlichtes Fenster geöffnet — kann keine Grid-Layout-Änderungen annehmen oder bereitstellen, obwohl alles andere gespiegelt wird. Einige prompt-gesteuerte Worktree-Operationen (neuer Worktree, Merge, Auflösen) sind in v1 ebenfalls nicht vom Rich Client aus verfügbar, und das Multi-Host-Subnetz-Aliasing ist eine dokumentierte Design-Einschränkung, kein ausgeliefertes Verhalten: Ein einzelner Remote-Host ist die unterstützte Konfiguration.
Behebung. Öffnen Sie ein Sitzungsfenster auf dem Remote, damit er ein vereinheitlichtes Fenster zum Spiegeln hat. Verwenden Sie für das Erstellen/Zusammenführen/Auflösen von Worktrees auf einem Remote das SSH/TUI-Remote-Menü statt der Rich-Client-Symbolleiste.
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). Über den Tunnel wird ein ICMP-Ping an einen Remote-Gast lokal beantwortet und bestätigt das Routing, nicht die Erreichbarkeit des Gasts.
Einen Fehler melden
Wenn Sie einen Bericht auf bromure.io einreichen, fügen Sie genug bei, damit ein Maintainer ihn reproduzieren kann:
- App- und Image-Versionen — die App-Version (4.3.0) und die Ausgabe von
bromure-cli info(der Versionsstempel des Base-Images, die Größen und der Pfad). - Das stderr-Protokoll — starten Sie
bromure-cliaus einem Terminal, wie unter Erfassen von stderr gezeigt, reproduzieren Sie das Problem und hängen Sie die Ausgabe an. Fügen SieBROMURE_AC_DEBUG=1hinzu, wenn der Maintainer mehr Details anfordert. - Das relevante Fenster — bei Setup-Fehlern die kopierte Konsolenausgabe aus dem Setup-Fenster; bei sicherheitsbezogenem Verhalten das gefilterte Sicherheitsprotokoll.
- Was Sie erwartet haben im Vergleich zu dem, was passiert ist, und ob der Arbeitsbereich Aus, Angehalten oder Läuft war.
Fügen Sie keine echten Geheimnisse bei — Trace-Aufzeichnungen und Protokollzeilen schwärzen sie bereits zu kurzen Vorschauen, und die App ist so gebaut, dass echte Zugangsdaten von vornherein nie in eine VM gelangen. Wenn Ihr Mac mit einem bromure.io-Arbeitsbereich registriert ist, leiten Sie Berichte über den Administrator Ihrer Organisation; registrierungsbezogener Zustand ist für ihn sichtbar und nicht direkt für Bromure. Die Registrierung wird in Enterprise behandelt.