DAO-Code ne s’ouvre pas sur macOS ? Guide de réparation des permissions et du PATH (2026)

Le fichier package.json de DAO-Code impose une version précise de Node.js : vérifiez donc d’abord l’exigence officielle, au lieu de réinstaller au hasard. Consultez la section concernée du fichier package.json, puis suivez cet ordre : which, chemin réel du fichier, version de Node.js, PATH, permissions, Gatekeeper, npm EACCES, et enfin l’API Key. Cette méthode permet de distinguer une commande introuvable d’un programme réellement bloqué.

Cette semaine, commencez par conserver le message d’erreur original et par noter votre architecture avec uname -m. Ne lancez pas sudo, ne désactivez pas les protections macOS et ne réinstallez pas DAO-Code avant d’avoir identifié la couche défaillante.

Cette page est destinée aux personnes qui exécutent dao et obtiennent command not found, aux utilisateurs bloqués par une alerte de sécurité macOS, ainsi qu’aux développeurs confrontés à npm EACCES ou à un échec d’authentification après le démarrage. Elle convient aussi aux utilisateurs d’Apple Silicon et de Mac Intel qui doivent vérifier qu’ils ont téléchargé le bon binaire.

Le symptôme visible ne désigne pas toujours la même panne

Avant de modifier votre environnement, copiez la commande saisie et les deux ou trois lignes exactes retournées par le terminal. Remplacez uniquement les informations sensibles : clé API, nom d’utilisateur, adresse interne et chemin privé. Le texte de l’erreur constitue votre première preuve.

Un point important : « ne s’ouvre pas » recouvre deux situations très différentes. Si le terminal ne trouve pas dao, macOS n’a pas encore essayé d’exécuter DAO-Code. Si la commande démarre puis échoue lors d’un appel à un modèle, le problème se situe plus loin, souvent dans la configuration ou l’authentification.

Première étape : retrouver l’installation avant de modifier le PATH

Commencez dans un nouveau terminal par :

uname -m
which dao
command -v dao
type -a dao
node --version
npm --version

which et command -v indiquent si le shell connaît déjà la commande. type -a peut révéler plusieurs installations concurrentes, par exemple une ancienne copie dans /usr/local/bin et une autre dans un dossier utilisateur. Une sortie vide ne prouve pas que DAO-Code est absent : elle prouve seulement que son emplacement n’est pas connu par le shell courant.

L’installation officielle doit être vérifiée dans le script et dans les instructions du projet. Le script install.sh de DAO-Code montre le répertoire utilisé par l’installation et la manière dont l’actif correspondant au système et à l’architecture est récupéré. La documentation d’installation officielle sert ensuite à comparer votre commande avec la procédure prévue.

Cherchez le fichier sans parcourir aveuglément tout le disque. Si vous connaissez le dossier cible indiqué par le script, examinez-le directement :

ls -la "$HOME/.local/bin"
ls -la "/usr/local/bin"

Adaptez le chemin au dossier réellement indiqué par le projet. Si vous trouvez un exécutable, testez-le avec son chemin complet :

"$HOME/.local/bin/dao" --version

Cette commande sépare deux diagnostics. Si la version s’affiche avec le chemin complet, le binaire fonctionne probablement et le problème est limité au PATH. Si macOS renvoie une erreur de permission, d’architecture ou de sécurité, l’ajout du chemin ne résoudra rien.

Après l’installation de DAO-Code, command not found signifie-t-il toujours que l’installation a échoué ?

Non. Le cas le plus fréquent est une installation placée dans un dossier que votre shell ne lit pas. Le shell peut aussi utiliser une configuration différente selon que vous ouvrez une session interactive, un script ou un terminal intégré à un éditeur. Vérifiez d’abord le fichier présent, puis seulement la configuration chargée.

Deuxième étape : corriger le PATH sans créer une configuration fragile

Affichez la valeur actuelle :

printf '%s\n' "$PATH"
echo "$SHELL"

Sur un Mac récent, le shell par défaut est généralement zsh, mais votre compte peut utiliser une autre configuration. Ne copiez pas une ligne trouvée dans un forum sans savoir quel fichier votre session lit. Pour une installation utilisateur, vous pouvez ajouter le dossier concerné à la fin du fichier adapté :

export PATH="$HOME/.local/bin:$PATH"

Pour tester cette modification uniquement dans le terminal actif :

export PATH="$HOME/.local/bin:$PATH"
command -v dao
dao --version

Si le test réussit, rendez la configuration persistante dans le fichier de démarrage approprié, puis ouvrez un nouveau terminal. Le nouveau terminal est indispensable : une modification enregistrée sur le disque ne change pas automatiquement l’environnement déjà chargé.

Évitez d’ajouter plusieurs fois le même dossier. Un PATH répété peut masquer l’ordre réel des versions et rendre le diagnostic difficile. Si type -a dao affiche plusieurs résultats, choisissez explicitement le chemin attendu, supprimez l’entrée obsolète de votre configuration et relancez le shell.

