Déploiement 2026 d’OpenAI Codex CLI sur Mac : guide sûr

Le terminal a refusé une commande, puis l’accès complet au disque a été accordé à Codex CLI pour « régler le problème ».

La solution la plus sûre est inverse : commencez par un petit dépôt sans secrets, utilisez read-only ou workspace-write, conservez les validations et ne passez à un Mac séparé ou à un Mac distant que si le travail est sensible, long ou non surveillé.

Cet article s’adresse aux développeurs indépendants qui veulent éviter une modification accidentelle de leur Mac, aux équipes qui préparent un essai sur un vrai dépôt et aux administrateurs chargés de livrer un environnement réinitialisable et contrôlable.

Dernière mise à jour : 2 août 2026. Les informations techniques ont été vérifiées dans la documentation officielle d’OpenAI, le dépôt officiel Codex et ses publications disponibles à cette date.

Le périmètre avant l’installation

Avant d’installer OpenAI Codex CLI, vous devez répondre à trois questions : quelles données l’agent peut-il lire, combien de temps doit-il fonctionner et qui doit intervenir s’il demande une autorisation ?

Cette étape évite l’erreur la plus fréquente : traiter une restriction gênante comme un simple problème de configuration. Un agent de codage peut lire des fichiers, modifier le dépôt, lancer des tests, appeler un gestionnaire de paquets ou accéder au réseau selon le mode choisi. Le risque ne dépend donc pas uniquement du modèle. Il dépend du périmètre concret dans lequel vous le faites agir.

Un dossier de travail doit être explicite. Utilisez par exemple un répertoire dédié au projet :

mkdir -p ~/Codex-lab/projet-test
cd ~/Codex-lab/projet-test

Ne lancez pas l’outil depuis votre dossier personnel, depuis la racine d’un disque externe ou depuis un répertoire contenant vos clés SSH, vos fichiers .env, vos certificats et vos réglages privés. Le dossier courant et certains répertoires temporaires peuvent faire partie de l’espace de travail détecté par Codex ; la commande /status permet de vérifier les chemins concernés. (vérifier le périmètre et les validations)

Le choix initial peut suivre cette règle :

Codex CLI peut-il accéder directement à tout votre dépôt local ? Oui, si vous lui donnez ce périmètre et les autorisations correspondantes. Mais ce n’est pas une bonne configuration de départ. Commencez par une copie réduite, sans secrets et avec un objectif réversible.

Pour les cas où vous n’avez pas de machine de secours, vous pouvez aussi examiner les environnements Mac disponibles dans la console MacHTML, sans confondre cette option avec une garantie automatique de sécurité : le réseau, les identifiants et les règles Codex restent à configurer.

L’installation et l’identité utilisées

La documentation officielle indique que Codex CLI prend en charge macOS 12 ou version ultérieure. Le dépôt officiel précise également une exigence minimale de 4 Go de mémoire vive, avec 8 Go recommandés pour l’installation et l’utilisation courante. Ces données décrivent la compatibilité générale, pas la stabilité d’un long travail dans votre projet. (consulter les instructions officielles d’installation)

Pour une installation sur Mac, privilégiez une source publiée par OpenAI. Le dépôt officiel propose notamment le script autonome, npm, Homebrew et les binaires des publications. Pour une équipe, le script ou le binaire versionné est plus facile à consigner qu’une installation laissée à la résolution automatique d’un gestionnaire de paquets. (voir le dépôt officiel Codex)

Exemple de procédure à documenter dans votre fiche d’environnement :

curl -fsSL https://chatgpt.com/codex/install.sh | sh
codex --version
command -v codex

Le but n’est pas seulement d’obtenir une commande fonctionnelle. Vous devez conserver :

• la source d’installation utilisée ;
• la version retournée par codex --version ;
• le chemin retourné par command -v codex ;
• l’architecture du Mac ;
• l’identité active ;
• le chemin du fichier de configuration ;
• la date de l’installation.

Évitez de recopier une commande trouvée dans une discussion communautaire sans la comparer aux instructions officielles. Les tickets GitHub peuvent signaler un échec ponctuel sur une version de macOS ou de Node, mais ils ne prouvent pas qu’un problème touche toutes les installations. Un ticket récent lié à macOS et à un binaire natif doit donc être utilisé comme piste de diagnostic, non comme règle générale.

Codex CLI propose deux voies d’authentification principales. La connexion avec ChatGPT applique les droits, le rôle et les règles du compte ou de l’espace de travail ChatGPT. La clé API suit les règles de l’organisation API et sa facturation à l’usage. Ces chemins ne sont donc pas interchangeables du point de vue de l’administration. (consulter les méthodes d’authentification)

Pour une session interactive sur votre Mac, vous pouvez commencer par :

codex login
codex login status

