Comment installer Codex CLI sur Windows Mac Linux sans risque ?

J’installe Codex CLI proprement en préparant le terminal, l’authentification et surtout le bon dossier de travail. Le piège, c’est rarement la commande. C’est plutôt de lancer l’outil au mauvais endroit, avec trop de confiance, trop vite.

De quoi avez vous besoin avant l’installation ?

Avant d’installer Codex CLI, je prépare toujours trois choses simples : un terminal qui marche, un accès OpenAI, et surtout un dossier de projet propre. Ça paraît basique, mais c’est souvent là que les erreurs bêtes commencent.

Sur Windows, le plus simple est d’utiliser PowerShell. Pas besoin de lancer ça depuis un terminal exotique au début. WSL2, le sous-système Linux de Windows, peut être utile si vous travaillez déjà dans un environnement Linux, avec Git, Node, Python et vos outils dedans. Mais ce n’est pas obligatoire pour une installation Windows native. Si vous installez Codex CLI côté Windows, PowerShell suffit.

Sur macOS et Linux, je vérifie surtout que curl est disponible. Curl, c’est l’outil en ligne de commande qui permet de télécharger des fichiers ou d’appeler une URL depuis le terminal. Il est souvent déjà installé, mais je préfère le vérifier avant.

Élément	À vérifier
Windows	PowerShell prêt à lancer la commande d’installation
macOS ou Linux	curl disponible dans le terminal
Accès OpenAI	Compte ChatGPT, Device Code ou clé API
Dossier projet	Répertoire connu, contrôlé et digne de confiance

Côté authentification, vous aurez besoin d’un accès OpenAI. Selon votre usage, ça peut être un compte ChatGPT, une connexion via Device Code, c’est-à-dire un code temporaire à valider dans le navigateur, ou une clé API OpenAI. La clé API sert plutôt aux usages automatisés ou techniques, quand un outil doit appeler directement les services OpenAI.

Le point que je surveille le plus, c’est le dossier courant. Codex CLI prend le répertoire depuis lequel vous lancez la commande comme workspace, donc comme espace de travail. Plus tard, il pourra y lire des configurations locales, des hooks, c’est-à-dire des actions automatiques déclenchées à certains moments, et des politiques d’exécution. Donc je ne lance jamais ça depuis System32, Téléchargements, le bureau en vrac, ou un dossier que je ne comprends pas.

J’ai déjà vu un client lancer tous ses outils depuis le même vieux terminal ouvert dans un mauvais répertoire, par habitude. Avec un outil classique, ça passe souvent. Avec Codex CLI, c’est moins propre, parce que l’outil peut croire que ce dossier est votre projet. Et là, il analyse ou applique des règles au mauvais endroit.

Je préfère créer ou ouvrir un vrai dossier projet, puis vérifier où je suis avant de continuer.

pwd
# Ou sur Windows PowerShell
Get-Location

Quelle commande utiliser pour installer Codex CLI ?

La commande dépend surtout de votre système, mais le principe ne change pas beaucoup. Vous installez Codex CLI, puis vous vérifiez qu’il est accessible depuis le terminal avec la commande codex.

Sur macOS et Linux, la méthode directe passe par curl. Curl télécharge le script d’installation, puis sh l’exécute dans le terminal. C’est rapide, mais comme toujours avec ce type de commande, je vérifie que l’URL est bien l’URL officielle avant de coller ça dans un shell.

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

Sur Windows, je passe par PowerShell. La commande utilise irm, qui récupère le script, puis iex, qui l’exécute. ExecutionPolicy ByPass autorise l’exécution pour cette commande, sans changer toute votre configuration PowerShell.

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

L’installateur Windows ajoute normalement Codex au PATH. Le PATH, c’est la liste des dossiers dans lesquels votre terminal cherche les commandes. Grâce à ça, vous pouvez taper codex depuis n’importe quel dossier. À la fin, l’installateur peut aussi proposer de lancer l’application. Je réponds N si mon terminal n’est pas déjà placé dans le bon dossier projet. Sinon Codex démarre au mauvais endroit, et on perd du temps pour rien.

Il y a aussi des alternatives propres selon votre environnement. Je préfère l’installateur officiel quand je veux aller vite, Homebrew quand je veux garder une machine propre, npm quand le poste est déjà orienté JavaScript. Chez un client avec beaucoup de développeurs front, npm était logique. Sur mon Mac perso, je préfère Brew, c’est plus simple à maintenir.

