Konzepte & Architektur

Bromure Agentic Coding führt KI-Coding-Agenten in einer hardwarevirtualisierten Linux-Maschine auf Ihrem eigenen Mac aus und erzwingt jede Sicherheitskontrolle an einem einzigen Punkt, den der Agent nicht umgehen kann. Dieses Kapitel definiert das Vokabular, auf das sich der Rest des Handbuchs stützt — Host und Gast, Arbeitsbereich und Sitzung, die Übertragungsgrenze, persistenter und flüchtiger Speicher — und erklärt, wie die Teile zusammenpassen. Wenn Sie über den Schnellstart hinaus nur ein Kapitel lesen, lesen Sie dieses.

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 der darauf laufende Bromure-Agentic-Coding-Prozess. Der Host besitzt alles Sensible: Ihre echten Zugangsdaten (verschlüsselt mit einem Hauptschlüssel im macOS-Schlüsselbund), den MITM-Proxy, der im Auftrag des Agenten mit dem Internet spricht, den privaten Schlüssel der Bromure-Root-CA, den Trace-Speicher sowie die Fenster, Terminals und Dashboards der App. Das Terminal, in das Sie tippen, wird auf dem Host gerendert, nicht innerhalb der VM.
• Der Gast ist die virtuelle Linux-Maschine, in der der Agent tatsächlich läuft — Claude Code, Codex CLI, Grok CLI oder einfaches Shell-Tooling, zusammen mit allem, was diese installieren und berühren: geklonte Repositories, Paket-Caches, Docker-Container, virtualenvs. Der Gast wird von Grund auf als nicht vertrauenswürdig behandelt. Er enthält keine echten Geheimnisse, nur absichtlich ungültige gefälschte Zugangsdaten, und sein ausgehendes HTTPS wird durch den Proxy des Hosts geleitet.

Die beiden Seiten kommunizieren über zwei schmale Kanäle: vsock (virtio-Sockets, ein Host-zu-Gast-Transport, der überhaupt kein Netzwerk benötigt) für Steuerung, Terminals und den Proxy-Pfad sowie ein privates virtuelles Netzwerk (vmnet NAT) für gewöhnlichen IP-Verkehr. Beide werden unten ausführlich beschrieben.

Diese Aufteilung macht die Sicherheitsaussage des Produkts konkret: Ein durch Prompt-Injection oder anderweitig fehlverhaltender Agent kann innerhalb des Gasts alles tun, was er möchte, aber er kann keinen echten API-Schlüssel lesen, nicht mit einem echten AWS-Geheimnis signieren und keinen privaten SSH-Schlüssel extrahieren — 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 Arbeitsbereich-VM; sein HTTPS verlässt sie über vsock zum Host-Proxy, der der einzige Ort ist, an dem gefälschte Zugangsdaten zu echten werden; das Sitzungsfenster verbindet sich über separate vsock-Brücken mit den Terminals der VM; und eine optionale wegwerfbare Browser-VM teilt sich dasselbe private Netzwerk, sodass sie die Dev-Server des Agenten laden kann.

Arbeitsbereich, Sitzung und VM

Drei Begriffe tragen im gesamten Handbuch präzise, unterschiedliche Bedeutungen:

