Utilisation sous Windows : environnement natif ou WSL, comment choisir la solution la plus simple

📚 Navigation de la série : Le chapitre précédent 〔32 Migrer depuis Claude Code〕 expliquait comment effectuer une transition en douceur vers Codex. Ce chapitre s'adresse spécifiquement aux utilisateurs de Windows : alors que les chapitres précédents supposaient l'utilisation de macOS ou Linux, Windows impose ses propres règles en matière de chemins de fichiers, de sauts de ligne et de sandbox. Le chapitre suivant 〔34 Projet de synthèse〕 combinera l'ensemble de ces connaissances dans un cas pratique réel.

Commençons par une erreur que j'ai commise moi-même.

En mars 2026, lors de ma première installation de Codex sur mon ordinateur portable professionnel sous Windows 11, j'ai voulu simplifier les choses en n'utilisant pas WSL. J'ai exécuté l'installation directement dans PowerShell. Tout semblait opérationnel, mais la modification des fichiers échouait systématiquement. Après analyse des logs, j'ai constaté que le projet cloné depuis mon dépôt macOS contenait des scripts configurés avec des sauts de ligne LF. Git sous Windows les avait automatiquement convertis au format CRLF. Lors de l'enregistrement par Codex, le diff de code affichait le caractère ^M sur chaque ligne, marquant tout le fichier comme modifié. J'ai d'abord cru à un bug de Codex avant de réaliser qu'il s'agissait simplement d'une mauvaise configuration des sauts de ligne sous Windows.

En vérité, s'exécuter de manière native sous Windows est tout à fait possible et performant, mais cela diffère de macOS et Linux. La gestion de la sandbox comporte deux modes spécifiques à Windows, les chemins de fichiers utilisent des barres obliques inverses (antislashs), et la gestion des sauts de ligne nécessite des ajustements. Mieux vaut connaître ces spécificités pour éviter les erreurs.

Ce chapitre détaille la gestion de Codex sous Windows : la procédure d'installation, le choix entre exécution native et WSL2, la résolution des trois erreurs courantes propres à Windows, les spécificités de la sandbox, et un exercice pratique d'exécution de tâche sous PowerShell.

Ce que vous obtiendrez après avoir lu ce chapitre :

• La recommandation officielle sur la méthode d'exécution la plus simple sous Windows pour éviter les hésitations.
• Le guide d'installation de Codex à l'aide du script officiel PowerShell, avec la liste des dépendances prérequises.
• Un comparatif « Exécution native PowerShell vs WSL2 » pour vous guider selon vos habitudes de travail.
• Les solutions pour éviter les trois écueils classiques sous Windows : antislashs dans les chemins, sauts de ligne CRLF et avertissements de sécurité de type Everyone.
• L'analyse des modes de sandbox elevated et unelevated spécifiques à Windows, et la résolution de l'erreur 1385.
• Un guide pas à pas pour exécuter votre première tâche Codex sous Windows.

⚠️ Les commandes, options de configuration et comportements par défaut décrits se réfèrent à la documentation officielle de Codex. Les noms de modèles, abonnements et numéros de versions pouvant évoluer, fiez-vous aux commandes codex --help et aux affichages de votre terminal. Veillez à lancer les commandes dans le shell approprié (PowerShell ou WSL) comme indiqué.

---

01 Recommandation officielle : le choix le plus simple sous Windows

Voici la recommandation officielle pour vous guider dans votre choix :

Privilégiez la configuration « Windows natif + sandbox elevated ». C'est la méthode recommandée, offrant les meilleures performances sans aucun compromis sur la sécurité. L'utilisation de WSL2 doit être réservée aux flux de travail déjà exécutés sous Linux ou en cas d'impossibilité technique de faire fonctionner les sandbox natives de Windows.

Les conseils suggérant d'utiliser systématiquement WSL ou le mode unelevated ne sont plus d'actualité. La documentation officielle stipule désormais que la sandbox native sous Windows offre les meilleures performances de rapidité et d'isolation, le mode elevated devant être choisi en priorité, le mode unelevated constituant une solution de secours.

