OpenClaw : Mac distant connecté, mais commandes non exécutées ? Dépannage 2026

Un nœud peut être visible et connecté alors que la commande demandée n’est pas disponible ou reste bloquée par une règle. Il faut donc isoler le point d’arrêt plutôt que modifier immédiatement le réseau, réinstaller Xcode ou désactiver les contrôles d’accès. Le parcours à reconstituer est le suivant : l’Agent sélectionne un nœud, le Gateway applique sa politique, puis le nœud local autorise ou refuse l’exécution de la commande.

Les états à distinguer sont liés, mais ne se remplacent pas :

• La connexion indique que le Gateway et le nœud communiquent.
• L’appairage établit une relation de confiance entre le nœud et le Gateway.
• La disponibilité de la commande détermine si une action comme system.run est exposée par le nœud.
• La stratégie du Gateway décide si cette famille de commandes est permise.
• L’approbation locale peut encore demander une validation ou refuser une commande précise.
• La cible effective détermine enfin sur quelle machine la commande est lancée.

Cette séparation explique pourquoi un tableau de bord peut afficher un nœud connecté sans que l’exécution soit possible. La documentation OpenClaw consacrée à l’exécution sur les nœuds décrit ce chemin de requête ; la page de dépannage aide à examiner l’état du nœud et les erreurs remontées. Les libellés et détails visibles peuvent dépendre de l’environnement : il convient de relever l’erreur exacte plutôt que de supposer qu’un message générique désigne toujours la même cause.

Pour commencer, consignez le texte de l’erreur, l’identifiant du nœud sélectionné, l’heure de l’essai et le nom de l’Agent. Gardez aussi le contexte de la commande : un refus d’autorisation, une commande absente et une commande qui démarre puis échoue ne sont pas le même incident. Ce relevé empêche de confondre une panne de routage avec un échec de l’outil appelé sur macOS.

Un nœud peut être appairé sans que l’autorisation d’exécuter une commande soit acquise. Vérifiez donc séparément l’identité du nœud, l’état d’approbation et la liste des commandes exposées ; ne réappairez pas un nœud déjà reconnu tant que les indices ne désignent pas une perte de confiance ou une identité différente.

Première vérification : confirmer l’identité du nœud

Dans l’interface ou les journaux OpenClaw utilisés par l’installation, relevez l’identifiant du nœud actuellement connecté et comparez-le à celui visé par l’Agent. Un nom d’affichage similaire n’est pas une preuve d’identité : plusieurs machines peuvent avoir des noms proches, et un ancien enregistrement peut rester visible. Consultez la procédure officielle d’appairage des nœuds pour interpréter les demandes en attente et l’état de confiance.

Si une demande d’appairage attend une décision, traitez-la selon la procédure d’administration prévue, après avoir vérifié l’origine et l’identité de la demande. Si le nœud est déjà appairé et que l’identifiant correspond, ne répétez pas l’opération comme remède automatique : l’appairage ne valide pas à lui seul la disponibilité de system.run.

Deuxième vérification : chercher l’approbation du plan de commande

Inspectez la description du nœud et les informations de commandes qu’il annonce. Si system.run n’y apparaît pas, l’Agent ne peut pas exécuter cette action simplement parce que la connexion est active. Si la commande apparaît, ce constat confirme sa disponibilité déclarée, mais ne prouve pas encore qu’elle est autorisée par les stratégies du Gateway ou du nœud.

Cette vérification répond au cas où un nœud appairé ne lance toujours pas les commandes sur le Mac : l’appairage décrit une relation de confiance ; l’exposition et l’autorisation de l’action relèvent d’autres contrôles. Comparez la description avant et après toute modification contrôlée, puis conservez les journaux utiles à l’incident. Les recommandations de la documentation sur l’exécution de commandes des nœuds permettent de distinguer l’action demandée de l’état de connexion.

Lorsque system.run est disponible, examinez la règle du Gateway qui s’applique à la commande et au nœud. Une règle de refus peut bloquer l’action même si le nœud est correctement appairé ; une règle d’autorisation globale mal comprise peut, à l’inverse, accorder plus de capacité que nécessaire. La référence OpenClaw sur la stratégie des commandes de nœud décrit les règles et décisions à contrôler.

Procédez dans cet ordre :

