Comment installer OpenClaw en toute sécurité sur macOS ?

Pourquoi une installation hâtive d'OpenClaw est risquée

• Autostart caché via launchd. Un service glissé dans les LaunchAgents peut redémarrer en douce et survivre aux redémarrages. C'est une technique de persistance bien connue et documentée par MITRE ATT&CK, techniques T1569.001 et T1543.001 (MITRE ATT&CK).
• Exfiltration réseau si le bac à sable n'est pas isolé. Un outil trop bavard peut envoyer des métadonnées, journaux et contenus hors de votre réseau. Dans une démo, on s'en rend rarement compte, mais l'empreinte réseau demeure.
• Exécution hors bac à sable. Les agents qui obtiennent trop de permissions se mettent à opérer hors de l'isolement prévu, ce qui recoupe le risque OWASP LLM Top 10 2025 LLM08:2025, appelé Excessive Agency, soit une autonomie trop large avec des privilèges mal bornés (OWASP LLM Top 10 2025), ce qui recoupe exactement le virage que je documente dans la partie 3 de cette même série, sur le virage MCP.
• Accès disque excessif. macOS protège l'accès complet au disque via TCC et, par défaut, Terminal n'a pas Full Disk Access. Si vous court-circuitez ces garde-fous, vous élargissez la surface d'attaque sans raison valable (Apple).
• Socket Docker exposé. Donner accès à docker.sock, c'est comme offrir un passe-partout système. Docker l'écrit noir sur blanc, l'accès au socket équivaut à un accès root sur l'hôte. Ne l'exposez jamais à l'outil par défaut (Docker).
• Clé API sans plafond de dépense. Une clé mal gérée peut brûler du budget en une journée si une boucle s'emballe. Plafonnez, surveillez, et préparez une rotation.

C'est le genre de raccourci qu'on voit trop souvent dans les installations pressées, peu importe l'outil : on veut tester vite, alors on saute les vérifications, et on se retrouve à défaire six mois plus tard ce qui a été bâclé en dix minutes.

Ce qu'il vous faut avant de commencer

• Un macOS récent, à jour.
• Docker Desktop installé et démarré avant toute opération qui touche aux conteneurs. Docker sert ici de bac à sable : il isole OpenClaw dans un environnement cloisonné (système de fichiers, réseau, processus séparés du reste du Mac), pour que l'outil ne puisse pas toucher directement à vos fichiers personnels ni au reste du système. En savoir plus sur Docker et la conteneurisation.
• 1Password ou un autre gestionnaire de mots de passe pour stocker jetons et clés, jamais en clair dans un fichier texte.
• Node.js 24 installé via nvm, jamais via un installateur système et sans sudo.
• Zéro sudo tout au long du processus. Si ça demande sudo, on recule et on revalide la démarche.

L'installation étape par étape, avec preuves à l'appui

1. Vérifier Node.js 24 via nvm, jamais sudo

Objectif : confirmer que Node est accessible et en version 24.x avant d'aller plus loin.

nvm install 24
node -v

Résultat attendu : une version v24.x.x. Si Laravel Herd est déjà présent sur votre machine, son nvm intégré convient parfaitement pour cette étape, comme dans la partie 1 de ma série IA en local quand j'avais installé mon premier environnement IA local.

2. Installer OpenClaw depuis npm, sans script distant ni sudo

Objectif : installer une version épinglée d'OpenClaw, côté utilisateur, et valider l'installation.

npm install -g [email protected]
openclaw --version

Résultat attendu : la commande renvoie OpenClaw 2026.7.1-2. Aucun usage de curl | sh ni d'installateurs opaques.

3. Prouver l'absence d'autostart caché via launchd

Objectif : démontrer qu'OpenClaw ne s'est pas inscrit en autostart avant validation.

launchctl list | grep -i openclaw
ls -al ~/Library/LaunchAgents | grep -i openclaw

Résultat attendu : aucune sortie dans les deux cas. S'il y a du bruit, on arrête ici et on nettoie avant de continuer. La persistance silencieuse, c'est non.

4. Précréer une configuration minimaliste et sûre

Objectif : écrire ~/.openclaw/openclaw.json avec des permissions 600 avant tout premier démarrage, et utiliser un jeton d'authentification fort stocké dans 1Password.