Pour un flux automatisé, l’authentification par clé API est plus adaptée, mais la clé doit être dédiée à la tâche, limitée autant que possible et révocable. La documentation officielle indique que les identifiants peuvent être conservés dans ~/.codex/auth.json ou dans le trousseau de secrets du système selon le mode utilisé. Ce fichier doit donc entrer dans votre inventaire de protection.

La première heure et les permissions

Le premier lancement ne doit pas commencer par le dépôt de production. Créez un dépôt de test contenant :

• quelques fichiers source ;
• un test qui échoue volontairement ;
• un fichier factice ressemblant à une configuration ;
• aucun jeton, certificat ou secret réel ;
• un historique Git permettant de revenir à l’état initial.

Sur macOS, la sandbox s’appuie sur le mécanisme Seatbelt intégré au système. Elle s’applique non seulement aux opérations de fichiers, mais aussi aux commandes lancées par l’agent, comme Git, les tests et les gestionnaires de paquets. (lire le fonctionnement de la sandbox)

Pour une première vérification, utilisez un mode explicitement restrictif :

codex --sandbox read-only --ask-for-approval on-request

Dans ce mode, Codex peut examiner les fichiers, mais doit demander une validation avant une modification, l’exécution de commandes ou l’accès réseau. Le mode workspace-write autorise les modifications dans l’espace de travail, tout en conservant des validations pour les opérations hors périmètre ou nécessitant le réseau.

La configuration de départ la plus équilibrée pour un dépôt Git de test est généralement :

codex --sandbox workspace-write --ask-for-approval on-request

Cela ne signifie pas que toute commande devient sûre. Le réseau reste désactivé par défaut dans workspace-write, sauf si vous l’activez dans la configuration :

[sandbox_workspace_write]
network_access = true

L’activation du réseau doit correspondre à un besoin précis : télécharger une dépendance, consulter une documentation ou appeler un service de test. Elle ne doit pas devenir une autorisation permanente simplement parce qu’une commande a échoué.

Quelles permissions faut-il ouvrir à OpenAI Codex CLI sur Mac ? Commencez par la lecture seule, puis autorisez l’écriture dans un seul espace de travail. Ajoutez le réseau uniquement pour une commande identifiée. Réservez danger-full-access et les options qui contournent les validations aux environnements déjà isolés, jamais au Mac principal par défaut. La documentation officielle décrit ce mode comme une exécution sans sandbox et sans approbation ; il est explicitement déconseillé pour un usage courant. (lire les règles de sécurité et d’approbation)

Pendant cette première heure, vérifiez quatre comportements :

1. la commande /status affiche bien le répertoire attendu ;
2. une demande de lecture d’un fichier extérieur est refusée ou soumise à validation ;
3. une modification dans le dépôt laisse une différence visible avec git diff ;
4. une commande réseau s’arrête lorsque l’accès n’est pas autorisé.

Vous pouvez tester le comportement de la sandbox macOS avec la commande prévue par la documentation :

codex sandbox macos --log-denials -- COMMAND

Le nom exact de l’option ou du profil doit être contrôlé dans la version installée avant d’être intégré à une procédure d’équipe.

Le premier dépôt réel et les secrets

Le premier travail réel doit être petit, réversible et facile à relire. Une correction de documentation, un test isolé ou une fonction sans accès aux données sensibles convient mieux qu’une migration de schéma ou qu’un déploiement.

Créez une branche dédiée :

git switch -c codex-pilote
git status

Puis demandez une action limitée. Après chaque étape, inspectez le résultat :

git diff --stat
git diff --name-only
git diff --check

L’objectif est de prouver que Codex CLI ne modifie que les chemins autorisés et que chaque changement peut être annulé. Ne donnez pas à l’agent votre fichier .env principal, vos clés de production ou votre configuration SSH habituelle. Préparez plutôt un secret de test, avec une portée minimale et une révocation immédiate possible.

Comment isoler une clé API et les fichiers de configuration sur macOS ? Utilisez un compte macOS distinct ou un répertoire CODEX_HOME séparé lorsque votre procédure le permet, puis fournissez uniquement les variables nécessaires au travail. Ne montez pas votre dossier personnel complet dans un environnement distant et ne copiez pas automatiquement vos clés depuis le trousseau du Mac principal.

Pour une équipe, l’approbation doit rester compréhensible. Une demande d’installation de paquet doit indiquer le paquet, la version visée, le registre utilisé et la raison. Une demande d’accès à Internet doit préciser le domaine ou le service attendu. Une demande d’écriture hors du dépôt doit être refusée tant que son effet n’est pas démontré.

Le long travail et la reprise

Un travail interactif de quelques minutes n’a pas les mêmes contraintes qu’une exécution non surveillée. Pour la seconde catégorie, vous devez tester au minimum la fermeture du terminal, la mise en veille, une coupure réseau et un échec de commande.

Ne concluez pas qu’une session est fiable parce qu’elle a terminé une fois. Préparez un test interrompu :