• Identifiez la commande effective évaluée par OpenClaw, et non uniquement le texte affiché dans l’interface de l’Agent.
• Consultez le résultat de stratégie et les journaux associés à la tentative, notamment le nœud et l’action concernés.
• Déterminez si la décision vient d’une règle générale ou d’une règle applicable à ce nœud.
• Modifiez uniquement la règle identifiée, selon la politique de l’équipe, puis répétez le même test limité.
• Si la règle reste ambiguë, conservez le refus et demandez une revue plutôt que de remplacer la politique par une autorisation sans restriction.

Une erreur de stratégie est un indice, pas une invitation à désactiver les contrôles. Une modification trop large peut résoudre un test isolé tout en autorisant d’autres commandes ou d’autres nœuds. Le bon correctif doit être vérifiable dans la décision de stratégie et rester limité au besoin documenté.

Si la stratégie du Gateway ne bloque pas la requête, examinez l’approbation appliquée sur le Mac lui-même. Un message du type approval required indique qu’une décision d’approbation est nécessaire ; un résultat comme allowlist miss invite à vérifier si la commande correspond à la liste autorisée. Ces termes orientent le diagnostic, mais leur interprétation doit être rapprochée du détail de l’événement et de la configuration réellement chargée.

La documentation OpenClaw sur les approbations d’exécution sépare ces décisions locales de l’appairage et des règles du Gateway. En pratique, contrôlez l’approbation enregistrée pour le nœud concerné, le chemin de l’exécutable, les arguments transmis et la méthode de confirmation exigée. Une commande peut être refusée parce que son exécutable ne correspond pas à la liste autorisée, même si une variante proche y figure.

Ne répondez pas à un refus en passant directement à une exécution sans limite. Si une validation humaine est prévue, utilisez-la pour la commande examinée, puis vérifiez dans le journal si elle a effectivement été accordée. Si une règle de liste autorisée doit être corrigée, documentez le chemin et les arguments nécessaires, et évitez une entrée générique qui permettrait des commandes sans rapport avec la tâche.

Point de vigilance : une identité appairée, une décision favorable du Gateway et une approbation locale sont des preuves différentes. Gardez leurs événements distincts dans le compte rendu ; les fusionner sous « accès autorisé » rend la prochaine enquête plus difficile.

Une commande peut être autorisée et s’exécuter sans produire le résultat attendu parce que l’Agent l’a envoyée à un autre nœud, ou parce que le contexte de l’utilisateur distant diffère de celui supposé. Si plusieurs nœuds exécutables sont présents, vérifiez la cible dans la requête de l’Agent et dans les journaux de l’exécution ; ne déduisez pas la machine cible du seul nom de l’Agent.

Pour une vérification initiale, demandez au nœud d’exécuter une commande de lecture seule, par exemple hostname, id -un et pwd, puis comparez les résultats à ceux attendus sur le Mac. Ces commandes donnent des indices sur l’hôte, le compte et le répertoire courant. Elles ne prouvent pas à elles seules qu’un projet précis ou qu’une installation Xcode particulière est utilisée : il faut poursuivre sur la chaîne d’outils.

Sur le Mac cible, examinez le chemin actif et la version déclarée :

xcode-select -p
xcodebuild -version

Apple indique que les outils de ligne de commande Xcode nécessitent Xcode et que le répertoire développeur actif doit être sélectionné ; les instructions Apple d’installation et de sélection des outils donnent les prérequis à vérifier. Si le chemin retourné ne correspond pas à l’installation attendue, vérifiez le choix actif avant d’attribuer l’échec à OpenClaw. Ne changez pas cette sélection sur une machine partagée sans confirmer l’impact sur les autres travaux.

Pour vérifier un projet, commencez par une inspection non destructive :

xcodebuild -list -project "/chemin/vers/Projet.xcodeproj"

Remplacez le chemin par celui du dépôt réellement présent sur le nœud. Si la commande ne trouve pas le projet, contrôlez le répertoire courant, les droits de lecture et le chemin transmis par l’Agent. Si la liste des cibles s’affiche, cela confirme que xcodebuild peut lire le projet dans ce contexte, mais pas que sa compilation complète aboutira.

Ensuite, lancez une compilation de contrôle avec le schéma réellement utilisé par l’équipe et un répertoire de résultats dédié, par exemple :

