Konzepte & Architektur

Bromure Agentic Coding führt KI-Coding-Agenten in hardwarevirtualisierten Linux-Maschinen auf Ihrem Mac aus und setzt jede Sicherheitskontrolle an einem Punkt durch, den der Agent nicht umgehen kann. Dieses Kapitel definiert die Begriffe, auf die sich der Rest des Handbuchs stützt — Sitzung, Maschine, Raum, Branch, Host und Gast, die Übertragungsgrenze — und erklärt, wie die Teile zusammenpassen. Wenn Sie über den Schnellstart hinaus nur ein Kapitel lesen, dann dieses.

Sitzungen, Maschinen, Räume und Branches

Vier Objekte machen fast alles aus, was Sie in der App tun.

Sitzung

Eine Sitzung ist ein Gespräch mit einem Agenten, in einem Ordner, auf einer Maschine. Sie starten sie im Bildschirm für neue Sitzungen; sie hat einen Titel (der Agent vergibt ihn anhand Ihrer ersten Nachricht, und Sie können ihn umbenennen), einen Agenten (Claude Code, Codex, Grok, Kimi Code oder Oh My Pi), eine Maschine und einen Arbeitsordner auf dieser Maschine. Sitzungen sind das, was die Seitenleiste auflistet und der Chat zeigt.

Innerhalb der Maschine ist eine Sitzung ein Agent, der in einem eigenen Terminal-Tab läuft. Diesen Tab müssen Sie selten sehen, aber Sie können: Die Pille Linux in der Symbolleiste (⌥⌘U) oder Im Linux-Terminal öffnen im Menü der Sitzung wechselt dorthin, und die Pille (die dann Sitzung zeigt) wechselt zurück.

Eine Sitzung überdauert den Agentenprozess. Beendet sich der Agent oder fährt seine Maschine herunter, bleibt die Sitzung mit ihrem Gespräch in der Seitenleiste, und Ihre nächste Nachricht startet den Agenten erneut im selben Gespräch. Siehe Die Sitzungsübersicht.

Maschine

Eine Maschine ist eine isolierte Linux-VM samt ihren Einstellungen und ihrem dauerhaften Speicher. Das Hauptfenster sagt Maschine; der Einstellungseditor, mehrere Menüs (Neuer Arbeitsbereich…, Arbeitsbereiche) und die Befehlszeile sagen Arbeitsbereich (intern und in Dateinamen wie profile.json ein Profil). Alle drei Wörter meinen dasselbe.

Eine Maschine legt die Zugangsdaten, freigegebenen Ordner, die Umgebung, MCP-Server, Schutzmaßnahmen, Modell-Überschreibungen, das Erscheinungsbild und die VM-Größe fest, die für jede Sitzung auf ihr gelten — alles, was Sie im Einstellungseditor bearbeiten. Jeder Agent ist auf jeder Maschine verfügbar. Eine Maschine existiert, ob sie läuft oder nicht, und viele Sitzungen können gleichzeitig auf einer Maschine laufen, jede in ihrem eigenen Ordner und Terminal-Tab.

Üblich ist eine Maschine pro Projekt oder pro Zugangsdaten-Grenze: Sitzungen auf derselben Maschine teilen deren Festplatte, Zugangsdaten und Netzwerkidentität. Maschinen stehen in der Seitenleiste unter Virtuelle Maschinen; siehe Maschinen.

Ein Maschinenlauf ist ein zusammenhängender Zeitraum, in dem die VM einer Maschine eingeschaltet ist: Er beginnt, wenn die Maschine startet oder fortgesetzt wird, und endet, wenn sie herunterfährt oder angehalten wird. Mancher Zustand gehört zum Lauf, nicht zur Maschine: Von Ihnen erteilte Freigaben für Zugangsdaten liegen im Speicher und werden am Ende des Laufs widerrufen, und die Konfigurationsfreigaben pro Boot werden bei jedem Start neu aufgebaut.

Raum

Ein Raum fasst Sitzungen zusammen, die an derselben Sache arbeiten. Öffnen Sie einen Raum, sehen Sie seine Sitzungen nebeneinander als Raster von Live-Chats, dazu ein Eingabefeld, das an jede einzelne oder an alle gleichzeitig senden kann. Ein Raum kann eine eigene Schaltzentrale haben, eine Sitzung, die die Sitzungen dieses Raums im Blick behält und nur diese. Sitzungen eines Raums können auf verschiedenen Maschinen laufen. Siehe Räume.

