2026 OpenClaw sur Mac distant : sortie fixe WireGuard, domaines modèle et outils, passerelle 18789 et synthèses CI fusionnées

Sur un Mac distant loué ou géré, traitez la passerelle OpenClaw comme un service exposé indirectement : un compte macOS dédié (ou rôle technique) possède les fichiers de configuration et les jobs launchd, tandis que l'administration SSH reste sur un chemin maîtrisé. Le trafic vers les API de modèles et les outils autorisés ne doit sortir que via l'interface WireGuard lorsque votre politique impose une IP fixe ; le reste du trafic (Git interne, artefacts CI) peut rester sur le chemin direct si vous appliquez un tunnel partagé cohérent avec votre segment réseau.

Documentez trois listes distinctes : hôtes d'administration, hôtes de build, hôtes « modèle + outils OpenClaw ». Cette séparation évite d'étendre AllowedIPs à tout Internet et réduit la surface en cas de compromission d'une compétence.

1. Plan de contrôle séparé : les webhooks CI arrivent sur un reverse proxy, un tunnel SSH ou une terminaison TLS qui ne publie que vers 127.0.0.1, jamais directement sur le LAN brut.
2. Refus par défaut en sortie : n'autorisez que le résolveur DNS choisi, NTP, les FQDN des fournisseurs de modèles, les registres npm/pip explicitement requis par vos skills, et les endpoints CI documentés.
3. Piste d'audit : openclaw.json, plists et fichiers d'environnement en chmod 600 ; rotation des jetons à chaque rotation d'équipe ou de fork sensible.

En 2026, le fil officiel recommande une version de Node supportée : Node 22 LTS ou Node 24. Des versions antérieures peuvent masquer des erreurs de parsing ou de dépendances jusqu'en production. Après installation de Node (fnm, nvm ou paquet Apple Silicon), exécutez le one-liner curl publié sur la documentation OpenClaw (l'URL exacte évolue avec les releases), puis enregistrez le démon avec openclaw onboard --install-daemon.

node -v   # attendu : v22.x ou v24.x

# Exécuter le script curl indiqué sur la page d'installation officielle OpenClaw

openclaw onboard --install-daemon
openclaw doctor
openclaw gateway status --deep || true

Pour plusieurs passerelles (préproduction / production), exportez OPENCLAW_HOME ou OPENCLAW_CONFIG_HOME avant chaque onboard afin que les labels launchd et les répertoires de données ne se marchent pas dessus. Tenez un tableau simple : nom d'instance, chemin home, port local si vous dérivez du 18789 par override documenté.

• Le binaire global openclaw correspond à l'utilisateur propriétaire des jobs launchd.
• openclaw doctor signale DNS, espace disque et joignabilité fournisseur depuis le même environnement que le démon (pas seulement depuis votre shell).
• Le port 18789 est libre ou explicitement redirigé ; après mise à jour, aucun double écouteur zombie.

Réduisez AllowedIPs aux préfixes réellement utilisés par votre fournisseur plutôt que 0.0.0.0/0, sauf obligation compliance d'un tunnel complet. Configurez le DNS split : les noms liés aux modèles résolvent via le résolveur annoncé dans le tunnel, tandis que le Git d'entreprise ou le registre d'artefacts reste sur le résolveur par défaut pour éviter d'ajouter de la latence inutile aux clones CI.

wg-quick up wg0
wg show
scutil --dns | head -n 80

curl -4sv --max-time 15 https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" -o /dev/null

Après chaque redémarrage de wg-quick, vérifiez l'âge de la poignée de main (wg show) et enchaînez avec un curl court vers l'endpoint modèle : c'est le même enchaînement que votre sonde doctor devrait refléter.