Voici le premier embranchement de décision :

• Si le chemin complet fonctionne et que command -v dao reste vide, corrigez le PATH, ouvrez une nouvelle session, puis testez la version.
• Si le chemin complet renvoie permission denied, inspectez les permissions avant de toucher au PATH.
• Si le chemin complet renvoie bad CPU type in executable, arrêtez la procédure PATH et passez au contrôle d’architecture.
• Si aucun fichier n’existe dans le dossier prévu, relisez l’installation officielle et son résultat avant de relancer le script.

Vous pouvez conserver cette méthode dans le centre d’aide en français de Hashvps avec votre relevé d’erreur. L’objectif est de garder une trace reproductible, pas d’accumuler des commandes correctives.

Troisième étape : distinguer permission Unix, quarantaine et Gatekeeper

Trois blocages sont souvent confondus.

Une permission Unix concerne le droit d’exécuter le fichier. Examinez-le avec :

ls -l /chemin/vers/dao
file /chemin/vers/dao

Si le fichier ne possède pas le bit d’exécution, une correction ciblée peut être envisagée :

chmod u+x /chemin/vers/dao

Ne donnez pas automatiquement des droits plus larges au fichier ou à tout le dossier. Le but est de permettre à votre utilisateur d’exécuter le binaire, pas de transformer l’environnement en zone ouverte.

La quarantaine macOS est un attribut associé à certains fichiers téléchargés. Vous pouvez l’inspecter :

xattr -l /chemin/vers/dao

La présence de com.apple.quarantine ne prouve pas que le fichier est malveillant. Elle indique que macOS applique une vérification supplémentaire liée à son origine. Avant toute action, comparez l’URL, le dépôt et l’actif avec les sources officielles. La documentation Apple sur Gatekeeper et la protection d’exécution explique le rôle de cette vérification.

Une alerte « développeur non identifié » est encore un autre cas. Apple documente une procédure ponctuelle pour ouvrir une application provenant d’un développeur non identifié, mais cette procédure ne remplace pas la vérification de la provenance. Les étapes officielles Apple pour une application bloquée doivent être suivies uniquement après contrôle du dépôt et de l’actif.

Attention : ne désactivez pas Gatekeeper au niveau du système pour faire disparaître une alerte DAO-Code. Vous perdriez une protection générale alors que le problème peut venir d’un mauvais téléchargement ou d’un fichier incomplet.

Comment traiter le blocage macOS Gatekeeper sans affaiblir tout le Mac ?

Vérifiez d’abord l’origine, le nom de l’actif et l’architecture. Si le projet fournit une procédure officielle, utilisez-la. Si l’alerte concerne un fichier inattendu, arrêtez-vous et récupérez une copie vérifiée. Une autorisation ponctuelle et documentée est très différente de la désactivation permanente des mécanismes de sécurité.

Quatrième étape : résoudre npm EACCES sans utiliser sudo par réflexe

npm EACCES signifie que npm tente d’écrire dans un emplacement auquel votre utilisateur n’a pas accès. Cela arrive souvent avec une installation globale utilisant un répertoire système, mais le message peut aussi révéler une configuration héritée d’une ancienne installation de Node.js.

Relevez d’abord les chemins :

npm config get prefix
npm root -g
node --version
npm --version

Comparez la version de Node.js avec la contrainte du projet dans le package.json officiel. Une version trop ancienne ou trop récente peut produire un échec différent d’un problème de permissions. Ne mélangez pas ces deux causes.

Pour EACCES, la documentation npm recommande une stratégie de gestionnaire de versions ou un répertoire global appartenant à l’utilisateur, plutôt que l’usage systématique de sudo. La documentation npm sur les erreurs de permissions lors des installations globales détaille ces options.

Votre décision peut suivre ce modèle :

• Si npm config get prefix pointe vers un dossier système et que l’installation globale échoue, utilisez un gestionnaire de versions Node.js ou configurez un préfixe dans votre dossier utilisateur.
• Si le préfixe est déjà utilisateur mais que EACCES persiste, inspectez le propriétaire du dossier et les permissions parent avant de modifier quoi que ce soit.
• Si la version Node.js ne respecte pas la contrainte du projet, changez de version avec votre gestionnaire de versions, puis recréez un terminal.
• Si l’installation se termine mais que dao est introuvable, revenez au diagnostic du PATH.

Évitez de réparer un répertoire entier avec chown -R sans connaître son contenu. Cette commande peut modifier des fichiers appartenant à d’autres outils et créer une nouvelle série de pannes.

Architecture : Apple Silicon et Intel ne doivent pas recevoir le même actif

Vérifiez votre architecture :

uname -m

Une sortie arm64 correspond à un Mac Apple Silicon ; x86_64 correspond à un Mac Intel. Inspectez ensuite le binaire téléchargé :

file /chemin/vers/dao

