OpenClaw CI sans tête sur Mac cloud Canada M4 2026 : install-cli.sh, --no-onboard, sondes launchd Mac mini hosting

Lorsque les équipes plateforme déplacent OpenClaw vers un Mac distant M4 au Canada, l’erreur classique consiste à copier le playbook bureau : ouvrir le partage d’écran, lancer un openclaw onboard complet, espérer que la Gateway survive après la coupure SSH. Les charges CI et batch exigent un autre contrat — un chemin d’installation headless via install-cli.sh officiel avec --no-onboard, une config pré-injectée et des sondes launchd plutôt que des invites de l’assistant. Ce billet ne répond qu’à une question : comment déployer une CI OpenClaw headless reproductible sur un siège Mac cloud / Mac mini cloud. Il ne rouvre pas le débat tunnel SSH vs Gateway directe (OpenClaw Canada M4 : passerelle SSH, token 18789 et launchd) ni le playbook onboard interactif (Mac distant : install, onboard et LaunchDaemon 24/7). Si le même siège de Mac mini hosting héberge aussi un runner GitHub Actions, séparez utilisateurs Unix et labels launchd selon runners macOS auto-hébergés sur Mac cloud pour éviter les conflits de versions Node et du port 18789.

1. Quand imposer le headless --no-onboard plutôt qu’un onboard interactif

L’openclaw onboard interactif brille sur un Mac avec une vraie session GUI où un opérateur approuve les invites TCC (Accessibilité, Automatisation, Enregistrement d’écran). C’est la bonne première expérience sur un portable de développeur. Ce n’est pas le défaut lorsque la cible est une lane CI Mac cloud accessible uniquement par SSH ou un runner auto-hébergé, et que la configuration est déjà générée par des modèles internes. Continuer à invoquer l’assistant bloque les pipelines et crée des hôtes « flocon » non reconstruisibles depuis Git.

Le contrat headless ressemble à ceci :

• Épingler Node LTS et le semver CLI global openclaw via install-cli.sh.
• Passer --no-onboard et synchroniser le répertoire de config (souvent ~/.openclaw, selon la doc amont) depuis la gestion des secrets.
• Planifier une fenêtre unique de partage d’écran seulement si vos agents exigent encore une automatisation navigateur soumise au TCC ; ensuite, n’opérez que via launchd.

Par rapport à notre note « stabilité Mac distant », cet article livre un runbook CI versionné et des scripts de sonde — pas un manuel opérateur bureau. Si votre équipe tape encore des réponses dans onboard à chaque nouveau siège, vous n’avez pas atteint la maturité headless.

2. Headless install-cli.sh vs onboard complet : comment choisir

Lors du provisionnement d’un nouveau siège Mac mini cloud chez un fournisseur, exécutez d’abord votre pipeline smoke headless. Les équipes qui « onboardent une fois à la main » découvrent souvent des semaines plus tard qu’elles ne peuvent pas restaurer la Gateway en moins d’une heure.

3. Runbook de provisionnement headless : install-cli.sh et injection de config

Les exemples supposent un utilisateur système dédié openclaw-ci, isolé du compte admin VNC. Sur un Mac cloud M4 Canada, épinglez Node en LTS (22.x est une base raisonnable en 2026) et séparez-le des shims nvm du runner — les jobs launchd ne chargent pas les profils shell interactifs.

# SSH en tant qu'openclaw-ci sur le Mac cloud
export OPENCLAW_CONFIG_DIR="$HOME/.openclaw"
curl -fsSL https://example.openclaw.dev/install-cli.sh | bash -s -- --no-onboard

# Restaurer la config depuis les secrets CI — ne jamais committer les tokens
install -d -m 700 "$OPENCLAW_CONFIG_DIR"
echo "$OPENCLAW_CONFIG_JSON" > "$OPENCLAW_CONFIG_DIR/config.json"

# Installer le service launchd Gateway si supporté
openclaw gateway install-daemon
openclaw doctor --non-interactive

Notes opérationnelles qui séparent installs hobby et lanes Mac cloud de production :

1. Idempotence : votre workflow doit tolérer les relances. Un bon script no-op ou converge la version si déjà installé.
2. Verrou semver : enregistrez openclaw --version et la version du schéma config ; les upgrades passent par une fenêtre de changement avec rollback.
3. Disposition disque : gardez les caches npm/pnpm sur un chemin effaçable indépendamment des Derived Data si le même hôte compile aussi des artefacts iOS.
4. Checksum : épinglez le digest du script d’install en production ; un curl | bash nu sans vérification attend un incident supply-chain.

4. Contrôles de santé launchd : triangle processus, port et logs