Analogie : Choisir son type de connexion Internet. La connexion par fibre optique (mode elevated) est à privilégier car elle est la plus rapide et la plus stable. Si des contraintes techniques ou l'IT de votre entreprise empêchent son installation, vous pouvez vous rabattre sur un câble réseau classique (mode unelevated). L'option de travailler depuis les locaux d'un voisin équipé (WSL2) ne doit être envisagée qu'en dernier recours. Pour la majorité des utilisateurs, la première solution convient directement.

Selon les profils, le choix s'établit ainsi :

• Vous développez principalement sous Windows avec les outils Windows : utilisez l'environnement natif en mode elevated.
• Vous utilisez un ordinateur professionnel verrouillé par l'IT sans droits d'administrateur : utilisez le mode unelevated de manière native, tout en effectuant une demande d'accès auprès de votre administrateur.
• Vos projets s'exécutent déjà dans WSL avec les outils Linux : utilisez directement WSL2 de bout en bout pour éviter les allers-retours entre environnements.

💡 Résumé en une phrase : La configuration par défaut recommandée est « Windows natif + sandbox elevated », WSL2 étant destiné aux flux de travail déjà hébergés sous Linux.

---

02 Installation et dépendances prérequises

Sous Windows, la méthode recommandée pour installer Codex CLI consiste à utiliser le script d'installation officiel PowerShell.

Exécutez la commande suivante dans PowerShell ou Windows Terminal :

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

Si Node.js est déjà présent sur votre système, vous pouvez utiliser le gestionnaire npm :

npm install -g @openai/codex

Redémarrez votre terminal après l'installation pour appliquer la mise à jour de la variable d'environnement PATH, puis validez :

codex --version

Le terminal doit afficher la version installée sous la forme codex 0.x.x.

Si vous préférez une interface graphique à la ligne de commande, l'application officielle Codex pour Windows est téléchargeable sur le Microsoft Store, ou via la commande winget : winget install Codex -s msstore. Ce chapitre se concentre sur l'outil en ligne de commande codex.

Dépendances nécessaires à réunir pour éviter les erreurs :

Dépendance	Utilité	Installation / Configuration
Windows 11 (recommandé)	Environnement de référence validé	Mise à jour vers Windows 11 ; Windows 10 est supporté à partir de la version 1809
Outil winget fonctionnel	Requis pour installer les outils de compilation C++ et l'application graphique	Mettre à jour Windows ou installer le package App Installer
Droits d'administrateur	Requis pour initialiser la sandbox en mode elevated	Valider la demande UAC ; requiert l'intervention de l'IT sur les postes professionnels
Outils de build C++	Requis pour la compilation de certaines dépendances de l'extension IDE	winget install --id Microsoft.VisualStudio.2022.BuildTools -e

Si vous utilisez l'extension VS Code et que celle-ci reste bloquée lors de l'initialisation, vérifiez que les outils de build Visual Studio pour C++ sont installés. Lancer la commande winget install ci-dessus puis redémarrer VS Code résout généralement le problème. Pensez à installer ces outils dès le départ si vous développez avec VS Code.

💡 Résumé en une phrase : Le CLI s'installe via une commande PowerShell unique. Assurez-vous de disposer de Windows 11, de winget actif, des droits d'administrateur, et ajoutez les outils de build C++ si vous utilisez VS Code.

---

03 WSL vs PowerShell natif : quel environnement choisir

Il s'agit d'une décision importante pour les développeurs Windows. Le choix dépend principalement de l'emplacement de votre code et de vos outils.

Analogie : Choisir son domicile fiscal. Travailler en PowerShell natif équivaut à s'installer sous Windows : vous utilisez les processus de Windows pour toutes vos démarches, ce qui est le plus rapide. Utiliser WSL2 équivaut à louer un logement dans un autre pays (Linux) : vous devez entrer dans cet espace pour exécuter les outils et les scripts Linux. Les deux options sont valables, mais il convient d'éviter de transférer constamment vos fichiers de l'un à l'autre : définissez un espace de travail principal.

Tableau comparatif des environnements :