Système ou outil	Commande	Quand l’utiliser
macOS Linux	curl -fsSL https://chatgpt.com/codex/install.sh | sh	Installation directe depuis le terminal
Windows PowerShell	powershell -ExecutionPolicy ByPass -c « irm https://chatgpt.com/codex/install.ps1 | iex »	Installation native Windows
Homebrew	brew install –cask codex	Gestion propre des outils sur macOS
npm	npm install -g @openai/codex	Environnement Node.js déjà en place

Comment lancer Codex CLI la première fois ?

Je lance toujours Codex CLI depuis le dossier du projet, jamais depuis un dossier pris au hasard. C’est un réflexe simple, mais il évite pas mal de bêtises, surtout quand l’outil va lire, modifier ou créer des fichiers.

J’ouvre un terminal, puis je me place dans le bon dossier avec cd. Ensuite seulement, je lance codex.

cd chemin/du/projet
codex

Le point important, c’est que Codex utilise le répertoire courant comme workspace. Le workspace, c’est simplement le dossier de travail que Codex va considérer comme le projet actif. Donc le chemin affiché dans votre terminal compte vraiment.

Sur Windows, je fais particulièrement attention à un cas classique. Si vous ouvrez un terminal en mode administrateur, il peut démarrer dans C:\Windows\System32. Et clairement, ce n’est pas un dossier à approuver pour travailler avec un assistant de code. Si vous voyez System32 dans le prompt, vous faites d’abord un cd vers votre projet.

Au premier lancement, Codex va vous demander comment vous voulez vous authentifier. En général, vous avez trois options.

• Sign in with ChatGPT : Je l’utilise quand je veux connecter Codex à mon abonnement ChatGPT.
• Sign in with Device Code : Je le prends pour une machine en SSH, un container, ou un environnement qui ne peut pas ouvrir correctement le retour navigateur.
• Clé API : Je l’utilise quand je veux facturer l’usage via mon compte OpenAI Platform, donc avec la facturation API classique.

Le passage navigateur est assez simple. Codex affiche ou ouvre une URL, vous vous connectez avec le bon compte, vous vérifiez l’identité affichée, puis vous revenez dans le terminal après la page de succès. Si un code est affiché, vous le copiez dans la page demandée, puis vous validez.

Je fais aussi très attention aux environnements partagés. Si plusieurs comptes sont connectés dans le navigateur, vérifiez deux fois avant d’autoriser. J’ai déjà vu une équipe autoriser un outil sur le mauvais compte juste parce que Chrome avait gardé une session perso ouverte. Ça prend dix secondes à contrôler, et ça évite une vraie galère derrière.

Pourquoi faut il faire confiance au bon dossier ?

Quand Codex CLI vous demande de faire confiance à un dossier, ce n’est pas une formalité. C’est le moment où vous lui dites : “Oui, tu peux travailler ici, avec ce contexte-là”. Et franchement, c’est une des étapes que je prends au sérieux, surtout sur une machine où il y a plusieurs projets, des clés, des fichiers clients ou des vieux dossiers qui traînent.

Codex affiche le répertoire qu’il s’apprête à approuver. Il faut lire le chemin complet, pas juste appuyer sur Entrée par réflexe. Un chemin comme C:\Users\franck\projets\client-a, ce n’est pas pareil que C:\Users\franck ou pire, un dossier système. Plus le dossier est large, plus vous donnez de contexte à l’outil.

La confiance permet à Codex de charger des configurations locales, des hooks et des règles d’exécution. Un hook, c’est simplement un script qui peut se lancer automatiquement à certains moments, par exemple avant une commande ou après une modification. C’est pratique dans un projet maîtrisé. C’est beaucoup moins drôle dans un dossier que vous n’avez pas vérifié.

Si le chemin affiché n’est pas le bon, je ne cherche pas à rattraper le coup. Je quitte Codex, je me replace dans le bon dossier avec le terminal, puis je relance codex. C’est simple, propre, et ça évite de donner accès à trop de choses sans le vouloir.

Après l’authentification, Codex confirme aussi le compte utilisé et affiche un message sur les paramètres d’autonomie. L’autonomie, c’est le niveau de liberté que vous laissez à l’outil : ce qu’il peut décider seul, ce qu’il doit demander, et les permissions disponibles. Vous pouvez les relire ou les modifier plus tard avec /permissions.

Sur Windows, Codex peut aussi proposer de créer un bac à sable, ou sandbox. Le mode que je garde quand c’est possible, c’est le mode par défaut recommandé avec élévation. Il utilise des utilisateurs de moindre privilège, une isolation du système de fichiers, des règles firewall et des policies locales. Le mode non-admin existe, mais il protège moins. Si je peux approuver l’élévation dans un cadre maîtrisé, je choisis le sandbox recommandé.