• Ein Arbeitsbereich ist eine gespeicherte Konfiguration plus ihr dauerhafter Speicher. Er definiert, welcher Agent läuft (und wie er sich authentifiziert), die Zugangsdaten, freigegebenen Ordner, Umgebung, MCP-Server, Schutzmechanismen, Darstellung und VM-Dimensionierung — alles, was Sie im Fenster Arbeitsbereich bearbeiten bearbeiten — und er besitzt ein Verzeichnis unter ~/Library/Application Support/BromureAC/profiles/<uuid>/, das seine Systemplatte, das Home-Image, SSH-Schlüssel, Prüfpunkte und gespeicherten Zustand enthält. Ein Arbeitsbereich existiert unabhängig davon, ob etwas läuft oder nicht. Intern (in Dateinamen wie profile.json und in CLI-Flags) wird ein Arbeitsbereich als Profil bezeichnet; die beiden Begriffe sind austauschbar. Übliche Praxis ist ein Arbeitsbereich pro Projekt oder pro Zugangsdaten-Grenze. Siehe Arbeitsbereiche.
• Die VM (virtuelle Maschine) ist die laufende Linux-Instanz, die aus dem Speicher eines Arbeitsbereichs gebootet wird. Jeder Arbeitsbereich ist auf genau eine VM abgebildet — einen Ubuntu-Gast mit eigenen Platten, deterministischer MAC-Adresse, IP-Adresse und MITM-Proxy-Listener pro Arbeitsbereich. Zwei Arbeitsbereiche teilen sich niemals eine VM, und ein Arbeitsbereich hat niemals zwei.
• Eine Sitzung ist ein durchgängiger Lauf der VM eines Arbeitsbereichs: Sie beginnt, wenn Sie den Arbeitsbereich starten (oder fortsetzen), und endet, wenn die VM heruntergefahren oder ausgesetzt wird. Das Sitzungsfenster kann sich von einer Sitzung lösen, ohne sie zu beenden — die Schließaktion Im Hintergrund ausführen lässt die VM headless weiterlaufen, und Sie können sich später aus der Seitenleiste wieder verbinden. Ein Teil des Zustands ist bewusst sitzungsgebunden: Zugangsdaten-Genehmigungen und -Ablehnungen leben nur im Speicher und werden beim Abbau der Sitzung widerrufen, und die Metadaten-Freigaben pro Start werden bei jedem Boot neu aufgebaut. Siehe Sitzungen.

Eine nützliche Kurzform: Der Arbeitsbereich ist das Substantiv (er bleibt auf der Platte bestehen), die VM ist die Maschine (sie existiert, solange sie eingeschaltet oder ausgesetzt ist), und die Sitzung ist der Lauf (sie hat einen Anfang und ein Ende).

Die Arbeitsbereich-VM

Jede Arbeitsbereich-VM ist ein Ubuntu-24.04-Gast, der unter Apples Virtualization.framework läuft — dieselbe Hypervisor-Technologie, die macOS selbst bereitstellt, die Apple Silicon erfordert und nur ARM64-Gäste unterstützt. Die VM bootet mit festen 4 vCPUs und der im Arbeitsbereich eingestellten RAM-Menge (standardmäßig an Ihren Mac angepasst: 4, 6 oder 8 GB), von zwei virtuellen Platten:

• disk.img — die Systemplatte. Beim ersten Start des Arbeitsbereichs wird sie als APFS-Copy-on-Write-Klon des gemeinsamen, signierten Ubuntu-Base-Image erstellt (siehe Installation): Der Klon erscheint sofort und verbraucht keinen neuen Plattenplatz, bis der Gast darauf schreibt. Spätere Starts verwenden denselben Klon wieder, sodass Pakete, die Sie per apt install installieren, Docker-Images, die Sie ziehen, und jede andere Änderung auf Systemebene über Sitzungen hinweg erhalten bleiben.
• home.img — ein privates, sparse ext4-Image, das /home/ubuntu enthält und als zweites virtio-blk-Gerät angebunden ist. Es hat standardmäßig eine scheinbare Größe von 64 GiB, wird aber verzögert allokiert und schrumpft auf dem Host, wenn Dateien im Gast gelöscht werden. Das Home überlebt sogar ein Platte zurücksetzen, weshalb Ihre Repositories, Dotfiles und Shell-Historie ein Zurücksetzen der Systemplatte überdauern. (Ältere Arbeitsbereiche verwenden möglicherweise noch ein Legacy-Home über freigegebene Ordner; die App bietet eine einmalige Aktualisierung an — siehe Arbeitsbereiche.)

