Pourquoi les workflows OpenClaw en SSH distant ont besoin de limites
Le travail de type OpenClaw devient vraiment utile quand l’agent peut quitter l’ordinateur portable et continuer sur une machine distante. SSH rend cela possible, mais ajoute aussi un risque net : la machine distante peut hériter de trop de confiance, de trop de clés et de trop d’accès au dépôt.
Office Claws n’est pas un runtime OpenClaw natif. Nous utilisons le même modèle opérationnel pour des agents appuyés par Codex : garder le plan de contrôle en local, se connecter à un runner VPS jetable par un chemin privé, et rendre chaque session distante facile à inspecter. Si tu choisis d’abord la couche runtime, commence par OpenClaw vs Codex, puis utilise ce workflow comme couche SSH plus sûre.
Le modèle de runner SSH pour OpenClaw
Un bon workflow SSH distant a trois rôles : isoler le runner, réduire les identifiants et préserver la trace d’audit. Le runner doit être assez utile pour compiler et tester le code, mais assez banal pour être détruit à la fin de la tâche.
| Couche | Garder en local | Autoriser sur le runner | Porte de revue |
|---|---|---|---|
| Contrôle | Bureau Office Claws, clés fournisseur, approbations | État et journaux du runner | Un humain peut arrêter ou supprimer le runner |
| Source | Dépôt canonique et branches protégées | Une branche ou un worktree | Diff de PR avant fusion |
| Secrets | Clés API longues durées et tokens de déploiement | Token de dépôt court si nécessaire | Token révoqué après la tâche |
| Réseau | Tailscale ou politique de route privée | SSH depuis un opérateur approuvé | Ports entrants inconnus bloqués |
Ce modèle rejoint OpenClaw secrets management : ne copie pas le coffre de l’opérateur sur la machine où l’agent exécute des commandes non fiables. Utilise SSH comme transport, pas comme prétexte pour transformer le runner en deuxième ordinateur portable.
Une checklist minimale pour le SSH distant
Les commandes exactes varient selon le cloud et la distribution, mais la forme opérationnelle doit rester stable. Voici la checklist que nous aimons avant de confier une tâche à un agent :
1. Create or reuse one VPS runner for one task.
2. Connect over Tailscale or another private route when possible.
3. Check out one repo branch or one isolated worktree.
4. Pass only the scoped token required for the task.
5. Stream logs back to the operator view.
6. Push a PR, validate CI, then destroy or reset the runner.Le détail important est l’étape quatre. Si un runner doit seulement créer une branche et pousser une PR, il n’a pas besoin de clés de déploiement de production. S’il doit seulement lancer des tests, il n’a peut-être besoin d’aucun token externe. OpenClaw sandbox couvre la même idée côté espace de travail.
Les modes d’échec à éliminer par conception
Les workflows SSH distants échouent souvent discrètement avant d’échouer bruyamment. Un vieux runner conserve un ancien fichier .env. Une machine partagée a deux agents qui modifient le même checkout. Un token personnel reste dans l’historique du shell. Rien de tout cela ne ressemble à un incident jusqu’au mauvais push de branche ou à la fuite de la mauvaise clé.
Conçois le workflow pour que le chemin sûr soit le plus simple :
- une tâche par runner ou worktree ;
- aucun agent n’écrit directement dans
main; - les journaux reviennent vers l’opérateur local au lieu de rester seulement sur le VPS ;
- les secrets sont courts, limités et tournés après usage ;
- les sessions bloquées peuvent être arrêtées depuis le gestionnaire desktop.
Pour la partie GitHub, associe cela au OpenClaw GitHub workflow. SSH amène l’agent sur la machine ; les branches, les PR et CI décident si le travail doit être intégré.
Ce qu’Office Claws ajoute
Office Claws for OpenClaw users est la couche opérateur autour de ce modèle : gestion desktop, provisionnement de runners VPS, monitoring et gestion plus sûre des clés locales. Le chemin d’exécution est aujourd’hui Codex-first, c’est pourquoi nous décrivons honnêtement ce workflow comme adjacent à OpenClaw plutôt que comme un support OpenClaw natif.
Le résultat pratique est simple : les agents peuvent travailler à distance sans transformer chaque VPS en ancre de confiance permanente. Garde le contrôle en local, les runners jetables, et chaque session SSH orientée vers une branche révisable.