2026 OpenClaw Agent, bac à sable (sandbox) : image Docker, docker.user, droits de volume, outils absents, OOM/137

Pourquoi, une fois le bac à sable on, c’est : “chez moi c’est là, pas dans l’image”

La vraie cause est la frontière de processus :

1. Racine différente de l’hôte : le bac à sable est une image à part ; ce que vous installez sur l’hôte avec brew n’entre pas dans le PATH du conteneur sans couche ou montage supplémentaire.
2. Le workspace est en bind : 501:20 côté hôte, 1000:1000 dans le conteneur, refus d’écriture ou déni, souvent Permission denied / EROFS.
3. Deuxième périmètre de sécurité : même quand le Gateway a du réseau, DNS, sortant et banc d’outils méritent un cadrage, distinct du SSH sur l’hôte.

Comparé en un tableau : Docker, SSH, sans sandbox

Point d’entrée de config : agents.defaults.sandbox.docker + sandbox-setup.sh

Deux couches : l’implémentation de sandbox (image, runtime) et la provenance de l’image, souvent scripts/sandbox-setup.sh pour pré-construire / tirer l’image. agents.defaults.sandbox.docker.image est l’image de session ; s’ils divergent, on voit manifest not found / pull access denied tandis que l’UI croit le sandbox allumé.

docker.user + montage OPENCLAW_HOME : lire le symptôme, éviter chmod 777 massif

Ordre recommandé :

• Sur l’hôte, vérifier le répertoire workspace monté (propriétaire, groupe) et l’identité réelle du processus Gateway.
• Régler docker.user sur un UID:GID cohérent avec l’écriture sur le volume (selon la doc ; parfois la clé est sous sandbox.docker).
• Si la politique interdit un chown de tout le dépôt, ajuster plutôt un sous-répertoire monté dans le conteneur, pas tout le disque.

Sur Linux et Mac distant, volumes nommés vs bind, étiquettes SELinux (certaines distros) amplifient le « juste dans Compose, faux dans le conteneur ». Lire la première ligne d’erreur I/O des logs Gateway et sandbox, pas des essais au hasard côté modèle.

Quatre questions : outil présent sur l’hôte, absent du bac à sable

1. L’exécutable se trouve-t-il sur le PATH de l’image ? En docker exec, command -v vaut mieux qu’un avis par téléphone.
2. Dépend-il d’une lib ou d’un interprète (Node, Python) absent de l’image ?
3. Fallait-il un bind lecture seule d’un chemin hôte (ex. ~/.cache) ? Préférer le cache intégré à l’image ou une couche partagée, plutôt qu’un découpage ad hoc de l’hôte.
4. Même politique réseau que le Gateway, besoin d’un HTTP(S)_PROXY manquant : les pannes réseau se lisent parfois comme command not found.

OOM et exit 137 : « tué » et « mémoire insuffisante » dans Docker

137 = 128 + 9 (SIGKILL) : souvent le tueur OOM, mais aussi docker kill manuel ou plafond mémoire cgroup. En triage : phase de build (docker build vs docker run) ; builds concurrents sur la VM Docker ; sur un Mac distant, RAM réellement libre et swap, pas seulement la limite d’un conteneur. Même file pour des codes 1/2 avec beaucoup de Cannot allocate memory (mémoire ou disque temporaire), sans boucle infinie de réglages côté modèle.

En cas d’OOM au build, ordre fréquent : réduire le parallélisme (--parallel …), build multi-étapes, augmenter la mémoire de la VM Docker, ou s’appuyer sur un Mac cloud dédié avec plus de mémoire comme base stable (autre nature qu’un laptop où IDE, modèle local et Docker se croisent par chance). Avec stockage partagé, surveiller aussi métadonnées et éclatement de petits fichiers (effet OOM) : volumes séparés ou nettoyage.

Six étapes : d’un état zéro à un passage d’outils fiable en sandbox

1. Valider Docker/Compose et le démarrage de Gateway : triage modèle + doctor.
2. Exécuter le sandbox-setup fourni, construire ou tirer, et conserver le nom et l’ID d’image en accord avec la config.
3. Sur un espace de test, activer le sandbox : une écriture de petit fichier, une lecture d’un gros répertoire, relever toute erreur de permission.
4. Tester A/B sur docker.user et montages : une seule variable à la fois, diff tracé pour pouvoir revenir en arrière.
5. Lancer un build de complexité moyenne en surveillant mémoire hôte et conteneur ; noter l’apparition de 137.
6. Publier le runbook dans le wiki : reproductible minimal, extrait de log, règles pour sandbox coupé ou obligatoire.

{
  "agents": {
    "defaults": {
      "sandbox": { "mode": "docker" },
      "docker": { "user": "1000:1000" }
    }
  }
}
// Souvent imbriqué sous sandbox.docker ; lancer openclaw doctor

Trois points à citer (revue ou fiche capacité)

• 137 et signaux 128+ : consigner docker events / journal moteur, memory pressure hôte — éviter d’identifier une OOM métier avec une OOM de docker build en parallèle.
• Namespace et UID en bind : chown -R 1000:1000 sur un dépôt projet n’est pas le même risque qu’un déménagement de tout le répertoire perso : ticket + point de repli.
• Latence de froid dé du sandbox : grosse image, premier index pip, téléchargements répétés sans couche persistante → chiffrer un premier démarrage en revue de capacité.

Laptop+Docker+grand modèle+Xcode vs cadence d’entreprise

Pic mémoire+IO, cadre d’environnement délicat : production agent voit 137+amplification écriture. Besoin 7j/7 Gateway+Sandbox : cloud Apple Silicon dédié, règles disque/log, période déterminée. MACCOME Mac distant : socle OpenClaw fiable, moins de bataille locale, plus d’outillage produit.