Der Gast bindet außerdem kleine virtiofs-Freigaben pro Start ein: eine schreibgeschützte Meta-Freigabe, die die Konfiguration dieses Boots trägt (Umgebungsdateien mit gefälschten Tokens, Proxy-Einstellungen, das Bromure-CA-Zertifikat, Gast-Agenten, MCP-Konfigurationen), und eine schreibbare Outbox, die der Gast verwendet, um Ereignisse an den Host zurückzumelden (seine IP-Adresse, die tmux-Tab-Liste, den Agent-Status). Beide werden bei jedem Boot neu aufgebaut und tragen keinen dauerhaften Zustand. Bis zu 8 Host-Projektordner können zusätzlich in den Gast freigegeben und ins Home-Verzeichnis symlinkiert werden.

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

Bromure Agentic Coding wird aus derselben Codebasis ausgeliefert wie seine Schwester-App Bromure — die Web-Browser-Variante — und die beiden treffen bewusst gegensätzliche Lebenszyklus-Entscheidungen:

Coding-Arbeit benötigt dauerhaften Zustand — geklonte Repos, Paket-Caches, virtualenvs, Shell-Historie — sodass das Zerstören der VM nach jeder Sitzung Agenten nutzlos machen würde. Statt den Zustand der VM zu kontrollieren, kontrolliert Bromure Agentic Coding, was die VM überhaupt jemals halten darf: keine echten Geheimnisse und keinen unvermittelten Weg ins Internet. Flüchtigkeit existiert weiterhin als Notausgang statt als Standard: Platte zurücksetzen klont die Systemplatte erneut aus dem Base-Image, Platten- und Home-Prüfpunkte ermöglichen Rollback, bromure-cli vm run --rm erstellt Docker-artige wegwerfbare Arbeitsbereiche, die beim Stoppen der VM gelöscht werden, und der Kompromittierungs-Ablauf löscht eine kontaminierte Platte und Home, während Ihre Einstellungen und Schlüssel erhalten bleiben.

Die Browser-Sidecar-VM

Ein Stück von Bromure (Web) lebt in Bromure Agentic Coding weiter: der agentische Browser-Bereich. Wenn Sie (oder der Agent) ihn öffnen, erhält der Arbeitsbereich eine zweite, flüchtige VM — einen Alpine + Chromium-Gast, der ins temporäre Verzeichnis geklont und beim Abbau des Bereichs gelöscht wird. Diese Sidecar-VM ist die Ausnahme, die die Regel bestätigt: Der Browsing-Zustand ist standardmäßig wegwerfbar (es sei denn, der Arbeitsbereich aktiviert Bei Websites angemeldet bleiben, was das Chromium-Profil auf einer verschlüsselten Platte pro Arbeitsbereich hält), während die daneben liegende Arbeitsbereich-VM dauerhaft ist. Beide VMs sitzen im selben privaten Netzwerksegment, sodass der Browser einen Dev-Server, den der Agent gerade gestartet hat, über die IP der VM laden kann.

VM-Lebenszyklus: Aus, Ausgesetzt und Läuft

Jeder Arbeitsbereich befindet sich immer in genau einem von drei dauerhaften Zuständen, angezeigt als Pille neben dem Arbeitsbereichsnamen in der Seitenleiste und auf dem VM-Dashboard. (Während eine VM hochfährt, sehen Sie außerdem kurz vorübergehende Zustände — Startet… in der Seitenleiste und eine Boot-Anzeige auf dem Dashboard.)

Das Auswählen des Namens eines Arbeitsbereichs zeigt sein Dashboard für jeden Zustand: Live-Karten für CPU, Arbeitsspeicher, vCPU, Platte und Laufzeit im laufenden Zustand oder die Spezifikation der Maschine und die Konfigurationszusammenfassung im ausgeschalteten oder ausgesetzten Zustand — der Screenshot oben zeigt einen Arbeitsbereich, der noch nie gestartet wurde, weshalb die Platten-Karte noch 0 MB anzeigt (es existiert noch kein Klon). Die Schaltfläche in der oberen rechten Ecke ist Starten für einen ausgeschalteten Arbeitsbereich und Fortsetzen für einen ausgesetzten.