Branch-Sitzung

Eine Branch-Sitzung ist eine Sitzung, die aus einer anderen Sitzung auf einem eigenen Git-Branch gestartet wird, in einem separaten Checkout (einem Git-Worktree) desselben Repositorys auf derselben Maschine. Sie arbeitet, ohne den Ordner der ursprünglichen Sitzung anzufassen, und wenn Ihnen das Ergebnis gefällt, prüfen Sie es und führen es zurück. Siehe Branches und Review.

Sitzungen, die andere Sitzungen starten

Zwei Arten von Sitzungen werden für Sie gestartet statt von Ihnen:

• Delegierte. Ein Agent kann einen Auftrag an eine neue Kind-Sitzung übergeben — auf einem eigenen Branch oder einer anderen Maschine — und auf das Ergebnis warten. Das Kind erscheint unter der Sitzung, die es gestartet hat. Ein Agent kann auch über den @Spitznamen eine Anfrage an eine bestehende Sitzung senden. Siehe Agenten arbeiten zusammen.
• Die Schaltzentrale. Eine Claude-Code-Sitzung, die alle anderen Sitzungen im Blick behält. Sie erscheint in der Seitenleiste, sobald zwei oder mehr Sitzungen laufen, arbeitet im Ordner ~/.bromure/switchboard auf der zuletzt verwendeten Maschine und kann nach strengen Regeln Sitzungen für Sie lesen, beantworten und starten. Die eigene Schaltzentrale eines Raums arbeitet in ~/.bromure/rooms/<room> und sieht nur diesen Raum. Siehe Schaltzentrale und Messaging.

Auch Automatisierungsläufe und Coding-Aufgaben laufen als Sitzungen und werden archiviert, wenn sie fertig sind; siehe Automatisierungen und Coding-Aufgaben.

Sitzungszustände

Die Seitenleiste gruppiert Sitzungen danach, was sie von Ihnen brauchen, nie danach, auf welcher Maschine sie laufen:

Zwei weitere Orte enthalten Sitzungen außerhalb dieser Gruppen:

• Archiviert ist ein eingeklappter Bereich am Ende der Sitzungsliste für Gespräche, die Sie weggelegt haben. Eine archivierte Sitzung bleibt lesbar, und eine Nachricht holt sie zurück. Sitzungen, die vor mehr als drei Tagen beendet wurden, werden automatisch archiviert, außer Sitzungen in einem Raum und Schaltzentralen. Delegierte, Coding-Aufgaben und Automatisierungsläufe werden archiviert, sobald sie fertig sind.
• Eine Sitzung, deren Maschine oder Ordner nicht mehr existiert, wird abgeblendet angezeigt, als „Maschine entfernt“ oder „Ordner entfernt“. Sitzungen gelöschter Maschinen werden am Ende der Liste in einer Zeile mit einer Schaltfläche Löschen gesammelt.

Der Host hält eine Kopie des Gesprächs jeder Sitzung (in ~/Library/Application Support/BromureAC/transcripts/), die aktualisiert wird, solange der Agent läuft, sodass eine pausierte, beendete oder archivierte Sitzung gelesen werden kann, ohne ihre Maschine zu starten.

Der Host und der Gast

Alles in Bromure Agentic Coding befindet sich auf einer Seite einer harten Trennlinie:

• Der Host ist Ihr Mac — macOS 14 oder neuer auf Apple Silicon — und die darauf laufende App Bromure Agentic Coding. Der Host hält alles Sensible: Ihre echten Zugangsdaten (verschlüsselt mit einem Hauptschlüssel im macOS-Schlüsselbund), Ihre Anmeldungen, den MITM-Proxy, der für den Agenten mit dem Internet spricht, den privaten Schlüssel der Bromure-Root-CA, den Trace und die Sicherheits-Zeitleiste sowie die Fenster, Chats und Terminals der App. Der Chat und die Terminals, in die Sie tippen, werden auf dem Host gezeichnet, nicht in der VM.
• Der Gast ist die Linux-VM, in der der Agent tatsächlich läuft — Claude Code, Codex, Grok, Kimi Code, Oh My Pi oder einfache Shell-Werkzeuge, mit allem, was sie installieren und berühren: geklonte Repositories, Paket-Caches, Docker-Container, Virtualenvs. Der Gast gilt per Design als nicht vertrauenswürdig. Er hält keine echten Geheimnisse, nur absichtlich ungültige Attrappen-Zugangsdaten, und sein ausgehender Webverkehr läuft durch den Proxy des Hosts.