Critère	PowerShell natif	WSL2
Simplicité d'installation	✅ Script d'installation en une ligne	❌ Nécessite l'installation préalable de WSL via wsl --install
Performances d'exécution	✅ Performances maximales	File I/O plus lente pour les accès inter-environnements
Implémentation sandbox	Spécifique à Windows (elevated/unelevated)	Sandbox Linux standard (bubblewrap)
Compatibilité outils	✅ Outils Windows natifs et fichiers .exe	✅ Outils Linux et scripts bash
Profil recommandé	Majorité des développeurs Windows	Développeurs disposant déjà de projets sous Linux

Quand choisir PowerShell natif ? Si vous développez de manière standard sous Windows avec VS Code et utilisez les outils Windows (Git, compilateurs Windows), restez en PowerShell natif.

Quand choisir WSL2 ? Si vous dépendez d'outils propres à Linux, si vos projets sont déjà clonés dans WSL2 ou si le mode sandbox natif de Windows est bloqué sur votre système.

Pour utiliser WSL2, installez l'environnement dans un terminal PowerShell ouvert en tant qu'administrateur :

wsl --install
wsl

Une fois dans le shell WSL, installez Codex au sein de l'environnement Linux (la version installée sous Windows n'étant pas accessible directement) :

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

Un piège de performance important : évitez de placer vos projets dans le répertoire /mnt/c/Users/... (qui correspond au disque C de Windows monté sous Linux). Les accès fichiers entre WSL et Windows ralentissent considérablement l'exécution des commandes Git et de Codex. Clonez vos dépôts directement dans le répertoire utilisateur Linux :

mkdir -p ~/code && cd ~/code
git clone https://github.com/votre/projet.git
cd projet

Les fichiers restent accessibles depuis Windows via l'explorateur en saisissant le chemin \\wsl$\Ubuntu\home\<utilisateur> (en remplaçant <utilisateur> par votre identifiant Linux). Notez que Codex requiert WSL2 à partir de la version 0.115 (en raison de l'usage de la sandbox bubblewrap). La configuration par défaut de WSL étant désormais la version 2, vous n'avez pas de modification particulière à effectuer.

💡 Résumé en une phrase : Si votre code est sous Windows, utilisez PowerShell natif. S'il est sous Linux, utilisez WSL2 en veillant à cloner vos projets dans le répertoire ~/ de Linux pour préserver les performances.

---

04 Résoudre les trois erreurs courantes sous Windows : chemins, sauts de ligne et permissions

Windows possède des spécificités de gestion système qui peuvent générer des erreurs inexistantes sous macOS ou Linux.

1. La syntaxe des chemins de fichiers (antislashs)

Windows utilise les barres obliques inverses (C:\Dossier\Projet) tandis qu'Unix utilise les barres obliques (/home/projet). Bien que Codex gère cette conversion automatiquement la plupart du temps, veillez à respecter ces règles :

• Indiquez des chemins absolus complets dans votre fichier ~/.codex/config.toml (ex. C:\chemin\absolu).
• Pour autoriser la lecture d'un répertoire externe par la sandbox, utilisez la commande slash suivante dans la session active de Codex en renseignant un chemin absolu existant :

/sandbox-add-read-dir C:\chemin\absolu

Cette autorisation de lecture s'applique uniquement à la session en cours. Elle doit être renouvelée en cas de réinitialisation.

2. La gestion des sauts de ligne CRLF

Il s'agit d'un point classique lié à l'usage de Git sous Windows, mais dont l'impact est visible lors des modifications de fichiers par Codex.

Analogie : Les normes de prises électriques. Les formats LF (Unix) et CRLF (Windows) représentent deux manières de coder un retour à la ligne (présence ou non du caractère \r). Si vous clonez un projet configuré en LF, Git sous Windows peut le convertir automatiquement en CRLF. Lorsque Codex modifie le code et l'enregistre, le diff affiche des modifications sur chaque ligne en raison des caractères de fin de ligne modifiés, rendant la relecture impossible.

Pour éviter ce comportement, forcez la politique de fin de ligne du projet en créant un fichier .gitattributes à la racine :

* text=auto eol=lf

Vous pouvez également désactiver globalement la conversion automatique de Git dans PowerShell :

git config --global core.autocrlf false

L'essentiel est de maintenir une cohérence des sauts de ligne pour éviter que les modifications de Codex ne soient masquées par des changements de formatage invisibles.