Ein paar Lebenszyklus-Regeln, die man sich zu eigen machen sollte:

• Aussetzen ist ein RAM-Snapshot, keine Speicherdatei. Das Wiederherstellen erfordert, dass die Konfiguration der VM identisch ist, weshalb jeder Arbeitsbereich einen Maschinenbezeichner und eine deterministische MAC-Adresse persistiert. Wenn Sie den Satz freigegebener Ordner ändern, während ein Snapshot existiert, fragt die App, ob der ausgesetzte Zustand verworfen werden soll — der nächste Start bootet kalt, und keine Dateien sind betroffen.
• Ein Snapshot überlebt niemals seine Platte. Das Zurücksetzen oder Löschen der Systemplatte verwirft auch jeglichen gespeicherten RAM-Snapshot und Tab-Zustand, denn frische Platte plus veralteter RAM würden sofort zu Korruption führen.
• Aus bedeutet nicht gelöscht. Ein heruntergefahrener Arbeitsbereich behält seine Systemplatte und Home auf unbestimmte Zeit. Tatsächliche Datenzerstörung ist immer explizit (Platte zurücksetzen, Home löschen, Arbeitsbereich löschen) oder wird durch den Kompromittierungs-Ablauf erzwungen.

Schließaktionen

Was beim Schließen einer Sitzung geschieht, ist eine Wahl pro Arbeitsbereich (Beim Schließen des Fensters im Arbeitsbereich-Editor): Im Hintergrund ausführen (das Fenster lösen, die VM weiterlaufen lassen), Aussetzen, Herunterfahren oder Fragen — der Standard, der jedes Mal mit allen drei Optionen nachfragt. Das Schließen des letzten Terminal-Tabs läuft über dieselbe Wahl. Siehe Sitzungen für den vollständigen Ablauf.

Die Übertragungsgrenze

Die Übertragungsgrenze ist die zentrale Idee des Produkts: sämtliches ausgehende HTTPS vom Gast passiert einen hostseitigen Man-in-the-Middle-(MITM-)Proxy, und jeder Schutz — Geheimhaltung, Zugangsdaten-Scoping, Lieferketten-Scanning, Prompt-Injection-Erkennung, Tracing — wird an diesem einen Punkt erzwungen. Der Agent kann ihn nicht umgehen, weil es auf seiner Seite der Linie nichts Nützliches gibt.

Der Ablauf, von Anfang bis Ende:

1. Der Gast hält nur Fälschungen. Beim Start der Sitzung schreibt der Host absichtlich ungültige Platzhalter-Zugangsdaten in die VM — Umgebungsvariablen wie ANTHROPIC_API_KEY und Konfigurationsdateien wie ~/.git-credentials, ~/.docker/config.json und ~/.kube/config. Fälschungen bewahren die Struktur (sk-ant-api03-brm-…, ghp_…-förmig, brm_…), sodass clientseitige Validatoren sie akzeptieren, und sind deterministisch pro Installation, sodass Tools niemals sehen, wie ein Schlüssel zwischen Sitzungen „rotiert“. Die passenden echten Werte werden in die In-Memory-Austauschtabelle des Proxys auf dem Host geladen, jeweils mit dem Ziel-Host verknüpft, zu dem sie gehören.
2. Das TLS des Gasts terminiert am Proxy. Jede Shell im Gast exportiert HTTPS_PROXY=http://127.0.0.1:8080, einen In-VM-Endpunkt, der über vsock (Port 8443) zum Host-Proxy tunnelt. Der Proxy präsentiert ein gefälschtes Leaf-Zertifikat pro Host, signiert von der Bromure-Root-CA, inspiziert die Anfrage und verschlüsselt sie erneut in Richtung des echten Upstreams.
3. Fälschungen werden erst auf dem Weg nach draußen echt. Der Proxy tauscht jede Fälschung gegen ihren echten Wert — Header-Austausch für API-Schlüssel und Tokens, Body-Austausch für OAuth-Refresh-Abläufe, vollständige SigV4-Neusignierung für AWS (der Gast signiert mit einem gefälschten Geheimnis; der Host entfernt diese Signatur und signiert mit dem echten neu), ssh-agent-Signierung über vsock für SSH. Austausche sind exakt-oder-Subdomain auf den registrierten Host beschränkt, niemals als Teilzeichenkette, sodass Zugangsdaten, die für api.anthropic.com registriert sind, niemals in Richtung einer ähnlich aussehenden Domain injiziert werden.