Die beiden Seiten sprechen über zwei schmale Kanäle miteinander: vsock (virtio-Sockets, ein Host–Gast-Kanal, der kein Netzwerk braucht) für Steuerung, Terminals, MCP-Server und den Proxy-Pfad; und ein privates virtuelles Netzwerk für gewöhnlichen IP-Verkehr. Beide werden unten beschrieben.

Diese Trennung macht das Sicherheitsversprechen konkret: Ein per Prompt Injection manipulierter oder fehlerhafter Agent kann im Gast tun, was er will, aber er kann keinen echten API-Schlüssel lesen, nicht mit einem echten AWS-Geheimnis signieren und keinen privaten SSH-Schlüssel auslesen — nichts davon existiert auf seiner Seite der Linie.

Architektur auf einen Blick

Lesen Sie das Diagramm von unten nach oben: Der Agent arbeitet in der VM der Maschine; sein HTTPS verlässt sie über vsock zum Host-Proxy, dem einzigen Ort, an dem Attrappen zu echten Zugangsdaten werden; die App hängt sich über separate vsock-Brücken an die Terminals der VM; und eine optionale Wegwerf-Browser-VM teilt dasselbe private Netzwerk, damit sie die Entwicklungsserver des Agenten laden kann.

Neben Maschinen und Browser-VMs kann die App drei Arten eigener verwalteter VMs betreiben, alle im selben privaten Netzwerk: Kubernetes-Cluster-Knoten und eine Container-Registry (siehe Kubernetes-Cluster und Registries) sowie den Messaging-Connector, der die Schaltzentrale mit Signal, WhatsApp oder Slack verbindet (siehe Schaltzentrale und Messaging). Sie stehen in der Seitenleiste unter Virtuelle Maschinen, sind aber keine Maschinen: In ihnen läuft kein Agent.

Die VM der Maschine

Die VM jeder Maschine ist ein Ubuntu-24.04-Gast unter Apples Virtualization.framework, das Apple Silicon voraussetzt und nur ARM64-Gäste unterstützt. Sie bootet mit 4 vCPUs und der im Bereich Ressourcen der Maschine eingestellten Speichermenge, von zwei virtuellen Festplatten:

• disk.img — die Systemdisk. Beim ersten Start der Maschine wird sie als APFS-Copy-on-Write-Klon des gemeinsamen, signierten Ubuntu-Basis-Images angelegt (siehe Installation & erster Start): Der Klon ist sofort da und belegt keinen neuen Speicherplatz, bis der Gast darauf schreibt. Spätere Starts verwenden denselben Klon, sodass Pakete, die Sie mit apt install installieren, geladene Docker-Images und andere systemweite Änderungen erhalten bleiben.
• home.img — eine private ext4-Festplatte mit /home/ubuntu, als zweite Festplatte angehängt. Sie ist standardmäßig 16 GiB groß, belegt aber nur so viel Platz, wie sie gefüllt ist, und schrumpft auf dem Host, wenn im Gast Dateien gelöscht werden. Das Home übersteht ein Datenträger zurücksetzen — deshalb überdauern Ihre Repositories, Dotfiles, Ihr Shell-Verlauf und der Ordner jeder Sitzung ein Zurücksetzen der Systemdisk.

Der Gast bindet außerdem kleine Freigaben pro Boot ein: eine schreibgeschützte Meta-Freigabe mit der Konfiguration dieses Boots (Umgebungsdateien mit Attrappen-Zugangsdaten, Proxy-Einstellungen, das Zertifikat der Bromure-CA, Gast-Agenten, MCP-Konfiguration) und einen beschreibbaren Postausgang, über den der Gast dem Host berichtet (seine IP-Adresse, seine Terminal-Tabs, den Agentenstatus). Beide werden bei jedem Start neu aufgebaut und enthalten keinen dauerhaften Zustand. Bis zu 8 Ordner von Ihrem Mac können zusätzlich in den Gast freigegeben werden; sie erscheinen im Home-Ordner.

Persistent von Design her — der Gegensatz zu Bromure (Web)

Bromure Agentic Coding teilt seine Codebasis mit der Schwester-App Bromure, dem Webbrowser, und die beiden treffen bewusst gegensätzliche Entscheidungen zur Lebensdauer:

