OpenClaw 2026.3.x charge sous Docker des capacités optionnelles avec un schéma plus strict, des frontières de sandbox explicites et des plugins qui peuvent désormais exposer des surfaces routées en HTTP plutôt que de simples aides en stdio. Les régressions typiques : ancienne forme de setupCommand, OPENCLAW_SANDBOX implicite, routes encore pointées vers des chemins d’avant migration, ou diff Compose qui mélange secrets et profils. Ce runbook ordonne le travail ainsi : validate → bascule d’environnement → setupCommand → routes HTTP → doctor. Pour les permissions minimales et la chaîne onboard → doctor → fix sur les mêmes fichiers, reportez-vous à
OpenClaw 2026 : configuration minimale, ClawHub, onboard et doctor.
1. Toujours exécuter config validate avant de changer d’image
Validez openclaw.json (et les fragments montés par Compose) avec les mêmes chemins que ceux vus par le conteneur avant de promouvoir une nouvelle étiquette d’image. Montez secrets et includes comme en production ; valider un fichier plat local masque des clés présentes seulement en CI. Faites échouer le pipeline sur un code non nul, joignez le rapport machine à la demande de changement, puis montez le tag. Séparez les travaux : une PR pour la JSON, une autre pour l’image — les retours arrière restent lisibles si le symptôme n’apparaît qu’au runtime.
2. Rendre OPENCLAW_SANDBOX un interrupteur explicite dans Compose et la CI
Définissez OPENCLAW_SANDBOX=true|false explicitement dans chaque profil — surcharges de développement, Compose de préproduction, piles de production et matrices GitHub Actions ou Buildkite — afin que les portables, les jobs planifiés et les shells docker compose run ponctuels s’accordent. Les valeurs implicites produisent le classique « ça passe en local, ça casse en CI » lorsque les plugins perdent la visibilité disque attendue sous le chemin plus strict. Si vous devez assouplir le sandbox pour une fenêtre de débogage étroite, encapsulez l’exception dans un profil Compose nommé ou un workflow de branche afin qu’elle ne reste pas sur main sans surveillance.
3. Normaliser setupCommand pour des hooks de cycle de vie déterministes
Préférez des entrées setupCommand structurées avec un répertoire de travail fixe et un shell non interactif ; supprimez les enchaînements cd qui dépendent de la disposition de l’image, dédupliquez les hooks et déplacez les installations de paquets vers la construction d’image lorsque c’est possible. Un script unique avec set -euo pipefail et une ligne de journal semver limite les à-coups des health checks qui relanceraient le setup de façon imprévisible entre 2026.2.x et 2026.3.x.
4. Plugins HTTP : migrer les chemins, puis répéter Streamable HTTP
Lorsqu’un plugin passe en HTTP, modifiez manifeste, préfixe Gateway et retrait de chemin du reverse-proxy dans la même PR. Après déploiement, curl depuis le réseau des conteneurs puis depuis un pair du tailnet pour séparer bind et ACL. Comparez codes et TLS à chaque saut. Les timeouts Streamable ou ENOENT viennent souvent d’un PATH ou d’un répertoire de travail différent entre stdio et HTTP ; répétez la même invocation sur les deux transports. Pour le détail transport et délais, voir
OpenClaw et MCP : stdio, Streamable HTTP, délais et tutoriel ENOENT.
5. Triage piloté par doctor : réduire l’espace de recherche dans l’ordre
N’exécutez doctor sur la nouvelle image qu’après une validation réussie ; sinon vous perdez du temps sur des fantômes réseau. Parcourez la même liste : volumes, collisions de ports avec les sidecars, plugins versus table de routes, puis DNS, TLS d’entreprise et proxys. Fixez un scénario reproductible (mêmes variables et montages) ; toute dérive CI versus poste doit être un diff explicite. Archivez la sortie dans le ticket ; si doctor signale du HTTP, corrigez routes et préfixes, relancez doctor, puis seulement montez les journaux Gateway.
- L’UID/GID du volume correspond-il à l’utilisateur du conteneur ?
OPENCLAW_SANDBOXest-il identique entre shell interactif et CI ?- Les entrées legacy stdio des plugins ont-elles été retirées pour éviter les routes HTTP dupliquées ?
6. Mac distant haute mémoire : rebuild isolé à côté de la CI
Déportez les recompilations lourdes vers un second Mac très doté en RAM : clone propre, même majeure de Node qu’en production, lockfile, puis les mêmes validate et doctor que sous Docker. Isolez ce nœud du pool auto-hébergé par défaut — un runner qui efface souvent node_modules rend les builds erratiques et fausse le diagnostic OpenClaw. Fenêtres de maintenance ou labels opt-in évitent que les rebuilds en rafale coïncident avec le pic de PR ; purgez DerivedData et temporaires au même rythme que la CI. Pour files d’attente, parallélisme et caches multi-dépôts, croisez ce runbook avec
2026 — Pool CI Mac en entreprise : parallélisme multi-dépôts, cache, disque — cloud ou auto-hébergé ?
et, pour Bazel, Gradle et jobs mixtes sur NVMe,
2026 — Pool CI Mac entreprise : caches de build distants Bazel et Gradle, multi-jobs et xcodebuild en parallèle — partitions repository_cache et disk_cache sur NVMe, cache distant en lecture seule et plafonds de concurrence : FAQ opérationnelle.
Pourquoi une classe Mac mini reste l’ancrage de ce découplage
Les validations de configuration et les drapeaux de sandbox attrapent tôt les erreurs de fichier ; les rebuilds natifs et les caches volumineux profitent encore de la bande passante mémoire Apple Silicon et de la pile Unix de macOS, avec Gatekeeper, SIP et FileVault pour les hôtes sans clavier. Des Mac mini au profil sobre consomment très peu au repos, restent silencieux en service continu et servent de nœud de débordement pratique à côté de passerelles Docker. Si vous voulez de la capacité haute RAM dédiée sans les aléas d’un portable qui se met en veille, ouvrez la page d’accueil Macstripe et dimensionnez un Mac mini M4 pour que vos fenêtres de recompilation cessent de rivaliser avec la file CI — c’est le bon moment pour aligner région, latence et observabilité sur du matériel entièrement vôtre.