Die Bromure-Root-CA

Der Proxy kann das TLS des Gasts nur terminieren, 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 Boot über die Meta-Freigabe in den Trust Store jeder VM eingebunden wird. Der private Schlüssel verlässt niemals den Host (er liegt unter ~/Library/Application Support/BromureAC/ca/, nur für den Eigentümer lesbar). Nichts außerhalb Ihrer Bromure-VMs vertraut dieser CA: Sie kann nicht verwendet werden, um den eigenen Verkehr Ihres Macs abzufangen, und das Löschen des Verzeichnisses ca/ erzeugt beim nächsten Start einfach eine frische CA.

Fail-closed von Design her

Das Design ist fail-closed: Sollte Gast-Verkehr jemals den Proxy umgehen — ein Tool, das Proxy-Variablen ignoriert, ein rohes Socket, ein bewusster Umgehungsversuch — sind die einzigen Zugangsdaten, die er präsentieren kann, eine Fälschung, die kein Upstream akzeptiert. AWS gibt InvalidSignatureException zurück; API-Anbieter weisen den Platzhalter-Schlüssel ab. Das Umgehen der Grenze bringt einem Angreifer nichts, denn die Grenze ist nicht der Ort, an dem Geheimnisse geprüft werden — sie ist der einzige Ort, an dem Geheimnisse existieren.

Der Kompromittierungs-Detektor

Die Grenze wacht auch über die entgegengesetzte Richtung des Missbrauchs: Exfiltration. Der Proxy scannt jede ausgehende Anfrage auf einen der registrierten gefälschten Tokens des Arbeitsbereichs. Eine Fälschung hat genau ein legitimes Ziel — den Host, für den sie geprägt wurde — sodass eine Fälschung, die man anderswohin unterwegs beobachtet, die Signatur eines Agenten ist, der versucht, Zugangsdaten zu leaken. Der Proxy verweigert die Anfrage, ohne ein einziges Byte weiterzuleiten, pausiert die VM und alarmiert Sie; der Arbeitsbereich wird als kompromittiert markiert und weigert sich, erneut zu booten, bis seine (mutmaßlich kontaminierte) Platte und Home gelöscht sind. Ihre Einstellungen, Tokens und SSH-Schlüssel bleiben erhalten — und da nur die Fälschung jemals geleakt ist, muss das echte Zugangsdatum niemals rotiert werden. Das vollständige Zugangsdaten-Modell, einschließlich Genehmigungs-Prompts pro Zugangsdatum und TTL-begrenzter Gewährungen, wird in Zugangsdaten & die Übertragungsgrenze behandelt.

Was persistiert und was nicht

Bromure Agentic Coding ist explizit hinsichtlich der Lebensdauer. Alles, was ein Arbeitsbereich besitzt, liegt unter ~/Library/Application Support/BromureAC/profiles/<uuid>/; die Tabelle unten ist die endgültige Karte davon, was was überlebt.

Persistent — überlebt Herunterfahren und App-Neustarts:

Flüchtig — automatisch neu aufgebaut oder zerstört:

Aus dieser Karte ergeben sich zwei Konsequenzen. Erstens ist „das Fenster schließen“ für sich genommen niemals destruktiv — die destruktiven Verben sind alle explizit und bestätigt. Zweitens haben Sie, wenn Sie Wegwerfbarkeit wollen, abgestufte Optionen: einen Prüfpunkt zurückrollen, Platte zurücksetzen (Home überlebt), Home löschen, den Arbeitsbereich löschen oder von vornherein mit einem Wegwerf-Arbeitsbereich über bromure-cli vm run --rm starten.