Programmieren braucht dauerhaften Zustand — geklonte Repositories, Paket-Caches, Virtualenvs, Shell-Verlauf —, und die VM nach jeder Sitzung wegzuwerfen, würde Agenten nutzlos machen. Statt den Zustand der VM zu kontrollieren, kontrolliert Bromure Agentic Coding, was die VM überhaupt enthalten darf: keine echten Geheimnisse und keinen unvermittelten Weg ins Internet. Wegwerfmaschinen gibt es trotzdem als Option: Datenträger zurücksetzen klont die Systemdisk neu aus dem Basis-Image, Home zurückdrehen… setzt das Home auf einen früheren Checkpoint zurück, bromure-cli vm run --rm erzeugt eine Wegwerfmaschine, die beim Stoppen gelöscht wird, und der Kompromittierungsablauf löscht eine verseuchte Disk und ein verseuchtes Home, behält aber Ihre Einstellungen und Schlüssel.

Die Browser-VM

Ein Stück Bromure (Web) lebt in Bromure Agentic Coding weiter: der eingebettete Browser neben einer Sitzung. Wenn Sie (oder der Agent) ihn öffnen, bekommt die Maschine eine zweite, wegwerfbare VM mit Ubuntu und Chromium, in einen temporären Ordner geklont und beim Schließen des Browsers gelöscht. Der Browserzustand wird standardmäßig verworfen, es sei denn, die Maschine schaltet Bei Websites angemeldet bleiben ein, was das Chromium-Profil auf einer verschlüsselten Festplatte pro Maschine behält. Die Browser-VM sitzt im selben privaten Netzwerk wie die Maschinen, damit sie einen Entwicklungsserver laden kann, den der Agent gerade gestartet hat. Siehe Der eingebettete Browser.

Maschinenzustände: Aus, Angehalten und Läuft

Jede Maschine befindet sich immer in einem von drei dauerhaften Zuständen. Kurz sehen Sie außerdem Startet…, während eine Maschine bootet.

Klappen Sie Virtuelle Maschinen unten in der Seitenleiste aus, um Ihre Maschinen zu sehen. Ein Klick auf eine Maschine zeigt ihr Dashboard: CPU, Speicher, Festplatte und Laufzeit live, solange sie läuft, oder ihre Spezifikation und Konfiguration, wenn sie aus ist, mit einer Schaltfläche Starten oder Fortsetzen. Starten Sie eine Sitzung auf einer ausgeschalteten Maschine, wird sie für Sie gestartet.

Ein paar Regeln, die man kennen sollte:

• Anhalten ist ein Speicher-Snapshot, keine Speicherdatei. Um ihn wiederherzustellen, muss die Konfiguration der VM dieselbe sein wie beim Sichern. Ändern Sie etwas, wovon der Snapshot abhängt — etwa die Speichergröße oder die freigegebenen Ordner —, startet die Maschine stattdessen frisch, und keine Datei ist betroffen. Das App-Protokoll nennt, was sich geändert hat.
• Ein Snapshot überlebt seine Festplatte nie. Das Zurücksetzen oder Löschen der Systemdisk verwirft auch jeden gespeicherten Speicher-Snapshot, weil eine frische Festplatte mit veraltetem Speicher sofort beschädigt würde.
• Aus heißt nicht gelöscht. Eine heruntergefahrene Maschine behält ihre Systemdisk und ihr Home unbegrenzt. Tatsächliches Löschen ist immer ausdrücklich (Datenträger zurücksetzen, Home zurückdrehen…, Arbeitsbereich löschen) oder wird vom Kompromittierungsablauf erzwungen.

Schließaktionen

Was beim Schließen des Fensters einer Maschine passiert, ist eine Einstellung pro Maschine (Beim Schließen des Fensters im Bereich Allgemein): Im Hintergrund weiterlaufen lassen (die Maschine läuft ohne Fenster weiter), Anhalten, Herunterfahren oder Nachfragen — die Voreinstellung, die jedes Mal fragt. Siehe Maschinen.

Die Übertragungsgrenze

Die Übertragungsgrenze ist die zentrale Idee des Produkts: Der gesamte ausgehende Webverkehr des Gasts läuft durch einen host-seitigen Man-in-the-Middle-Proxy (MITM), und jeder Schutz — Geheimnisse bewahren, Zugangsdaten einschränken, Lieferketten-Prüfung, Prompt-Injection-Erkennung, Schutz personenbezogener Daten, Tracing — wird an diesem einen Punkt durchgesetzt. Der Agent kann ihn nicht umgehen, weil es auf seiner Seite der Linie nichts Brauchbares gibt.

