2026 OpenClaw : scripts d’installation officiels vs npm global (pin, repli proxy)

Lecture ~14 min · MACCOME

Public : ingénieurs qui provisionnent OpenClaw sur laptops neufs, WSL2, serveurs Linux ou hôtes Windows et s’appuient par défaut sur les one-liners curl ou PowerShell officiels, mais rencontrent proxys d’entreprise, AC personnalisées, politique d’exécution ou trous de PATH : le script « termine » sans openclaw. Résultat : utiliser le guide d’installation trois plateformes comme carte et cet article comme runbook d’installation double voie et d’épinglage : rapide si la voie script fonctionne ; sinon npm install -g avec versions explicites ; vérifier Node et PATH avant le doctor et la triage post-install. Plan : six pièges, matrice, extraits, runbook en six étapes, trois KPI, conseils de clôture.

Pourquoi, en 2026, un code de sortie zéro peut encore signifier une installation OpenClaw cassée

Les installateurs officiels détectent Node, récupèrent la logique d’amorçage et enregistrent une CLI globale, pourtant les shells non interactifs et le TLS d’entreprise peuvent faire s’arrêter le « succès » au téléchargement : la binaire est sous un préfixe utilisateur que les comptes de service CI ne voient jamais ; ou les globaux npm s’installent mais les shells sans login sautent les rc qui modifient PATH. Six erreurs d’interprétation récurrentes suivent.

  1. Ignorer le plancher de major Node documenté : une LTS plus ancienne peut parser certaines commandes mais échoue au démarrage du Gateway ; noter node -v contre le tableau officiel, pas seulement « npm tourne ».
  2. Mélanger les sources voie script et voie npm : après les deux passages, which openclaw peut pointer vers des préfixes différents—afficher toujours le chemin résolu avant de déboguer la config.
  3. Le proxy autorise le registre mais bloque les hôtes de scripts : relancer curl aide rarement ; changer de voie et définir HTTPS_PROXY, npm config set cafile ou un miroir de registre interne après revue sécurité.
  4. Politique d’exécution Windows et trous de profil : PowerShell réussit mais le bin npm global manque pour la session ; ou la politique bloque les scripts distants non signés—wrappers approuvés par l’org ou npm.
  5. Pas d’épinglage ni trace de changement : tout le monde utilise @latest ; le comportement du Gateway dérive la nuit—souvent corrélé aux cas « canaux OK » dans l’article de triage Gateway sans réponse.
  6. Sauter l’onboarding avant l’empreinte : sur Mac distants, utilisateur d’install ≠ utilisateur de démon donne « installé mais mauvais HOME » ; finir les contrôles ici avant systemd/launchd et le runbook Docker production.

Lier le choix de voie à la topologie du guide trois plateformes : le dev interactif peut favoriser le script rapide ; les builders sans présence humaine devraient préférer npm audit-friendly ou artefacts internes avec versions Node et CLI sur le ticket de changement.

Si la norme est pnpm/corepack, la règle reste : points d’entrée audités uniquement, avec Environment systemd/launchd aligné sur les shells interactifs. Documenter les migrations quand la doc publique dit encore latest alors que votre baseline épingle un semver.

Quand plusieurs projets Node partagent un hôte, isoler la major OpenClaw des runtimes d’apps pour éviter les cascades d’upgrade—même esprit d’isolement que les articles de pools multi-projets, appliqué à Node.

Matrice : voie script officielle vs voie npm global

Noter l’atteignabilité des hôtes de scripts, les besoins d’audit et l’exploitation sans présence—pas le goût personnel.

DimensionVoie curl/bash ou PowerShellVoie npm / pnpm global
Vitesse de première installEn général le moins d’étapes sur Internet propreExige d’abord Node et le gestionnaire de paquets prêts
Adéquation proxy d’entrepriseDépend des domaines de script et des chaînes certificat ; échecs bruyantsSépare registre, cafile, strict-ssl et pins—favorable à l’audit
RépétabilitéLes tags latest dérivent comme du npm non géréUn [email protected] explicite peut refléter des lockfiles internes
Sans présence / CINécessite garanties non interactives et contrats PATHPlus simple à intégrer dans des images dorées ou conteneurs de base
RollbackDépend de la sémantique de désinstallation de l’installateurRéinstaller le semver précédent avec ordre de désinstallation documenté

Extraits exécutables : empreinte trois lignes après l’installation

Coller les sorties dans les tickets ou wikis ; sur Mac distant, exécuter sous le même contexte de connexion que le démon final.

bash
node -v
command -v openclaw
openclaw --version 2>/dev/null || openclaw version 2>/dev/null || true