3. Les avertissements sur les droits d'accès Everyone

Codex peut afficher une alerte indiquant que certains dossiers disposent d'un accès en écriture ouvert à tout le monde (Everyone). La sandbox bloque l'exécution si les droits d'accès des dossiers du projet sont trop permissifs. Supprimez les droits d'écriture du groupe Everyone sur ces répertoires et relancez Codex. Contactez votre service informatique si vous ne pouvez pas modifier ces droits de dossier.

Erreur constatée	Cause possible	Résolution
Chemin de fichier non détecté	Erreur de syntaxe ou chemin relatif non résolu	Indiquez un chemin absolu existant, utilisez /sandbox-add-read-dir
Diff de code illisible (CRLF)	Conversion des sauts de ligne par Windows	Ajouter un fichier .gitattributes avec eol=lf ou désactiver core.autocrlf
Alerte de sécurité au démarrage	Permissions Everyone trop larges sur les dossiers	Restreindre les droits d'écriture dans les propriétés de sécurité Windows

💡 Résumé en une phrase : Déclarez des chemins absolus, fixez les sauts de ligne sur LF via le fichier .gitattributes, et réduisez les permissions d'accès aux dossiers pour éviter les blocages sous Windows.

---

05 La sandbox sous Windows : spécificités et configuration

La sandbox (le mécanisme de sécurité limitant les accès fichiers et réseau) utilise des technologies différentes sur chaque système. macOS utilise sandbox-exec, Linux utilise bubblewrap, et Windows s'appuie sur deux modes de sécurité propres.

En mode natif sous Windows, le processus d'agent bloque les écritures en dehors du dossier de travail et les accès réseau non approuvés. Ces règles se configurent dans le fichier ~/.codex/config.toml :

[windows]
sandbox = "elevated" # ou "unelevated"

Voici la distinction entre les deux modes :

Mode	Niveau de sécurité	Mécanisme technique	Cas d'usage
elevated (recommandé)	Maximum	Utilisateur système dédié à droits restreints, pare-feu Windows et politiques locales de sécurité	Configuration par défaut recommandée
unelevated (secours)	Intermédiaire	Jeton de sécurité Windows restreint, restrictions de droits (ACL) et isolation environnementale	À utiliser si le mode elevated est bloqué par l'IT

Contrairement aux anciennes recommandations, le mode elevated est la configuration par défaut à privilégier pour des raisons de performance et d'isolation. L'isolation de l'affichage (Private Desktop) est active par défaut pour les deux modes ; il est déconseillé de désactiver l'option windows.sandbox_private_desktop sauf pour des besoins spécifiques de compatibilité avec les sessions Windows classiques Winsta0\Default.

Pourquoi le mode elevated peut-il échouer au démarrage ? Ce mode requiert la création d'un utilisateur Windows dédié, la modification des règles de pare-feu et l'ajustement de stratégies de sécurité locales. Sur les postes d'entreprise, ces actions d'administration sont fréquemment bloquées par les politiques de sécurité (GPO). L'erreur la plus fréquente est le code 1385 (indiquant que l'utilisateur de la sandbox ne dispose pas des droits de connexion requis sur la machine).

Si vous rencontrez l'erreur 1385 :

1. Demandez à votre service informatique d'autoriser les privilèges de connexion requis pour l'utilisateur de sandbox créé par Codex.
2. Vérifiez si des restrictions de stratégies de groupe (GPO) bloquent l'accès.
3. Pour continuer à travailler immédiatement, configurez temporairement la sandbox sur le mode unelevated.
4. Envoyez le fichier de log CODEX_HOME/.sandbox/sandbox.log et les détails de votre version Windows à l'équipe support.

🔒 Attention à la confidentialité : ne partagez jamais le contenu du répertoire de clés secrètes CODEX_HOME/.sandbox-secrets/ ; seul le fichier sandbox.log doit être partagé pour analyse.

Si Codex signale un accès bloqué en lecture sur un dossier nécessaire à la tâche, utilisez la commande /sandbox-add-read-dir présentée au paragraphe 04 pour l'ajouter au périmètre.