Décision	Bon réflexe
Chemin affiché incorrect	Quitter et relancer dans le bon dossier
Dossier système	Ne pas le marquer comme fiable
Notice d’autonomie	Lire puis valider consciemment
Windows sandbox	Préférer le mode par défaut recommandé

Quel premier prompt envoyer sans risque ?

Une fois Codex CLI installé et configuré, je ne lance jamais une grosse demande dès le départ. Je sais que c’est tentant, surtout quand on veut tester vite, mais le premier prompt doit rester en lecture seule. Le but, c’est d’observer comment l’outil se comporte avant de lui laisser toucher au projet.

Je ne commence donc pas par une commande du style “Refactorise tout le projet” ou “Corrige tous les fichiers”. C’est trop large, trop flou, et surtout trop tôt. À ce stade, je veux juste vérifier que Codex comprend où il est, ce qu’il voit, et ce qu’il peut faire.

Je préfère envoyer une demande simple, par exemple :

Analyse la structure de ce projet sans modifier les fichiers.

Ou alors :

Liste les fichiers importants et explique leur rôle.

Ou encore :

Repère les points à vérifier dans ce dépôt sans écrire de changement.

Cette première interaction sert à vérifier trois choses très concrètes :

• Codex voit bien le bon dossier, pas un répertoire parent, pas un ancien projet, pas un dossier vide.
• L’authentification fonctionne, donc l’outil peut répondre correctement avec votre session active.
• Les permissions et le sandbox se comportent comme prévu. Le sandbox, c’est l’environnement contrôlé qui limite ce que Codex peut lire, modifier ou exécuter.

Toute la configuration faite avant a un but simple : garder le contrôle. Pas faire joli. Pas cocher des cases. Juste éviter qu’un assistant de code dans le terminal parte trop vite dans une direction qu’on n’a pas validée.

Dans mes accompagnements, je fais toujours une première passe en lecture seule, surtout avec des équipes qui découvrent ce type d’outil. J’ai vu des développeurs très bons être surpris juste parce que l’assistant avait analysé le mauvais dossier ou proposé des changements trop ambitieux. Une analyse simple au départ évite ça. Ça pose le cadre, ça rassure, et ça donne confiance pour la suite.

Prompt	Pourquoi
Analyse ce projet sans modifier les fichiers	Bon test en lecture seule
Liste les fichiers clés et leur rôle	Permet de vérifier le contexte
Refactorise tout le projet	Trop large pour un premier essai
Corrige tous les bugs automatiquement	Trop risqué avant validation des permissions

On l’installe maintenant proprement ?

Installer Codex CLI, ce n’est pas compliqué. Le vrai sujet, c’est de le lancer dans le bon dossier, avec le bon compte et les bonnes permissions. Je prépare le terminal, j’installe avec la commande adaptée, je me place dans un projet fiable, puis je choisis l’authentification qui colle à mon usage. Sur Windows, je garde le sandbox recommandé quand c’est possible. Et je commence toujours par un prompt en lecture seule. Cette méthode évite les erreurs bêtes, les dossiers mal approuvés et les modifications trop rapides. Vous gagnez surtout un démarrage propre, maîtrisé et beaucoup plus serein.

FAQ

• Codex CLI fonctionne sur Windows macOS et Linux ?
  Oui, Codex CLI peut être installé sur Windows avec PowerShell, et sur macOS ou Linux avec curl. Il existe aussi des méthodes alternatives avec Homebrew et npm selon votre environnement.
• Faut il un compte ChatGPT pour utiliser Codex CLI ?
  Vous pouvez vous connecter avec un compte ChatGPT, utiliser un Device Code pour certains environnements comme SSH ou containers, ou fournir une clé API OpenAI si vous voulez passer par la facturation OpenAI Platform.
• Pourquoi éviter de lancer Codex CLI depuis System32 ?
  Parce que Codex CLI utilise le répertoire courant comme workspace. System32 est un dossier système, pas un projet de travail. Il ne faut pas le marquer comme dossier de confiance.
• À quoi sert le sandbox Windows de Codex CLI ?
  Le sandbox limite les risques pendant l’exécution. Le mode par défaut recommandé utilise notamment une élévation contrôlée, des utilisateurs de moindre privilège, une isolation du système de fichiers et des règles réseau.
• Quel premier prompt envoyer après l’installation ?
  Je commence par une demande en lecture seule, par exemple analyser la structure du projet sans modifier les fichiers. Ça permet de vérifier le dossier, l’authentification et les permissions avant toute modification.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent utiliser l’IA de façon concrète, propre et sécurisée, pas juste tester des outils dans un coin. Avec webAnalyste et Formations Analytics, j’ai travaillé pour Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres. Si vous voulez structurer vos usages IA, automatiser vos process ou former vos équipes, contactez-moi.