Der Ablauf, von Anfang bis Ende:

1. Der Gast hält nur Attrappen. Wenn eine Maschine startet, schreibt der Host absichtlich ungültige Platzhalter-Zugangsdaten in die VM — Umgebungsvariablen wie ANTHROPIC_API_KEY und Dateien wie ~/.git-credentials, ~/.docker/config.json und ~/.kube/config. Attrappen behalten die Form der echten (sk-ant-api03-brm-…, in ghp_…-Form, brm_…), damit clientseitige Prüfungen sie akzeptieren, und sie sind für eine Installation stabil, sodass Werkzeuge nie einen Schlüsselwechsel zwischen Läufen sehen. Die passenden echten Werte werden auf dem Host in den Speicher des Proxys geladen, jeder an den Host gebunden, zu dem er gehört.
2. Das TLS des Gasts endet am Proxy. Jede Shell im Gast exportiert HTTPS_PROXY=http://127.0.0.1:65534, einen Endpunkt in der VM, der über vsock (Port 8443) zum Host-Proxy tunnelt. Zusätzlich leitet der virtuelle Netzwerk-Switch des Hosts ausgehende Verbindungen des Gasts zu den Ports 80 und 443 in denselben Proxy um, sodass auch ein Werkzeug, das die Proxy-Variablen ignoriert, durch ihn läuft. Der Proxy legt ein von der Bromure-Root-CA signiertes Zertifikat pro Host vor, prüft die Anfrage und verschlüsselt sie neu zum echten Server.
3. Attrappen werden erst auf dem Weg nach draußen echt. Der Proxy tauscht jede Attrappe gegen ihren echten Wert — Header-Austausch für API-Schlüssel und Tokens, die Ersatzschlüssel hinter Abonnement-Anmeldungen, vollständiges SigV4-Neusignieren für AWS (der Gast signiert mit einem falschen Geheimnis; der Host entfernt diese Signatur und signiert erneut mit dem echten) und ssh-agent-Signaturen über vsock für SSH. Der Austausch gilt nur für den registrierten Host und seine Subdomains, nie für einen Doppelgänger, sodass ein für api.anthropic.com registriertes Zugangsdatum nie in Richtung einer anderen Domain eingesetzt wird.

Eine Maschine kann die transparente Umleitung in ihrem Bereich Schutzmaßnahmen ausschalten; Proxy-Variablen, Zugangsdaten-Austausch, Tracing und Schutzmaßnahmen gelten weiterhin. Siehe Zugangsdaten & die Übertragungsgrenze.

Die Bromure-Root-CA

Der Proxy kann das TLS des Gasts nur lesen, weil der Gast ihm vertraut. Beim ersten Start erzeugt die App eine Zertifizierungsstelle pro Installation — die Bromure Agentic Coding Root CA —, deren öffentliches Zertifikat beim Booten über die Meta-Freigabe in den Vertrauensspeicher jeder VM installiert wird. Der private Schlüssel verlässt den Host nie (er liegt unter ~/Library/Application Support/BromureAC/ca/, nur für Sie lesbar). Nichts außerhalb Ihrer Bromure-VMs vertraut dieser CA: Sie kann nicht dazu dienen, den eigenen Verkehr Ihres Macs abzufangen, und das Löschen des Ordners ca/ erzeugt beim nächsten Start einfach eine neue CA.

Fail-closed von Design her

Das Design schlägt geschlossen fehl: Gelangt Gastverkehr je am Proxy vorbei — ein Raw-Socket auf einem ungewöhnlichen Port, ein bewusster Umgehungsversuch —, ist das einzige Zugangsdatum, das er vorlegen kann, eine Attrappe, die kein Server akzeptiert. AWS antwortet mit InvalidSignatureException; API-Anbieter lehnen den Platzhalterschlüssel ab. Die Grenze zu umgehen bringt einem Angreifer nichts, weil die Grenze nicht der Ort ist, an dem Geheimnisse geprüft werden — sie ist der einzige Ort, an dem Geheimnisse existieren.

Der Kompromittierungs-Detektor