Hinweis: Freigegebene Host-Ordner sind Projektverzeichnisse auf Ihrem Mac, außerhalb des Bromure-Speichers. Sie werden von keiner Bromure-Aktion jemals gelöscht — einschließlich der Kompromittierungs-Löschung — und der Lösch-Prompt sagt das ausdrücklich.

Host-Gast-Brücken (vsock)

Die interaktive Integration zwischen dem Mac und dem Gast läuft über virtio-Sockets — Punkt-zu-Punkt-Host-zu-Gast-Kanäle, die unabhängig vom Netzwerk der VM existieren. Sie konfigurieren diese nie, aber zu wissen, dass sie existieren, hilft beim Lesen von Traces oder des Kapitels Fehlerbehebung. Jede Brücke lauscht auf einem nummerierten vsock-Port:

Brücken der Arbeitsbereich-VM:

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

Zwischenablage

Es gibt keinen separaten Zwischenablage-Daemon für Arbeitsbereich-Terminals — die Zwischenablage läuft über das Terminal-Protokoll selbst. Kopieren innerhalb des Gasts (eine tmux-Auswahl oder jedes Programm, das OSC 52 ausgibt) landet automatisch in der macOS-Zwischenablage; ⌘C kopiert die hostseitige Terminal-Auswahl; ⌘V fügt mit Bracketed Paste in den Gast ein. Im Browser-Bereich stellen ein Gast-Zwischenablage-Agent plus erfasste ⌘C/⌘V das Kopieren und Einfügen zwischen dem Mac und Chromium bereit.

Dateiübertragung

Dateien bewegen sich auf drei Wegen zwischen dem Mac und einem Arbeitsbereich, alle behandelt in Sitzungen: freigegebene Ordner (virtiofs, der normale Weg für Projektdateien), das Finder-ähnliche Dateibrowser-Fenster (Hinein- und Herausziehen über den vsock-Dateidienst auf Port 5800) und Bild-Einfügen (⌘V mit einem Bild lädt es in den Gast hoch und fügt seinen Pfad ein). Das dedizierte Dateiübertragungs-Protokoll auf Port 5100 gehört zur Browser-Sidecar-VM.

Netzwerk

NAT-Modus (der Standard)

Alle Arbeitsbereich-VMs im NAT-Modus schließen sich an einen einzigen prozessweiten Software-L2-Switch an, gemultiplext auf eine vmnet-Shared/NAT-Schnittstelle. Die Konsequenzen:

• Ein privates Subnetz — standardmäßig 192.168.64.0/24 (Gateway .1, Adressen von .2 bis .254 für 24 Stunden verpachtet). Wenn das eigene LAN Ihres Macs diesen Bereich bereits verwendet, wählt Bromure automatisch ein anderes 192.168.x.0/24.
• Bromure betreibt seinen eigenen DHCP-Server auf diesem Switch (Apples eingebauter kann nur eine einzige Lease pro Schnittstelle verfolgen), und Leases persistieren in dhcp-leases.sqlite auf dem Host.
• Stabile Adressierung — jeder Arbeitsbereich erhält eine deterministische, lokal administrierte MAC-Adresse, persistiert in profile-macs.json, und in Kombination mit persistenten Leases behält ein Arbeitsbereich üblicherweise dieselbe IP über App-Neustarts hinweg (nach bestem Bemühen: solange die Adresse frei bleibt). Die aktuelle IP wird immer im Kopf des VM-Dashboards und in der Symbolleisten-Pille angezeigt.
• VMs können einander erreichen. Jede VM im NAT-Modus — Arbeitsbereich-VMs und Browser-Sidecars gleichermaßen — sitzt von Design her im selben L2-Segment, sodass der Browser-Bereich einen in der Arbeitsbereich-VM laufenden Dev-Server laden kann und zwei Arbeitsbereiche mit den Diensten des jeweils anderen sprechen können. Die Karte „Lauschende Ports“ des Dashboards listet jedes extern erreichbare Gast-Socket als den Endpunkt <VM-IP>:<port> auf, mit dem Sie sich tatsächlich vom Mac aus verbinden würden.
• Isolation von außen. NAT bedeutet, dass die VMs von Ihrem Mac aus erreichbar, aber nicht in Ihrem physischen LAN exponiert sind, und eingehende Verbindungen von anderswoher sind nicht möglich, es sei denn, Sie veröffentlichen einen Dienst explizit (Cloudflare-Quick-Tunnels pro Dienst, über die Karte „Lauschende Ports“).

