2026 OpenClaw Agent Sandbox: Docker-Image, docker.user & Volume-Rechte, fehlende Tools & OOM/Exit-137-Triage

Warum lokal vorhanden im Container plötzlich „we“ ist

Die Ursache liegt in der Prozessgrenze:

1. Getrenntes Root-Dateisystem: die Sandbox nutzt ein eigenes Image. Was Sie auf dem Host brew installen, erscheint im Sandbox-PATH nicht ohne Image oder Zusatzmounts.
2. Arbeitsbereich per Bind ist der Host-Ordner 501:20, läuft im Container 1000:1000, folgen häufig Permission denied bzw. EROFS.
3. Weiteres Sicherheitssegment: Auch mit Gateway-Netz müssen DNS, Egress und Toolset in der Sandbox gezielt designt werden; das ist kein reines „per SSH auf dem Host“.

Einblick: Docker-Sandbox, SSH, ohne Sandbox

Konfiguration: agents.defaults.sandbox.docker und sandbox-setup.sh

Es zählt zweierlei: welches Sandbox-Backend (Image/Runtime) und woher das Image kommt. scripts/sandbox-setup.sh baut oder zieht, damit docker auf dem Host das Image erkennt. agents.defaults.sandbox.docker.image nennt das für die Sitzung laufende Image. Unterschiede: Gateway meldet „Sandbox an“, docker run dagegen manifest not found / pull access denied.

docker.user und OPENCLAW_HOME-Mount: an Symptomen, nicht an wildem chmod 777 drehen

Reihenfolge:

• Prüfen, welches UID:GID für den Workspace-Mount gilt und unter welcher Identität Gateway tatsächlich läuft.
• docker.user in der Konfiguration dazu passend setzen (Dokumentation, ggf. unter sandbox.docker).
• Wenn firmenweit kein chown fürs komplette Repo erlaubt, lieber einen Unterordner für den Mount wählen.

Auf Linux und entfernten Macs verstärken Named/Bind, SELinux „sieht in Compose richtig aus“. Erste I/O-Fehlzeile aus den Gateway-/Sandbox-Logs, nicht Raten im Chat-Modell.

Vier Fragen: Befehl am Host, fehlt in der Sandbox

1. Liegt der Pfad in einer PATH-Bereichsspalte des Images? docker exec + command -v statt Anekdoten.
2. Braucht es eine fehlende Bibliothek/Interpreter-Minor-Version?
3. Blockiert der Betrieb, wenn ~/.cache nicht read-only angebunden ist? Dann besser Cache ins Image, nicht beliebig vom Host einschleusen.
4. Gehören Proxy-Richtlinien? Fehlendes HTTP(S)_PROXY wirkt häufig wie command not found.

OOM und exit 137 in Docker

137 = 128 + 9 (SIGKILL) fördert oft den OOM-Killer, doch docker kill oder cgroup-Limit sind möglich. Triage: docker build vs docker run; parallele Builds gegen die Docker-VM; auf entferntem Mac freier physikalischer Speicher, nicht nur Containerlimit. Auch: Exit 1/2 mit vielen Cannot allocate memory zu temp. Speicher/Heap zählen.

Mitigation bei Build-OOM: Parallelität senken, Multi-Stage, Docker-VM, dedizierte Remote-Mac-Instanz mit größerem Speicher als stabile Basis – ein anderes Ereignis als zufällig reichender Laptop-Stack. Bei geteiltem Storage: Inode, kleine Datei-Stürme, die wie OOM wirken.

Sechs Schritte: stabilen Sandbox-Tool-Lauf

1. Docker/Compose und Gateway gesund; näher Gateway/doctor.
2. sandbox-setup für Image; Image-Name+ID zur Konfig passend.
3. Test-Workspace, klein schreiben, großen Baum lesen, Rechte sammeln.
4. A/B: nur eine Sache ändern (docker.user oder Mount) mit sauberer Diff-History.
5. mittelschweren Build, Host- und Container-Speicher beobachten, 137 dokumentieren.
6. Run ins Wiki: Minimalrepro, Log, Regeln wann Sandbox nötig/optional.

{
  "agents": {
    "defaults": {
      "sandbox": { "mode": "docker" },
      "docker": { "user": "1000:1000" }
    }
  }
}
// Praxis: ggf. unter sandbox.docker. openclaw doctor / Upstream

Drei Einträge für Review/ Kapazität

• Bei 137: docker events / Enginelog, Host-memory pressure mitschreiben.
• Bind: chown -R 1000:1000 auf ein Verzeichnis vs. komplettem Home: Tickets und Rollback.
• Schwere Images, Kaltstart, wiederholter Download: Erst-Startdauer in Kapazitätsnotizen festhalten.

Warum Laptop + Docker + großes Modell + Xcode oft nicht den Enterprise-Sandbox-Takt hält

Typischer Engpass: gleichzeitig Speicher und I/O plus mangelnde, reproduzierbare Grenze. Teams mit 7×24 Gateway+Sandbox profitieren von dedizierter Apple-Silicon-Cloud, klarer Log-/Disk-Policy, planbarer Mietdauer. MACCOME Remote-Mac-Cloud ist ein passendes dauerhaftes OpenClaw-Fundament. Für EU-Kund:innen: Bei Hosting- und Auftragsverarbeitungsverträgen AV-Vertrag, Speicherort und TOMs vor Vertragsabschluss klarstellen; das ergänzt die technische Runbook-Arbeit.