Le résultat doit être cohérent avec votre machine, ou indiquer une compatibilité multi-architecture lorsque le projet fournit un binaire universel. Le script officiel de DAO-Code prévoit le téléchargement d’un actif correspondant au système et à l’architecture. Vous pouvez contrôler cette logique directement dans install.sh.

DAO-Code téléchargé affiche bad CPU type in executable : faut-il forcer Rosetta ou réinstaller ?

Pas immédiatement. Relevez d’abord uname -m, file et le nom exact de l’actif. Sur Apple Silicon, un binaire Intel peut nécessiter une couche de compatibilité, mais cela ne corrige pas un fichier mal choisi ou incomplet. Sur Intel, un actif arm64 ne devient pas compatible par une simple modification du PATH. Téléchargez l’actif prévu par la documentation officielle, puis refaites le test avant de modifier l’architecture de votre terminal.

Cette vérification est également importante si vous utilisez un terminal intégré, une machine virtuelle ou une session distante. Le shell et le processus peuvent ne pas utiliser la même architecture apparente. Notez donc la sortie des commandes, et non seulement le modèle commercial du Mac.

API Key : un lancement réussi ne garantit pas une authentification réussie

Lorsque dao --version fonctionne mais qu’une requête de modèle échoue, vous avez déjà franchi la partie exécution. Ne modifiez ni les permissions du binaire ni les réglages de Gatekeeper pour résoudre une erreur distante.

Consultez la procédure de configuration et de démarrage dans la section Quick Start du README de DAO-Code. Vérifiez ensuite :

• le nom exact de la variable d’environnement attendue ;
• le fichier de configuration réellement lu par votre session ;
• l’absence d’espaces ou de caractères invisibles dans la clé ;
• l’état du compte et les droits associés au modèle demandé ;
• la validité de l’interface distante au moment du test.

Pour rechercher une variable sans afficher sa valeur, utilisez par exemple :

if [ -n "$DEEPSEEK_API_KEY" ]; then
  echo "La variable est définie"
else
  echo "La variable est absente"
fi

Adaptez le nom à celui indiqué par la documentation. Ne publiez jamais la sortie complète de env, un fichier .env, une capture d’écran non masquée ou un journal contenant la clé.

Comment réinitialiser la configuration de l’API Key de DAO-Code ?

Commencez par identifier l’emplacement utilisé : variable de session, fichier de configuration ou gestionnaire de secrets. Supprimez l’ancienne valeur uniquement après l’avoir remplacée de façon sûre, puis ouvrez une nouvelle session et testez une action minimale. Si la commande fonctionne mais que le modèle refuse la requête, vérifiez le compte, le modèle et le service distant ; une erreur de réseau ou de solde n’est pas une panne macOS.

Validation finale : six contrôles avant de reprendre le développement

Après la correction, ne vous contentez pas de voir une fenêtre s’ouvrir. Validez chaque couche :

• [ ] uname -m correspond à l’actif téléchargé ;
• [ ] file /chemin/vers/dao confirme le type attendu ;
• [ ] command -v dao renvoie le chemin prévu ;
• [ ] dao --version fonctionne dans un nouveau terminal ;
• [ ] une commande de lecture ou de diagnostic du projet s’exécute sans modification ;
• [ ] un appel contrôlé au modèle fonctionne sans exposer l’API Key ;
• [ ] après redémarrage du terminal, le PATH et la configuration restent présents.

Si l’échec réapparaît uniquement après redémarrage, le correctif était probablement temporaire. Si le binaire fonctionne avec le chemin complet mais pas dans un éditeur, comparez l’environnement de l’éditeur avec celui du terminal. Si plusieurs utilisateurs doivent reproduire l’installation, documentez le chemin, la version Node.js, l’architecture et les variables attendues.

Lorsque votre Mac contient des configurations npm anciennes, plusieurs gestionnaires Node.js et des autorisations modifiées au fil des essais, un environnement distant propre peut être plus rapide à valider qu’une nouvelle série de corrections locales. Vous pouvez comparer cette option avec les informations générales disponibles sur les solutions Mac de Hashvps, sans migrer avant d’avoir enregistré votre état initial et vos critères d’acceptation.

Un Mac local reste préférable si vous avez besoin de périphériques physiques, d’un accès permanent hors ligne ou d’une charge stable sur le long terme. En revanche, pour une équipe qui doit reproduire DAO-Code sans héritage de permissions, tester plusieurs architectures ou remettre rapidement un poste à zéro, votre configuration actuelle présente trois limites concrètes : les anciens PATH restent difficiles à auditer, les permissions npm peuvent varier d’un utilisateur à l’autre et l’historique Gatekeeper peut compliquer la reproduction du problème. Une location de Mac auprès de Hashvps peut alors offrir un environnement séparé, réinitialisable et préparé pour vos essais, à condition de conserver la même discipline : vérifier l’architecture, documenter les versions et masquer les secrets dans chaque rapport.