Liez le service HTTP de la passerelle à 127.0.0.1:18789 et poussez TLS ou l'authentification mutualisée au bord (Caddy, nginx, ou tunnel SSH depuis votre orchestrateur). Le jeton entrant des webhooks doit vivre dans un fichier EnvironmentVariables de la plist ou dans le trousseau, jamais dans un dépôt. Pour la liste blanche sortante, reprenez la taxonomie des hôtes décrite dans le guide de durcissement passerelle : API modèle, éventuels hôtes d'embeddings, registre npm si le pipeline de skills en a besoin, et rien d'autre par défaut.

export OPENCLAW_GATEWAY_TOKEN="$(openssl rand -hex 32)"
launchctl print gui/$(id -u)/com.openclaw.gateway 2>/dev/null | head

curl -sS -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  http://127.0.0.1:18789/health || curl -sS http://127.0.0.1:18789/

Si vous exposez des routes outil (grep HTTP, fetch d'artefacts), vérifiez que chaque domaine figure dans la matrice approuvée côté pare-feu et dans la documentation interne ; les deux copies doivent rester synchrones après chaque mise à jour de fournisseur.

Considérez les micro-coupures WireGuard comme normales sur un hébergeur distant. Après wg-quick down / up, redémarrez le démon OpenClaw pour aligner caches DNS et états HTTP internes. Une plist auxiliaire peut lancer toutes les 60 secondes un curl vers /health ; deux échecs consécutifs déclenchent une alerte (email, Slack, ou métrique Prometheus si vous en exportez).

• Journaliser sur une même ligne l'âge de poignée de main WG et le dernier HEAD réussi vers l'API modèle pour le triage.
• Utiliser ThrottleInterval dans launchd pour éviter les spirales de redémarrage rapides.
• Conserver une archive « dernier état sain » de openclaw.json avant toute modification de routes ; coupler avec les flux de retour arrière décrits dans compétences, rollback et doctor.

Une matrice CI ne doit pas générer vingt notifications pour vingt cellules. Agrégez les queues d'erreurs : extrayez les dernières lignes stderr des étapes en échec, limitez la charge utile (viser environ quatre kilo-octets), dédupliquez par sort -u, puis envoyez un unique POST JSON avec job_id, commit_sha et summary_text. Réutilisez la même échelle de backoff 2 / 4 / 8 secondes que pour les hooks GitOps afin de laisser le tunnel refroidir avant de saturer la passerelle.

FAIL_LINES=$(grep -hE 'error|fatal|ÉCHEC' "$CI_LOG_DIR"/*.log 2>/dev/null | tail -n 40 | sort -u)
curl -fsS -X POST "https://bord.example/v1/webhooks/ci" \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --arg t "$FAIL_LINES" --arg j "$CI_JOB_ID" --arg c "${CI_COMMIT_SHA:-}" \
      '{summary_text:$t,job_id:$j,commit_sha:$c}')"

Côté réception, conservez une clé d'idempotence dérivée du couple pipeline + SHA pour éviter les doublons lors des relances manuelles du job.

Poignée de main OK mais TLS vers le fournisseur échoue : souvent décalage d'horloge ou magasin de confiance incomplet pour l'utilisateur du démon — relancez openclaw doctor sous ce compte.

Réussite dans Terminal, échec sous launchd : comparez printenv avec les EnvironmentVariables de la plist ; OPENCLAW_HOME manquant est la cause la plus fréquente.

Rafales de HTTP 401 après rotation de secret : mettez à jour en même temps l'injection d'en-tête côté proxy et le secret côté passerelle, puis un seul redémarrage du démon.

Livrable minimal : WireGuard pour une sortie prévisible, DNS split, passerelle en boucle locale 18789, webhooks protégés par jeton, texte d'échec CI fusionné. Lorsque la gestion DIY devient coûteuse, les pages tarifs et achat MacPull restent accessibles sans compte ; les pools Mac Mini M4 distants réduisent la friction réseau car la charge NIC reste colocalisée avec l'exécuteur. Le centre d'aide et l'index du blog complètent cette page, lisible entièrement sans connexion.