Die Grenze achtet auch auf den umgekehrten Missbrauch: Exfiltration. Der Proxy durchsucht jede ausgehende Anfrage nach allen für die Maschine registrierten Attrappen-Tokens. Eine Attrappe hat genau ein legitimes Ziel — den Host, für den sie erzeugt wurde —, also ist eine Attrappe auf dem Weg anderswohin das Kennzeichen eines Agenten, der versucht, Zugangsdaten abfließen zu lassen. Der Proxy stoppt die Anfrage, pausiert die Maschine und warnt Sie, mit der Wahl, die Maschine herunterzufahren, die Anfrage zu blockieren oder dieses Ziel für den Rest der Sitzung zu erlauben. Da nur eine Attrappe hinausging, muss das echte Zugangsdatum nie rotiert werden. Das vollständige Zugangsdatenmodell, einschließlich Genehmigungsabfragen pro Zugangsdatum und zeitlich begrenzter Freigaben, steht unter Zugangsdaten & die Übertragungsgrenze.

Was persistiert und was nicht

Bromure Agentic Coding ist ausdrücklich darin, was bestehen bleibt. Die Dateien jeder Maschine liegen in ~/Library/Application Support/BromureAC/profiles/<uuid>/; Ihre Sitzungen liegen daneben im Support-Ordner.

Dauerhaft — übersteht Herunterfahren und App-Neustarts:

Temporär — automatisch neu aufgebaut oder gelöscht:

Daraus folgen zwei Dinge. Erstens löscht das Schließen eines Fensters oder das Beenden einer Sitzung nie von selbst etwas — die zerstörerischen Aktionen sind alle ausdrücklich und bestätigt. Das Löschen einer Sitzung entfernt ihr Gespräch aus der App, lässt ihren Ordner aber auf der Maschine. Zweitens haben Sie, wenn Sie einen sauberen Neuanfang wollen, eine Reihe von Möglichkeiten: Home zurückdrehen…, Datenträger zurücksetzen (das Home bleibt), die Maschine löschen oder eine Wegwerfmaschine mit bromure-cli vm run --rm.

Hinweis: Von Ihrem Mac freigegebene Ordner sind gewöhnliche Ordner auf Ihrer Festplatte, außerhalb des Speichers von Bromure. Keine Aktion von Bromure löscht sie je — auch nicht die Kompromittierungs-Löschung —, und die Löschabfrage sagt das auch.

Host-Gast-Brücken (vsock)

Alles Interaktive zwischen Mac und Gast läuft über virtio-Sockets — direkte Host–Gast-Kanäle, die unabhängig vom Netzwerk der VM existieren. Sie konfigurieren sie nie, aber zu wissen, dass es sie gibt, hilft beim Lesen von Traces oder der Fehlerbehebung. Jede Brücke nutzt einen nummerierten vsock-Port:

Brücken der Maschinen-VM:

Eingebaute MCP-Server — Werkzeuge, die der Host jedem Agenten auf der Maschine anbietet, jeweils über einen kleinen Shim im Gast erreicht:

Brücken der Browser-VM: Konfiguration (5000), Dateiübertragung (5100), Chrome DevTools Protocol (5200), Link-Relay (5300), Webcam (5400), Tab-Leiste (5810) und Netzwerk-Trace (5900).

Zwischenablage

Terminal-Tabs haben keinen eigenen Zwischenablage-Dienst — die Zwischenablage läuft durch das Terminal selbst. Kopieren im Gast (eine tmux-Auswahl oder jedes Programm, das OSC 52 nutzt) landet in der macOS-Zwischenablage; ⌘C kopiert die Auswahl in einem Terminal; ⌘V fügt in den Gast ein. Im Browser sorgt ein Zwischenablage-Agent im Gast für Kopieren und Einfügen zwischen Mac und Chromium.

Dateiübertragung

Dateien gelangen auf drei Wegen zwischen Mac und Maschine, alle beschrieben unter Maschinen: freigegebene Ordner (der normale Weg für Projektdateien, die auf Ihrem Mac liegen), der Dateibereich (hinein- und herausziehen, über die Shell-Brücke auf Port 5800) und Anhänge — jede Datei bis 512 MB, die in einen Chat oder ein Terminal gezogen oder eingefügt wird, wird in die Maschine kopiert und ihr Pfad an den Agenten übergeben.

Netzwerk

NAT-Modus (der Standard)

Alle Maschinen im NAT-Modus verbinden sich mit einem einzigen Software-Netzwerk-Switch in der App, der das Internet über eine einzige vmnet-NAT-Schnittstelle von macOS erreicht. Daraus folgt:

