2026 OpenClaw parcours officiel : openclaw onboard de bout en bout—Node 24, workspace, premier canal, Skill ClawHub, daemon, mises à jour de canaux

Lecture ~14 min · MACCOME

Public : vous avez installé npm i -g openclaw en suivant des notes éparses, mais vous jonglez entre workspace, Gateway, canaux et Skills sans la séquence openclaw onboard recommandée, et hésitez sur la manière d’aligner Node 24, daemons, canaux stable/beta/dev. Résultat : un runbook relecturable—doctor → onboard → preuve de premier canal → premier Skill ClawHub → install daemon → montées/retours documentés—pour passer de « ça démarre » à « ça tient seul en continu ». Carte : six pièges → tableau des chemins → six étapes → trois champs d’audit ; lire avec docker-setup + GHCR, pairing Compose 1008 et triage post-install doctor.

Pourquoi « CLI installé » n’équivaut pas à « OpenClaw déployé »

L’amont pousse onboard car Gateway, workspace, canaux et modèles par défaut ont des dépendances d’ordre. Sauter l’assistant en éditant le JSON finit souvent en « processus up, jamais de messages » ou « Skill installé, outils jamais enregistrés ». Six lectures erronées fréquentes en 2026 :

  1. Node « à peine compatible » : préférez Node 24 (au moins 22.16+). Sous le socle, l’install peut réussir pendant que le Gateway s’écrase sur des bords natifs.
  2. Sauter openclaw doctor : sans bisect en fin d’onboard. Traitez doctor comme un verrou, pas un ornement.
  3. Skills avant canaux : l’install passe, rien en chat; souvent pas de redémarrage Gateway ou OAuth incomplet, pas le modèle.
  4. Confondre daemon et shell interactif : fermer le laptop stoppe le Gateway, on incrimine la version en amont.
  5. Mélange de canaux non documenté : bêta ici, stable là; dérive CLI/Gateway, mismatches non reproductibles.
  6. Répertoires d’état éphémères : sur Mac distants ou VPS, état sur disque non monté = mises à jour vues comme « perte de config ».

Si vous ciblez les conteneurs, lisez docker-setup + GHCR d’abord, cet article ensuite. Problèmes de sous-agent, lisez Compose 1008 avant de réinstaller npm à l’aveugle.

Table : trois chemins d’entrée (cet article couvre l’onboard npm)

CheminIdéal pourArtefacts à saisirRapport à cet article
openclaw onboard (npm global)Mac dédié ou VPS avec Gateway durableWorkspace, openclaw.json, unité launchd/systemd, preuve de canal, journal de vérification SkillPrincipal
Docker/Compose officiellivraison par image, runtime homogènefichier Compose, carto volumes, politique de switch OPENCLAW_IMAGEComplément
Triage centré sur doctorinstallé mais malsainarbres de symptômes, empreintes de logsLecture en parallèle
warning

Attention : onboard écrit sous le home. Sur comptes macOS partagés, validez la politique. En production, préférez des hôtes dédiés ou comptes de service.

Runbook en six étapes : d’hôte vide à boucle minimale sans opérateur

  1. Installer Node et noter la version : pinner nvm ou installeur officiel; consigner node -v dans le ticket de changement.
  2. Installer la CLI + doctor : npm i -g openclaw@latest puis openclaw doctor; vider le risque élevé avant onboard.
  3. Lancer openclaw onboard : workspace, modèle par défaut, injection AGENTS.md, au moins un canal; noter le port du Gateway et le chemin Control UI depuis l’assistant.
  4. Prouver le canal : message de test end-to-end; en échec, triage doctor plutôt que changer modèle et canal en même temps.
  5. Premier Skill ClawHub : openclaw skills searchopenclaw skills install <name>redémarrer le Gatewayopenclaw skills list.
  6. Installer le daemon et consigner les chemins de log : openclaw onboard --install-daemon (ou équivalent assistant); rotation des logs et seuils disque avant de jouer openclaw update --channel beta|dev.
bash
node -v
npm i -g openclaw@latest
openclaw doctor
openclaw onboard
openclaw skills search "calendar"
openclaw skills install example-org/some-skill
openclaw restart
openclaw skills list
openclaw onboard --install-daemon
openclaw update --channel stable

Trois champs d’audit pour le change ticket

  1. Majeure Node + source d’install : ex. v24.x via nvm; relancer doctor après chaque upgrade OS.
  2. Narration listen/bind du Gateway : documenter loopback vs reverse-proxy/Tailscale pour ne pas heurter l’guidance pairing Compose.
  3. Mapping des canaux : lier stable|beta|dev à des fenêtres calendrier; les retours notent des paires versions CLI+Gateway.

Ce sont des champs d’ingénierie, pas des SLA fournisseurs. Si le Gateway partage l’hôte avec la CI, ajoutez des alertes CPU et disque pour ne pas laisser les builds affamer les logs ou l’état SQLite.

Le onboard ancre l’automatisation : une fois les répertoires workspace/Skills stables, sauvegardes et upgrades n’ont qu’une source de vérité. Sauter cette ancre, c’est des réunions sur « qui a touché openclaw.json ».

Pourquoi un portable perso est un mauvais défaut pour un Gateway 24/7

Veille, aléas VPN et mises à jour d’entreprise brisent la continuité temporelle du Gateway. Quand OpenClaw devient le plan de contrôle de fait d’une petite équipe, privilégiez un hôte 7j/7 avec disque et sortie internet prévisibles; gardez le portable en client CLI si besoin.

Les tours maison et bureau offrent des fenêtres de patch et d’aléa électriques mal maîtrisées. Avec ferme de builds iOS et agents IA colocalisés, des hôtes cloud Apple Silicon multi-régions, gouvernés, donnent en général de meilleures métriques qu’un portable emprunté. MACCOME fournit nœuds bare metal et loyers flexibles : voir tarifs publics et centre d’aide sur canaux et accès.

Pilote : une semaine d’onboard+daemon sur un Mac distant dédié, capter le volume de logs et les pics CPU, puis décider de colocaliser le bêta; évitez d’ancrer le Gateway de prod sur une machine de dev dès la semaine 1.

FAQ

Sous WSL2, c’est le même enchaînement que sur macOS ?

Même trame, chemins et réseau diffèrent—préférez triage doctor + WSL2 plutôt qu’assumer la parité launchd.

La liste de Skills est vide après install par où commencer ?

Confirmez le redémarrage du Gateway et la visibilité du workspace, puis lisez triage no-reply avant de sauter en bêta.

Cela heurte l’install Docker ?

Non, mais ne partagez pas le même répertoire de données; choisissez la piste npm ou conteneur par politique. Voir docker-setup + GHCR.