En mode headless, « la Gateway semble up » signifie souvent qu’on a lancé curl une fois en SSH avec un PATH complet. Les sondes production doivent valider ensemble l’état launchd, l’adresse d’écoute et les mots-clés de log. Exécutez toutes les cinq minutes via cron ou un workflow GHA planifié :

#!/bin/bash
set -euo pipefail
LABEL="ai.openclaw.gateway"
launchctl print "gui/$(id -u)/$LABEL" | grep -q 'state = running'
lsof -nP -iTCP:18789 -sTCP:LISTEN | grep -q openclaw
curl -sf -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  http://127.0.0.1:18789/health | grep -q '"ok":true'
tail -n 50 ~/Library/Logs/openclaw/gateway.log | grep -Ei 'sharp|EADDRINUSE|401' && exit 1 || true

Le plist doit invoquer openclaw avec un chemin absolu et définir des EnvironmentVariables explicites, dont PATH=/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin. launchd ne lit pas votre ~/.zprofile interactif. Ce décalage est la première cause de « ça marche en SSH mais le daemon quitte aussitôt » sur un Mac cloud loué.

Étendez les sondes avec des métriques de durée : suivez la latence p95 de /health et alertez quand les cold starts dépassent le budget timeout de vos workflows. Une Gateway qui répond en quatre secondes en interactif mais trente sous launchd peut encore faire échouer des jobs CI à retries serrés.

5. Matrice de résultats de sonde : vert, jaune et rouge

Traitez le jaune persistant plus de vingt-quatre heures comme bloquant release. La CI headless suppose un comportement Gateway prévisible ; des échecs d’auth ou de latence intermittents se transforment en timeouts batch coûteux sans VNC pour déboguer.

6. Dépannage du module natif sharp sur Mac cloud Apple Silicon

Le graphe de dépendances OpenClaw inclut sharp (bindings libvips). Sur hôtes M4 arm64, des versions majeures Node incohérentes ou des utilisateurs d’install mixtes produisent Cannot find module '../build/Release/sharp.node' ou un mismatch d’architecture à l’exécution. La CI headless ne doit pas découvrir cela au premier job raté — intégrez la validation sharp dans des golden images ou hooks post-install.

6.1 Modes d’échec courants et correctifs

• Mismatch utilisateur : root a installé le CLI global tandis que openclaw-ci exécute le daemon — réinstallez sharp ou le CLI en tant qu’utilisateur service.
• Upgrade Node sans rebuild : après bump Node, lancez npm rebuild sharp ou réinstallez le paquet CLI openclaw.
• Mix Rosetta : plist et CLI doivent être arm64 ; file $(which node) doit rapporter arm64.
• Cache offline : sur hôtes Mac mini cloud à bande passante limitée, préchargez les binaires sharp pour éviter GitHub releases à chaque job CI.
• Multiples gestionnaires Node : évitez Homebrew Node pour le daemon et nvm en shell interactif — choisissez une histoire et encodez-la dans le plist.

node -p "process.arch + ' ' + process.version"
npm ls sharp --global 2>/dev/null || true
npm rebuild sharp --foreground-scripts
openclaw doctor 2>&1 | tee /tmp/openclaw-doctor.log
grep -i sharp /tmp/openclaw-doctor.log && exit 1 || echo "sharp OK"

Si doctor signale encore sharp, alignez Node et canaux d’install CLI depuis le même artefact install-cli.sh avant de chasser des bugs applicatifs. Mélanger Homebrew Node avec un CLI npm global sans fix PATH plist est l’arête sharp la plus fréquente sur les tickets Mac mini hosting.

7. Frontières Gateway 18789 et rotation de token en CI

Les pipelines headless doivent appeler la Gateway locale sur 127.0.0.1:18789 avec un bearer token — n’exposez jamais le port sur une interface publique. Stockez les tokens dans les secrets CI (par ex. OPENCLAW_GATEWAY_TOKEN). Flux de rotation : écrire le nouveau token dans la config, recharger le daemon, valider sondes vertes, puis révoquer l’ancien secret. L’accès loopback garde une latence minimale quand runner et Gateway partagent un Mac cloud ; les appels cross-host renvoient à la note passerelle SSH liée plus haut.

Les workflows doivent avoir des timeouts explicites et des retries limités. Un cold start peut prendre dix à trente secondes après reboot ; un échec de sonde doit déclencher launchctl kickstart une fois avant toute réinstall destructive. Documentez ce comportement pour que l’on-call n’efface pas une config saine lors de tempêtes de boot après correctifs macOS.

8. Baseline sécurité pour OpenClaw headless sur sièges Mac hébergés