• Ein privates Subnetz. Eine frische Installation wählt zufällig ein privates /24 innerhalb von 172.16.0.0/12 und behält es, wobei sie jedes 172.x-Netz meidet, in dem Ihr Mac bereits ist (etwa das von Docker). Der Schalter unter Einstellungen › Ressourcen (Arbeitsbereich-Subnetz — Privates Subnetz verwenden (vermeidet Konflikte zwischen Remotes)) zeigt das Subnetz, und Zufällig wählen wählt ein neues; Änderungen gelten beim nächsten Start Ihrer Maschinen. Ist der Schalter aus, nutzt die App 192.168.64.0/24 oder ein anderes freies 192.168.x.0/24, falls Ihr LAN diesen Bereich schon verwendet.
• Die App betreibt ihren eigenen DHCP-Server an diesem Switch, und die Zuweisungen werden in dhcp-leases.sqlite gehalten. Jede Maschine hat eine stabile MAC-Adresse (in profile-macs.json) und behält daher meist über Neustarts hinweg dieselbe IP-Adresse. IP-Adresse kopieren im Maschinenmenü und das Dashboard der Maschine zeigen die aktuelle Adresse.
• VMs erreichen einander. Maschinen, Browser-VMs, Cluster-Knoten und die Registry liegen per Design im selben Netzwerk, sodass der Browser einen Entwicklungsserver auf einer Maschine laden kann und zwei Maschinen die Dienste der jeweils anderen nutzen können. Die Liste lauschender Ports im Dashboard zeigt jeden erreichbaren Dienst als <IP>:<port>, mit dem Sie sich vom Mac aus verbinden würden.
• Von außen isoliert. Die VMs sind von Ihrem Mac aus erreichbar, aber nicht aus Ihrem physischen LAN, und nichts anderes kann sich mit ihnen verbinden, es sei denn, Sie veröffentlichen einen Dienst ausdrücklich (etwa über einen Cloudflare-Quick-Tunnel aus der Liste lauschender Ports).
• Nur IPv4. IPv6 ist im Gast ausgeschaltet, und localhost wird zu 127.0.0.1 aufgelöst.

Die Netzwerk-MTU des Gasts steht standardmäßig auf 1280 — ein sicherer Wert hinter VPNs und Unternehmensnetzen — und lässt sich mit defaults write io.bromure.agentic-coding vm.mtu -int <Wert> erhöhen.

Denken Sie daran, dass gewöhnlicher IP-Verkehr nicht der Weg ist, auf dem sich Zugangsdaten bewegen: Webverkehr wird in den Proxy gelenkt, und alles, was an ihm vorbeikommt, trägt nur Attrappen-Zugangsdaten — die oben beschriebene Eigenschaft, geschlossen fehlzuschlagen.

Bridged-Modus (pro Maschine)

Eine Maschine kann stattdessen Ihrem physischen LAN beitreten: Stellen Sie Netzwerk im Bereich Ressourcen auf Bridged und wählen Sie eine Schnittstelle; die VM erscheint dann im lokalen Netz mit einer eigenen Adresse von Ihrem Router (nützlich, wenn andere Geräte sie direkt erreichen müssen). Ist die gewählte Schnittstelle beim Start nicht verfügbar, fällt die Maschine auf NAT zurück. Siehe Einstellungen › Ressourcen.

Schnelle Starts

Zwei Dinge sorgen dafür, dass Maschinen schnell starten:

• Copy-on-Write-Festplatten. Die Systemdisk einer neuen Maschine ist ein sofortiger Klon des Basis-Images statt einer Kopie, sodass der erste Start nicht auf das Schreiben von Gigabytes wartet. Spätere Kaltstarts sind gewöhnliche Linux-Boots.
• Anhalten und Fortsetzen. Eine Angehaltene Maschine überspringt den Boot ganz: Ihr Speicher-Snapshot wird wiederhergestellt, und sie macht dort weiter, wo sie aufgehört hat, samt Terminal-Tabs und Agenten.

Maschinen werden weder gepoolt noch vorgebootet: Jede Maschine ist ein eigener, dauerhafter Rechner, es gibt also nichts Austauschbares, das man warmhalten müsste. Die Ausnahme ist die Wegwerf-Browser-VM; sie stammt aus derselben Pool-Mechanik wie Bromure Web.