Paramètres clés à mettre dans le fichier :

{
  "gateway": {
    "bind": "127.0.0.1",
    "port": 18789,
    "nodes": {
      "pairing": {
        "autoApproveCidrs": []
      }
    }
  },
  "session": {
    "dmScope": "per-channel-peer"
  },
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all"
      }
    }
  },
  "workspaceAccess": "none",
  "elevatedDefault": "off",
  "tools": {
    "allow": ["read", "sessions_list", "session_status"],
    "deny": ["exec", "process", "write", "edit", "apply_patch", "browser", "web_fetch", "nodes", "cron", "gateway"]
  }
}

L'authentification par jeton fort se génère séparément via openssl rand -hex 32, jamais affiché à l'écran, et se range dans son propre champ d'authentification (non représenté ci-dessus car généré, pas statique).

Principe : on valide par liste d'autorisation, pas par liste d'interdiction. L'allowlist a préséance, la denylist ferme le reste en seconde couche. C'est conforme aux recommandations OWASP sur la validation par liste d'autorisation plutôt que par liste d'interdiction (OWASP).

openssl rand -hex 32
openclaw config validate

Résultat attendu : le validateur retourne « Config valid ».

5. Construire l'image sandbox localement et épingler par digest

Objectif : bâtir l'image openclaw-sandbox:bookworm-slim localement, à partir de la recette officielle embarquée, sans jamais passer par un script distant, puis relever son digest pour l'épingler.

