Exécuter OpenClaw en local est le bon premier geste quand vous apprenez le framework, testez des prompts ou vérifiez si votre workflow a vraiment une forme d'agent. Votre ordinateur est proche du repo, facile à inspecter et peu coûteux à réinitialiser.
Le piège consiste à traiter ce même setup local comme de la production. Un portable se met en veille. Les shells disparaissent. Les secrets se dispersent dans les dotfiles. Les longues exécutions de code ont besoin d'une frontière plus nette. Ce guide garde le chemin local honnête, puis montre quand déplacer le travail de coding vers Codex sur un VPS avec Office Claws.
Commencer avec une petite sandbox locale
Ne pointez pas un nouvel agent vers votre checkout principal en espérant que tout ira bien. Donnez à OpenClaw un workspace étroit, une branche jetable et seulement les identifiants dont il a vraiment besoin.
| Choix de setup | Défaut plus sûr | Pourquoi ça aide |
|---|---|---|
| Repository | Nouvelle branche ou clone jetable | Rollback facile après une mauvaise édition |
| Secrets | Tokens à courte durée seulement | Moins de dégâts si un appel d'outil divulgue du contexte |
| Système de fichiers | Un seul dossier de projet | Évite les éditions accidentelles hors de la tâche |
| Réseau | Allowlist explicite | Rend les appels inattendus visibles |
Une routine locale minimale ressemble à ceci :
git checkout -b agent/sandbox-task
git status --short
# start OpenClaw with only this repo and the credentials required for the taskL'important n'est pas la commande. C'est la forme : une tâche, une branche, une frontière de confiance.
Garder la boucle locale observable
Les exécutions locales d'OpenClaw sont utiles parce que vous pouvez les surveiller de près. Utilisez cet avantage. Gardez le terminal visible, relisez les diffs avant chaque commit et intégrez les tests à la boucle plutôt qu'à un nettoyage final.
Nous aimons cette cadence :
- Demandez un petit changement, pas toute une roadmap.
- Laissez l'agent inspecter et proposer un plan.
- Relisez les fichiers qu'il veut toucher.
- Lancez le plus petit test significatif.
- Ne committez que lorsque le diff est ennuyeux.
Cette cadence facilite aussi les migrations. Si un workflow fonctionne localement par petites boucles, il se porte généralement bien vers Codex CLI sur un hôte distant. S'il ne fonctionne que parce que vous sauvez constamment l'agent à la main, l'hébergement ne corrigera pas magiquement le processus.
Savoir quand le local n'est plus le bon endroit
Local-first ne veut pas dire portable-pour-toujours. Déplacez la charge quand l'agent a besoin de temps, d'isolation ou de persistance.
| Signal | Rester local | Passer au VPS |
|---|---|---|
| Apprendre un nouveau framework d'agents | Oui | Pas encore |
| Refactor d'une heure avec revue active | Oui | Optionnel |
| Boucle test/fix pendant la nuit | Non | Oui |
| Plusieurs agents sur des branches liées | Pénible | Oui |
| Secrets proches production ou données client | Risqué | Préférer un hôte isolé |
C'est là que le choix OpenClaw vs Codex compte. OpenClaw est large et orienté écosystème. Codex est plus étroit, mais fort pour le travail logiciel centré sur un repo et compatible avec une économie d'abonnement. Notre comparaison OpenClaw vs Codex détaille ce compromis.
Le passage vers Office Claws
Office Claws n'est pas un runtime OpenClaw. Nous ne revendiquons pas de support natif OpenClaw et nous ne cachons pas OpenClaw derrière un bouton. Le passage honnête est celui-ci : utilisez OpenClaw en local pendant que vous explorez le workflow d'agent généraliste, puis déplacez le travail très orienté code vers des agents Codex quand vous voulez une exécution persistante et centrée sur le repo.
Avec Office Claws, ce chemin hébergé reste volontairement simple :
- Provisionner un VPS self-hosted depuis l'app desktop.
- Le connecter via Tailscale pour que le runner soit joignable sans exposer SSH à internet.
- Se connecter à Codex CLI avec votre abonnement ChatGPT.
- Lancer un agent par branche et suivre le statut dans le bureau pixel art.
- Rapatrier la branche en local pour la revue finale avant merge.
Le chemin Office Claws for OpenClaw users parle de contrôle : votre VPS, votre abonnement, vos branches et une vue desktop qui rend les agents longue durée visibles.
Recommandation
Exécutez d'abord OpenClaw en local. Gardez la sandbox serrée, mesurez quelle part de votre travail est vraiment centrée sur le code et utilisez la boucle locale pour apprendre les forces de l'agent.
Quand la tâche devient longue, riche en branches ou trop importante pour rester dans un portable en veille, déplacez la partie coding vers Codex sur un VPS. Vous obtenez ainsi la persistance que veulent les utilisateurs OpenClaw sans prétendre que chaque workflow OpenClaw appartient dans un outil en forme de Codex.
Le local sert à apprendre le workflow. Un runner Codex distant sert à laisser avancer le travail de code ennuyeux.