Die MTU der Gast-NIC ist standardmäßig auf 1280 begrenzt — ein konservativer Wert, der VPN- und Unternehmens-Path-MTU-Umgebungen übersteht — und kann mit defaults write io.bromure.agentic-coding vm.mtu -int <value> erhöht werden.

Denken Sie daran, dass gewöhnlicher IP-Verkehr in diesem Netzwerk nicht der Weg ist, auf dem Zugangsdaten fließen: Gast-HTTPS wird durch den In-VM-Proxy-Endpunkt und über vsock zur Übertragungsgrenze geleitet. Das NAT-Netzwerk trägt alles andere — und alles, was den Proxy umgeht, trägt nur gefälschte Zugangsdaten, was genau die oben beschriebene fail-closed-Eigenschaft ist.

Bridged-Modus (pro Arbeitsbereich)

Ein Arbeitsbereich kann stattdessen Ihrem physischen LAN beitreten: Der Bridged-Modus bindet die VM über vmnet-Bridging an eine gewählte Host-Schnittstelle an, sodass sie als Gerät im lokalen Netzwerk erscheint (nützlich, wenn andere Maschinen die VM direkt erreichen müssen). Ist die gewählte Schnittstelle beim Start nicht verfügbar, fällt die VM auf NAT zurück. Der Netzwerkmodus wird pro Arbeitsbereich im Arbeitsbereich-Editor festgelegt; siehe Arbeitsbereiche.

Sofortstart und Vorwärmung

Zwei verschiedene Mechanismen lassen Sitzungen sofort wirken, und es lohnt sich zu wissen, welcher wo gilt:

• Arbeitsbereich-VMs werden nicht gepoolt. Jeder Arbeitsbereich bootet seine eigene persistente VM direkt. Der erste Start ist schnell, weil die Systemplatte ein sofortiger CoW-Klon statt eines kopierten Image ist; nachfolgende Kaltstarts sind gewöhnliche Linux-Boots (abgedeckt vom animierten Boot-Overlay); und ein ausgesetzter Arbeitsbereich überspringt das Booten vollständig — sein RAM-Snapshot wird wiederhergestellt und die Sitzung setzt an Ort und Stelle wieder ein, mit Terminals und allem, nahezu sofort.
• Das Browser-Sidecar verwendet einen Warm-Pool. Die Engine hält im Hintergrund eine vorgebootete Browser-VM bereit, sodass das Öffnen des agentischen Browser-Bereichs unter 1 Sekunde dauert. Wenn diese VM beansprucht wird, beginnt eine Ersatz-VM sich aufzuwärmen; im Leerlauf wird der Memory-Balloon der Warm-VM aufgeblasen (der Gast behält etwa 512 MB) und die VM nach 30 Sekunden ausgesetzt, um kostengünstig zu bleiben, und dann bei Beanspruchung fortgesetzt und der Balloon entleert (voller Speicher an den Gast zurückgegeben).

Die Unterscheidung folgt direkt aus der Lebenszyklus-Philosophie: Gepoolte VMs ergeben nur Sinn, wenn jede Instanz austauschbar ist, was für wegwerfbare Browser-VMs zutrifft und für persistente, arbeitsbereichsgebundene Maschinen falsch ist.