# exemple voie npm (remplacer semver par votre baseline)
# npm install -g [email protected]
# npm config get registry
# npm config get cafile
warning

Avertissement : ne jamais coller des secrets internes de .npmrc dans des dépôts publics ; utiliser des placeholders dans la doc et stocker les identifiants dans le gestionnaire de secrets.

Runbook en six étapes : de « installé » à une baseline propice au rollback

  1. Verrouiller la baseline Node : installer la major documentée via fnm/nvm ou paquets OS ; épinger le même digest dans les images CI.
  2. Essayer la voie script avec journaux : point d’entrée curl/bash ou PowerShell officiel ; capturer les erreurs TLS complètes en cas d’échec.
  3. Repli sur npm : appliquer proxy et cafile, puis npm install -g openclaw@<pin> ; confirmer une seule version avec npm ls -g --depth=0.
  4. Réparer les contrats PATH : injecter le bin global dans Environment systemd/launchd ou l’env du runner—pas seulement les rc interactifs.
  5. Contrôles avant doctor : l’utilisateur d’install doit correspondre à l’utilisateur Gateway avant d’ouvrir les tableaux de triage post-install.
  6. Enregistrer le rollback : conserver le semver précédent et l’ordre de désinstallation pour revenir en quelques minutes.

Pour Ansible/Salt, rendre les tâches d’installation idempotentes : les relances ne doivent pas upgrader silencieusement vers latest. Sur parc Windows, documenter la politique d’exécution et les chemins npm globaux dans les notes GPO et OU pilotes avant déploiement fleet.

Trois KPI pour revues hebdomadaires

  1. Latence install → premier openclaw doctor réussi : l’allongement signale souvent PATH, droits ou proxy—pas les réglages modèle.
  2. Nombre de doublons globaux : les contrôles automatisés doivent imposer exactement un semver OpenClaw sur les builders.
  3. Taux d’échec de téléchargement de script par région : des pics régionaux justifient une revue DNS/MITM avant de peaufiner les paramètres modèle.

Note de terrain (pas un benchmark) : sur les déploiements entreprise 2025–2026, la « voie script sans pins » tend à générer plus de tickets de dérive nocturne sur des dizaines d’hôtes que « voie npm + pins explicites + fenêtres de changement » ; l’écart est la répétabilité, pas le CPU de crête.

Quand OpenClaw partage un Mac distant avec des builds iOS, décaler les upgrades Node/OpenClaw des grands sauts Xcode d’au moins un cycle de maintenance pour garder un bissect utile.

Sur builders en lecture seule, attacher l’empreinte trois lignes aux résumés de job (rédiger les secrets) et comparer aux horodatages de démarrage Gateway ; si l’empreinte est stable alors que le comportement change, privilégier quota modèle ou config canal aux boucles de réinstall—cela opérationnalise la découpe en quatre couches de l’article sans réponse.

Pourquoi des scripts rapides sur laptop n’impliquent pas des démons stables en production

Les machines interactives tolèrent essais et erreurs ; la production exige voies auditées, versions épinglées et contrats PATH alignés sur les démons. Les hôtes cloud éphémères qui tirent toujours @latest ramènent la triage au hasard des releases amont. Les équipes qui doivent garder le Gateway en ligne sur Mac distants avec egress, disque et journaux prévisibles choisissent en général du Apple Silicon dédié avec conditions de location flexibles plutôt que des VM jetables en rotation. MACCOME propose des Mac mini M4 / M4 Pro multi-régions avec tarifs publics pour aligner les baselines OpenClaw sur la même stratégie régionale que les builders.

Pilote sur un hôte avec ce runbook avant mise à l’échelle horizontale ; aligner les empreintes d’échec avec l’arbre de triage sans réponse pour couper le travail dupliqué.

Revoir trimestriellement les listes blanches des domaines d’installateur et des registres npm—moins cher que l’archéologie proxy rétroactive dans le chat.

Lier ce runbook au modèle de changement interne pour que les nouveaux clusters héritent par défaut des pins et du PATH.

FAQ

Frontière avec le guide d’installation trois plateformes ?

Le guide couvre scénarios et chemins ; cet article couvre double voie, repli proxy et pins. Contexte tarifs : tarifs de location.

Puis-je sauter l’install locale et n’utiliser que Docker ?

Oui, mais les hôtes ont encore besoin d’une CLI cohérente et de droits sur volumes—voir le runbook Docker production. Cet article explique toujours d’où viennent les versions Node et CLI sur l’hôte.

Différences WSL2 vs Linux natif ?

Disponibilité systemd, mappage de chemins et proxys Windows hérités diffèrent ; en cas d’échec, préférer npm dans WSL avec proxy et cafile propres à WSL.