1. lancez une tâche sur un dépôt de démonstration ;
2. notez l’état Git et les fichiers modifiés ;
3. fermez le terminal ou interrompez volontairement le processus ;
4. vérifiez l’état du dépôt ;
5. relancez la tâche ou reprenez-la selon le mécanisme prévu ;
6. comparez les changements avant et après la reprise ;
7. documentez ce qui doit être relancé manuellement.

La stabilité et la reprise ne doivent pas être présentées comme garanties générales. Elles dépendent de la version de Codex CLI, de macOS, du réseau, de la commande exécutée, de la veille du Mac et du dépôt concerné. Si votre Mac principal est régulièrement fermé, redémarré ou utilisé pour une visioconférence, il ne constitue pas une bonne machine pour un agent long qui doit rester disponible.

Un Mac distant est pertinent lorsque vous avez besoin d’un environnement séparé, accessible à distance et réinitialisable. Il ne supprime toutefois pas les risques : vous devez encore protéger la session, limiter les secrets, contrôler les accès réseau et prévoir la destruction de l’environnement après le test. Pour les étapes de connexion, de livraison et de réinitialisation, consultez le centre d’aide MacHTML avant de préparer un environnement destiné à une équipe.

L’acceptation de la première semaine

Après plusieurs jours d’essai, ne validez pas l’environnement sur la seule impression de confort. Utilisez cinq familles de preuves : périmètre, écriture, secrets, reprise et relecture.

• [ ] Le dépôt de test ne contient aucun secret réel.
• [ ] Le chemin de travail est affiché et documenté.
• [ ] Le mode read-only a été testé avant workspace-write.
• [ ] Les modifications hors dépôt déclenchent une validation ou sont bloquées.
• [ ] L’accès réseau est désactivé par défaut ou limité à un besoin documenté.
• [ ] Une commande d’installation de paquet a été approuvée séparément.
• [ ] La clé de test peut être révoquée sans toucher aux autres projets.
• [ ] codex login status permet de confirmer l’identité active.
• [ ] codex logout a été testé sur l’environnement de démonstration.
• [ ] Une interruption du terminal laisse un état Git identifiable.
• [ ] La reprise ne crée pas de modifications silencieuses ou dupliquées.
• [ ] Le retour arrière avec Git a été effectué sur une tâche réelle mais non critique.
• [ ] La version installée, sa source et le chemin du binaire sont enregistrés.
• [ ] Le choix entre Mac principal, compte séparé, Mac de secours et Mac distant est écrit.
• [ ] Une règle précise indique quand l’utilisation doit être arrêtée.

Pour un projet personnel peu sensible et court, le Mac principal peut rester acceptable avec workspace-write, des validations à la demande et un dépôt séparé. Pour un dépôt confidentiel, plusieurs projets simultanés ou une tâche qui doit continuer sans présence humaine, privilégiez un compte distinct, une machine de secours ou un environnement Mac distant.

Le choix entre Mac local et Mac distant

Le Mac local reste le plus simple pour examiner immédiatement les changements, utiliser vos outils audio ou vidéo et conserver un flux de travail créatif autour de Xcode, Final Cut ou des scripts de design. Son défaut est évident : il partage votre espace de travail quotidien, vos sessions ouvertes et vos fichiers personnels.

Le Mac distant apporte une séparation plus nette et convient mieux aux essais réinitialisables, aux tâches longues et aux environnements livrés à plusieurs personnes. En contrepartie, vous dépendez de la connexion, de la latence et de la procédure d’accès à distance. Il ne faut pas le choisir uniquement parce que le mot « distant » semble plus sécurisé.

Vous pouvez examiner les environnements Mac disponibles dans la console MacHTML, puis comparer l’environnement réellement nécessaire à votre tâche. Si vous devez seulement corriger quelques fichiers en présence, la location n’apportera pas forcément un avantage. Si vous devez laisser un agent travailler sur un dépôt isolé, avec une machine réinitialisable et une disponibilité continue, elle devient plus cohérente.

L’erreur initiale — ouvrir trop de permissions pour supprimer une erreur — reste le meilleur signal d’alerte. Le Mac principal est pratique, mais il mélange souvent fichiers privés, identifiants, projets et sessions personnelles. Une machine distante mal configurée reproduit exactement le même défaut ailleurs. La location d’un Mac auprès de MacHTML offre surtout un environnement séparé et plus facile à remettre à zéro ; elle améliore l’expérience lorsque vous avez besoin d’un essai isolé ou d’une tâche continue, pas lorsqu’elle sert à éviter la configuration de sécurité.

Commencez par appliquer la liste de validation sur un dépôt non productif, conservez la version installée et les règles d’approbation, puis choisissez l’environnement qui correspond à la durée, à la sensibilité et au niveau de surveillance réellement nécessaires.