💡 Résumé en une phrase : La sandbox Windows propose deux modes : elevated (par défaut) et unelevated (secours). L'erreur 1385 est généralement causée par des restrictions de sécurité d'entreprise bloquant les droits de l'utilisateur dédié.

---

06 Pratique : exécuter une première tâche Codex sous Windows

Voici la procédure pour initialiser un projet de test et exécuter une tâche de modification de fichier dans un terminal PowerShell natif.

Étape 1 : Initialiser le dossier de projet (dans PowerShell) :

mkdir codex-win-test
cd codex-win-test
git init
"console.log('hi')" | Out-File -Encoding utf8 app.js

Si vous utilisez une ancienne version de PowerShell (5.1), la commande Out-File peut ajouter une marque d'ordre des octets (BOM) au fichier UTF-8, générant des caractères superflus dans Git. Sous PowerShell 7+, utilisez plutôt Set-Content -Encoding utf8NoBOM pour éviter ce comportement.

Étape 2 : Configurer la politique des sauts de ligne en créant le fichier .gitattributes à la racine :

* text=auto eol=lf

Étape 3 : Démarrer l'interface Codex :

codex

Lors du premier lancement en mode elevated, Windows peut afficher une demande d'autorisation d'administration (UAC) pour finaliser l'installation des composants de sécurité. Si les droits d'administration sont bloqués sur votre poste, Codex bascule automatiquement en mode unelevated après un avertissement, vous permettant de continuer le travail.

Étape 4 : Confier une tâche de modification de fichier dans le terminal Codex :

Remplace 'hi' par 'hello, codex on windows' dans app.js

Résultat attendu : Codex analyse le code de app.js, affiche le diff de modification proposé et sollicite votre validation. Après confirmation, les modifications sont écrites. Vérifiez le contenu du fichier modifié :

Get-Content app.js

Le fichier doit afficher :

console.log('hello, codex on windows')

Étape 5 : Valider la structure du diff avec Git (bonne pratique pour s'assurer de l'absence de modifications de fin de ligne) :

git diff

Le diff doit afficher uniquement la ligne modifiée. Si des caractères ^M apparaissent sur chaque ligne, reprenez la configuration des sauts de ligne décrite au paragraphe 04.

Lancer cette validation rapide lors de la configuration de chaque nouvel environnement Windows permet de s'assurer du bon fonctionnement des outils de versionnage de code.

💡 Résumé en une phrase : Initialisez le projet, configurez le fichier .gitattributes, lancez Codex, appliquez la modification et validez la structure du diff avec git diff pour confirmer le bon fonctionnement de l'environnement Windows.

---

Synthèse

Ce chapitre a présenté les spécificités de l'utilisation de Codex sous Windows :

• Le choix de l'environnement : privilégiez PowerShell natif avec la sandbox elevated pour de meilleures performances ; réservez WSL2 aux développeurs travaillant déjà sous Linux.
• L'installation : le CLI s'installe via le script PowerShell officiel. Vérifiez vos versions Windows, l'accès winget et les outils de compilation C++ pour VS Code.
• La résolution des erreurs : utilisez des chemins absolus, forcez les fins de lignes en LF avec le fichier .gitattributes et adaptez les permissions de dossiers.
• La gestion de la sandbox : Windows dispose de ses propres modes elevated (recommandé) et unelevated (secours). L'erreur 1385 est le signe d'un blocage de politique de sécurité d'entreprise.

Vous êtes maintenant en mesure de : Installer et configurer Codex sous Windows, faire le choix de l'environnement PowerShell ou WSL2, et résoudre les anomalies liées aux sauts de ligne ou à la sandbox Windows. L'intégration de ces spécificités permet de retrouver une expérience d'utilisation similaire à celle de macOS.

---

Le chapitre suivant 〔34 Projet de synthèse〕 conclut la section Codex : nous mettrons en pratique l'ensemble des connaissances (configurations, modèles, permissions, sous-agents, gestion de projet) pour réaliser un cas pratique de développement complet.

---

Lectures recommandées

• Intégrer les modèles tiers (comme DeepSeek)
• Les quatre flux de travail types : exploration, correction, refactorisation, tests
• Les extensions pour IDE (VS Code, etc.)