• Utilisateur dédié : openclaw-ci sans droits admin ni login VNC.
• Secrets : config et tokens uniquement depuis votre vault ; FileVault activé sur le volume.
• Réseau : SSH ou Tailscale entrant seulement ; ne pas diffuser 18789 sur le LAN.
• Supply chain : vérifiez les checksums du script d’install ; bloquez pipe-to-bash non audité en production.
• Audit : conservez gateway.log quatorze jours ; envoyez mots-clés 401 et sharp vers votre stack logs.
• Rayon d’explosion : le profil tools agent doit suivre le moindre privilège ; les PR fork non fiables ne doivent pas atteindre les hôtes Gateway production.

L’automatisation headless accélère la livraison ; elle supprime aussi la pause humaine où quelqu’un remarquerait une URL d’install suspecte. Traitez l’URL et le checksum du script d’install avec la même rigueur que les certificats TLS production.

9. Brancher OpenClaw headless dans GHA ou CI interne

Une fois les sondes Gateway vertes, exposez OpenClaw aux pipelines via des étapes gardées :

1. Exportez OPENCLAW_GATEWAY_TOKEN depuis GitHub Environments avec reviewers requis pour la production.
2. Exécutez les jobs agent sur runs-on: [self-hosted, macos-m4-canada, openclaw] avec des labels distincts des jobs signature ou archive.
3. Preflight avec la même sonde shell que cron ; échec rapide avant étapes LLM ou navigateur coûteuses.
4. Capturez la sortie openclaw doctor en artefact workflow en cas d’échec pour revue asynchrone.

Planification mémoire : sur un siège Mac mini cloud 24 Go, mettez en pause les batches agent OpenClaw quand la pression mémoire unifiée dépasse quatre-vingts pour cent si le même hôte doit finir un xcodebuild archive la même nuit. Les alertes de profondeur de file évitent d’accuser « GitHub lent » quand l’hôte est simplement sursouscrit.

10. Checklist première semaine sur un siège M4 Canada dédié

1. Choisir un plan Mac mini hosting (24 Go RAM et SSD 512 Go minimum pour CI + Gateway combinés).
2. Créer openclaw-ci et valider les smoke tests install-cli.sh --no-onboard.
3. Injecter config et token ; s’assurer que openclaw doctor --non-interactive est clean.
4. Installer launchd et déployer sondes vert/jaune/rouge avec paging.
5. Prévalider sharp ; verrouiller versions Node et CLI dans le runbook.
6. Si un runner GHA partage l’hôte, vérifier utilisateurs séparés et absence de conflits de ports.
7. Documenter la reconstruction : un nouveau siège Mac cloud doit atteindre un comportement Gateway identique en trente minutes.

11. FAQ

Faut-il encore VNC après --no-onboard ?

Si les agents exigent automatisation navigateur ou permissions TCC, planifiez une session graphique unique. Les charges purement CLI ou API Gateway peuvent tourner sans VNC indéfiniment une fois launchd stable.

install-cli.sh vs install.sh complet ?

Utilisez install-cli.sh quand la CI n’a besoin que du CLI plus Gateway. Les installateurs complets avec apps barre de menus conviennent mal aux déploiements headless répétés de runners.

La sonde renvoie 401 mais le processus tourne ?

Souvent dérive de rotation token ou workflows envoyant encore un ancien secret. Alignez la config disque avec l’en-tête Authorization ; vérifiez les proxys injectant des tokens périmés.

sharp échoue sous launchd mais marche en SSH ?

Presque toujours des différences PATH ou environnement utilisateur. Comparez côte à côte les blocs environment de launchctl print et la sortie env interactive.

Puis-je exécuter OpenClaw Gateway dans Docker sur macOS ?

Docker sur Mac ne remplace pas les exigences TCC et automatisation GUI natives. Exécutez Gateway sous launchd natif ; les conteneurs conviennent aux outils périphériques seulement.

Comment planifier OpenClaw aux côtés de GitHub Actions sur un hôte ?

Décalez les batches agent des pics archive ; mettez en pause les agents au-delà de quatre-vingts pour cent de pression mémoire. Voir labels et concurrence dans l’article runner auto-hébergé.

Un nœud Hashvps Canada convient-il à OpenClaw headless ?

Oui lorsque vous avez besoin d’IPv4 dédié, M4 bare-metal et SSH persistant. Confirmez que le tier disque accueille caches npm et logs gateway rotés avant engagement.

Quelle est la procédure standard de upgrade CLI ?

Fenêtre maintenance : launchctl bootout, converger version via install-cli, npm rebuild sharp, doctor, sondes vertes, puis restaurer le trafic.