xcodebuild -project "/chemin/vers/Projet.xcodeproj" \
  -scheme "SchemaDeValidation" \
  -destination 'generic/platform=iOS' \
  -derivedDataPath "/tmp/DerivedData-validation" \
  build

Adaptez les chemins et le schéma au dépôt ; n’utilisez pas cet exemple tel quel sans vérifier qu’il correspond au projet. La compilation peut créer des fichiers dans le répertoire de résultats indiqué. Elle ne doit donc pas être lancée sur un chemin de production ou dans un espace partagé sans accord. Conservez la sortie, le compte utilisé, le chemin actif retourné par xcode-select -p et l’identifiant du nœud : ensemble, ces éléments relient le résultat à son contexte d’exécution.

Reprenez la commande initialement en échec après chaque correction ciblée. Une commande de diagnostic qui fonctionne ne suffit pas à démontrer que la tâche d’origine est réparée : elle peut utiliser un exécutable différent, une autre cible ou un niveau d’autorisation distinct.

• [ ] L’identifiant du nœud dans la requête correspond au Mac attendu.
• [ ] L’état d’appairage est confirmé et aucune demande inattendue ne reste à traiter.
• [ ] La description du nœud indique que system.run est disponible.
• [ ] Le résultat de stratégie du Gateway autorise précisément l’action examinée.
• [ ] L’approbation locale est accordée ou la règle de liste autorisée correspond à l’exécutable et aux arguments.
• [ ] Les journaux relient la requête de l’Agent à l’exécution sur le nœud prévu.
• [ ] hostname, id -un et pwd confirment le contexte de la machine distante.
• [ ] Le chemin actif et la version Xcode ont été vérifiés sur cette même cible.
• [ ] La commande Xcode de contrôle a produit une sortie conservée et interprétable.
• [ ] La commande initialement défaillante a été rejouée sans élargir les permissions au-delà du besoin.

Si une seule vérification échoue, revenez à la frontière correspondante au lieu de modifier toutes les couches simultanément. Par exemple, un system.run absent de la description du nœud appelle une investigation différente d’un refus d’approbation locale ; un xcodebuild qui démarre puis échoue relève ensuite du projet, de son schéma ou de sa chaîne d’outils, pas nécessairement de la connexion OpenClaw.

Le compte rendu de résolution doit conserver l’erreur initiale, la décision qui a bloqué la requête, la modification appliquée, le résultat du nouveau test et les restrictions maintenues. Indiquez aussi si une confirmation humaine reste nécessaire et dans quelles conditions le changement doit être annulé. Cette trace permet de différencier un correctif temporaire d’une nouvelle règle durable, et de reproduire le diagnostic lors d’une prochaine mise à jour de l’environnement.

Une installation locale évite la dépendance à une session distante, mais immobilise un Mac et son budget dans un usage qui peut être ponctuel. Un serveur Linux peut héberger des tâches générales, mais ne remplace pas l’exécution macOS lorsque le projet exige Xcode. Une machine virtuelle ou un environnement simulé peut aider certains tests, sans constituer automatiquement une preuve équivalente à une compilation réalisée sur le Mac cible.

La location d’un Mac distant est pertinente lorsque l’équipe a besoin d’un environnement macOS accessible pour une période de développement, de validation ou d’exploitation, sans acheter immédiatement une machine dédiée. Elle n’est pas forcément le bon choix pour une charge lourde et continue, pour des essais nécessitant un accès physique à du matériel, ou lorsque la politique de sécurité interdit l’exécution de dépôts sur une machine hébergée. Dans ces cas, un Mac détenu et administré par l’équipe peut être plus approprié.

Pour évaluer une solution, il faut vérifier les moyens d’accès réellement proposés, la possibilité de reproduire le contexte de l’Agent et la manière dont les permissions sont administrées. Les informations sur l’environnement Mac distant de NUKCLOUD peuvent servir de point de départ ; pour une question d’accès ou d’exploitation, consultez également l’aide NUKCLOUD. Avant d’y déplacer un flux de construction, rejouez les mêmes contrôles : cible identifiée, autorisation minimale, chaîne Xcode vérifiée et résultat conservé. Le Mac distant devient alors un choix d’exploitation étayé par une validation reproductible, plutôt qu’un contournement supposé du problème OpenClaw.