Docker Sandbox

Vorschau: Claude Code, Codex, Grok Build und Kimi Code-Sitzungen sind verfügbar Auf Linux und macOS. Die lokale Ausführung bleibt verfügbar und bleibt die Standardeinstellung. Auditierte Zyklen behalten während dieser Vorschau ihre bestehende lokale Laufzeit.

AirCode Ø behält seine Steuerungsebene auf Ihrem Computer oder Server. Wenn Sie Docker Sandbox wählen, wird nur diese direkte Agent-Sitzung in einen kurzlebigen Arbeitercontainer verschoben. Dies ist für die Entwicklung mit Umgangsberechtigungen konzipiert: Der Agent kann an das ausgewählte klonierte Projekt schreiben, ohne den Rest Ihres Home-Verzeichnisses oder die Docker -Steckdose zu erhalten.

Web / Desktop / mobile
          ↓
AirCode Ø API + auth + tunnel (host)
          ↓
Local tmux / Windows ConPTY  OR  one Docker worker per session

Dies ist eine Ausführungsoption, nicht eine zweite Containerisierte AirCode Ø -Installation. Authentifizierung, Sitzungsstatus, Benachrichtigungen, WebSockets, Remote Access und die UI bleiben auf dem Host.

Wo die Auswahl angezeigt wird

• Web: Neue Sitzung → Ausführungsumgebung.
• Desktop: der gleiche Launcher, weil Desktop die Web-Workbench einbettet.
• Native mobile: Neue Sitzung → Ausführungsumgebung, persistent per gespeicherte Serververbindung.
• API: POST /api/sessions akzeptiert executionMode: "local" | "docker".

Die Sitzungsdetails zeigen die effektive Umgebung und das Bild. Der Server validiert den Daemon, das Bild und den Motor; er fällt niemals leise auf Local zurück.

Verwenden Sie die Quellvorsicht heute

Docker Engine oder Docker Desktop muss ausgeführt werden:

git clone https://github.com/spartaquant/aircode.git
cd aircode
npm run docker:runtime:build
npm run docker:runtime:check
npm run docker:session:smoke

Neustart AirCode Ø, eine Sitzung erstellen, und wählen Sie dann Docker Sandbox Unter Ausführung Umwelt. Wenn Docker oder das Bild nicht verfügbar ist, zeigt der Launcher den genauen Grund an und fällt nicht auf Local zurück.

Nach diesem ersten Build hält das Checkout das Bild im Schritt mit seinem Host: Wenn ein Update neuer pins Claude Code, Codex, Grok Build oder Kimi Code Versionen oder ermöglicht ein anderes Paket CLI, AirCode Ø Wiederaufbau aircode-session-runtime:local Im Hintergrund und neu Docker Die Sitzungen verwenden die aktuellen Versionen und die Engine-Liste.

Während der Vorschau ist das Bildtag aircode-session-runtime:local. Markierte Produktversionen erstellen und überprüfen sowohl linux/amd64 als auch linux/arm64, veröffentlichen ein unveränderliches Docker Hub-Versionstag und speichern seine Digest in dem unterzeichneten AirCode Ø -Versionsmanifest. Der separate manuelle Docker -Workflow veröffentlicht nur den preview -Kanal. Die öffentlichen Repository- und Release-Auskünfte werden konfiguriert, aber ein Tag wird erst nach seiner ersten erfolgreichen Veröffentlichung ziehbar.

Wenn ein öffentliches Tag verfügbar ist, ist kein AirCode Ø -Wiederherstellung erforderlich:

AIRCODE_DOCKER_IMAGE=aircodezero/session-runtime:<version> aircode

Was der Arbeitnehmer zugreifen kann

AirCode Ø kopiert das Repository nicht in das Bild. Es montiert das bereits klonierte Projekt auf dem gleichen absoluten Pfad innerhalb des Arbeiters. Edits landen daher im tatsächlichen Checkout und bleiben nach dem Verlassen des Container.

Es nicht erhalten Sie Ihr komplettes Home-Verzeichnis, die Docker -Socket oder Host Linux Fähigkeiten. Das Root-Dateisystem ist nur lesbar, und AirCode Ø verwendet PID, Speicher und CPU -Steuerelemente.

AirCode Ø’s Loopback API bleibt privat. Ein stabiler, fähigkeitsgeschützter Steuerungsport akzeptiert nur die eigenen Fertigstellungshocks des Arbeitnehmers, auch nach dem Neustart des Desktop-Servers.

Das Engine-Profil enthält Anmeldeinformationen und wird im Vorschau mit dem Leser geteilt. Containerisolation schützt unabhängige Host-Dateien; es macht nicht die Motor-Auskünfte unlesbar für die Engine oder für bösartige Code, der als der gleiche Container-Benutzer ausgeführt wird.

Was passiert während einer Sitzung

1. Der Client liest den Runtime-Katalog vom Host.
2. Der Host validiert Docker, den Bildvertrag und die ausgewählte Engine.
3. AirCode Ø erstellt einen gekennzeichneten Arbeiter und einen Funktionsumfang-Callback URL.
4. Der Arbeiter startet tmux im montierten Projekt.
5. Das bestehende Terminal WebSocket treibt diese tmux -Sitzung über Docker.
6. Normal-Ausgang oder Kill-Sitzung entfernt den Arbeitnehmer, lässt aber Projektänderungen und Motorverlauf auf dem Host.
7. Wenn AirCode Ø neu gestartet wird, wird der Arbeiter wiederentdeckt und die Fertigstellung wiederhergestellt Anrufe zurück.

VPN und Dev-Server-Traffic

Container-Egress folgt normalerweise dem Hostrouting von Docker und den Regeln von NAT . Ein Host VPN trägt es nur, wenn dieser VPN Brückenverkehr Docker enthält. Der verwaltete Hetzner/AirCode Ø -Tunnel ist für den Eingangszugang zum AirCode Ø -Steuerplan bestimmt; er führt nicht automatisch den Arbeiter-Exkurs.

Kein Workers Port wurde noch veröffentlicht. Authentifizierte Dev-Server-Vorleitung über AirCode Ø und die Hetzner-Route ist der nächste Netzwerk-Aufstieg. Lokale AirCode Ø -Sitzungen und vorhandener Remote-Zugriff bleiben unverändert.

Vorschau Grenzen

• Claude Code, Codex, Grok Build und Kimi Code sind verpackt und verfügbar für gewöhnliche Docker Sitzungen. Fehlende, unlesbare oder veraltete Versionen noch fehlgeschlossen vor dem Start.
• Direct Sessions sind abgedeckt. Auditierte Zyklen verwenden weiterhin die lokale Ausführung.
• Linux und macOS Hosts sind gezielt. Windows Desktop behält native ConPTY Local -Sitzungen; Docker -Path-Semantik ist dort noch nicht zertifiziert.
• Host-Browser-Funktionen und externe Token-Optimierungs-Einpackungen sind nicht wurde noch in Arbeiter injiziert.

Konfiguration

Halten Sie den Callback-Port stabil, während die Mitarbeiter laufen. Siehe Troubleshooting für die Laufzeit-Fehlercodes.

Der Docker Daemon bleibt eine vertrauenswürdige Host-Komponente. Wer diesen Daemon kontrolliert, kann die Containerisolation umgehen.