docker build -t openclaw-sandbox:bookworm-slim - <<'DOCKERFILE'
FROM debian:bookworm-slim
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y --no-install-recommends \
  bash ca-certificates curl git jq python3 ripgrep \
  && rm -rf /var/lib/apt/lists/*
RUN useradd --create-home --shell /bin/bash sandbox
USER sandbox
WORKDIR /home/sandbox
CMD ["sleep", "infinity"]
DOCKERFILE

docker images --digests

Résultat attendu : l'image openclaw-sandbox:bookworm-slim apparaît avec un digest SHA-256. Dans vos notes d'exploitation, épinglez par digest plutôt que par tag : c'est une bonne hygiène de chaîne d'approvisionnement recommandée par NIST SP 800-190 et par OWASP, un tag pouvant glisser vers une autre image au fil du temps (NIST SP 800-190). Ne configurez surtout jamais de politique de redémarrage automatique sur ces conteneurs.

6. Prouver le durcissement réseau et l'isolement du socket

Objectif : valider que la passerelle écoute seulement en loopback, que le conteneur n'a pas accès au docker.sock et que le réseau sortant est coupé pour la sandbox.

lsof -nP -iTCP:18789 -sTCP:LISTEN

Résultat attendu : uniquement des endpoints 127.0.0.1 et [::1] en écoute.

À l'intérieur du conteneur sandbox, vérifiez l'absence du socket Docker aux trois chemins habituels :

docker exec CONTENEUR sh -c 'for p in /var/run/docker.sock /private/var/run/docker.sock /run/docker.sock; do [ -e "$p" ] && echo PRESENT $p || echo ABSENT $p; done'

Résultat attendu : trois ABSENT.

Puis testez que le réseau sortant est bien coupé :

docker exec CONTENEUR sh -c 'timeout 5 curl -sI https://example.com >/dev/null && echo OUVERT || echo COUPE'

Résultat attendu : COUPE.

7. Clé API OpenRouter plafonnée et télémétrie npm réduite

Objectif : réduire le bruit, plafonner la dépense et préparer la rotation.

• Créez une clé OpenRouter avec un plafond de dépense réaliste et maxTokens à 4096, puis rangez-la dans 1Password avec une étiquette de projet claire.
• Coupez la télémétrie npm et les notifications de mise à jour pour éviter les sorties surprises dans les journaux.

npm config set fund false
npm config set update-notifier false

Résultat attendu : npm ne proposera plus de financement ni d'alertes de mise à jour dans vos sessions. Planifiez une rotation de la clé après la période d'utilisation intensive.

8. Premier démarrage manuel, jamais en service autostart

Objectif : démarrer la passerelle manuellement pour observer l'environnement durci, sans installer de service tant que les preuves ne sont pas satisfaisantes.

openclaw gateway run

Résultat attendu : l'interface est joignable à l'adresse http://127.0.0.1:18789. Collez le jeton depuis votre gestionnaire de mots de passe. Si un message « pairing required » apparaît, c'est normal et voulu la première fois par navigateur (voir la FAQ plus bas). Aucune écoute sur 0.0.0.0, aucun service persistant installé à cette étape.

9. Kill switch, arrêt des conteneurs et audit final

Objectif : stopper proprement, vérifier l'absence de résidus en écoute et produire un audit sécurité propre.

pkill -f "openclaw gateway run"
docker ps --filter name=openclaw
docker stop $(docker ps -q --filter name=openclaw)
openclaw security audit
lsof -iTCP:18789 -sTCP:LISTEN

Résultat attendu : plus aucun processus en écoute sur le port 18789, un audit de sécurité à 0 critique et 0 avertissement (corrigez toute alerte puis relancez l'audit jusqu'à 0), et aucun résultat sur la dernière commande lsof.

Dépannage : les erreurs les plus fréquentes

• Docker Desktop n'est pas démarré. Symptômes : l'image sandbox n'apparaît pas lors de la consultation des digests, ou le premier démarrage reste bloqué sur la préparation du conteneur. Solution : démarrez Docker Desktop, patientez jusqu'à l'icône verte, puis relancez les vérifications.

• Permissions du fichier de configuration incorrectes. Symptômes : la validation de configuration refuse de donner « Config valid », ou l'outil se plaint d'un fichier d'option trop permissif. Solution : remettez ~/.openclaw/openclaw.json en permissions 600 et relancez la validation, avant tout premier démarrage.

• Oubli de valider la configuration avant le premier démarrage. Symptômes : apparition d'options par défaut trop larges, pairing imprécis ou ouverture réseau involontaire. Solution : stoppez la passerelle, ajustez la configuration avec l'allowlist minimale, validez, puis redémarrez en mode manuel.

Et maintenant ?

Vous avez une installation macOS cadrée et mesurable, avec des preuves tangibles : écoute locale seulement, sandbox sans réseau ni socket Docker, audit à 0 critique et 0 avertissement, clés rangées avec un plafond et une rotation prévue. C'est exploitable au quotidien, sans crier victoire trop vite non plus.

Pour garder le cap, figez vos versions et prévoyez des fenêtres de mise à jour : testez une nouvelle version épinglée, revérifiez les preuves, documentez le digest. Une version figée sans veille redevient une vulnérabilité, un principe que j'applique aussi dans la partie 2 de ma série IA en local.

Prochains volets de la série :

• Article 2 : réussir sa démo sans perdre le contrôle
• Article 3 : budget et surveillance quotidienne, sans alarmer toute l'équipe
• Article 4 : Windows et WSL2 en profondeur
• Article 5 : désinstallation propre, traces nettoyées et leçons retenues

FAQ

Pourquoi n'utilisons-nous jamais sudo dans cette procédure ?

Parce que sudo élargit l'impact de chaque geste. Sur macOS, vous contournez alors les garde-fous natifs (TCC compris), vous installez des binaires système difficiles à auditer et vous gonflez la surface d'attaque. En restant dans votre profil utilisateur, vous facilitez les audits, les mises à jour et, au besoin, le retour arrière.

Pourquoi ne jamais afficher la clé ou le jeton à l'écran ?

Le terminal garde un historique défilant, les captures d'écran voyagent, et des journaux peuvent enregistrer la sortie standard. Afficher un secret, c'est ouvrir une piste d'exfiltration inutile. Générez-le, redirigez immédiatement la sortie vers le fichier de configuration, stockez une copie dans 1Password et copiez-collez depuis le coffre, pas depuis l'historique du shell.

Que faire si le pairing required apparaît au premier accès navigateur ?

C'est normal et souhaité la première fois. Listez les appareils détectés, puis approuvez explicitement celui que vous utilisez.

openclaw devices list
openclaw devices approve IDENTIFIANT

Rechargez ensuite la page et poursuivez. Ce rituel évite toute approbation automatique et garde la main sur qui se connecte.